专题：流行MCP服务器系统学习
关键词：MCP, MCP服务器, Model Context Protocol, MCP协议概述, LLM工具, Anthropic, 标准化
随着大型语言模型（LLM）能力的不断增强，开发者越来越希望将模型与现实世界的数据源和工具连接起来。然而，在MCP出现之前，LLM应用与外部系统的集成处于高度碎片化的状态。每个AI应用框架都在自行定义工具调用的接口规范，从LangChain的Tool抽象到OpenAI的Function Calling，再到各类Agent框架的自定义协议，缺乏一个统一的标准来协调整个生态。这种碎片化导致开发者在构建LLM应用时，不得不为每个数据源和工具编写自定义集成代码，造成了大量的重复劳动和维护负担。
另一个核心痛点是数据孤岛问题。企业内部积累了大量的数据和业务系统——数据库、文件服务器、API服务、SaaS工具等——但这些系统与LLM之间的交互缺乏标准化通道。开发者需要为每一个数据源单独开发连接器，而且不同AI框架之间的连接器无法复用。这种"各自为政"的局面严重制约了LLM在实际生产环境中的落地效率。市场迫切需要一种统一的协议，让所有AI应用都能以相同的方式发现和访问外部数据与工具。
2024年11月，Anthropic正式推出了Model Context Protocol（MCP），这是一个开放标准，旨在为LLM应用与外部数据源及工具之间建立统一、安全的通信协议。MCP的设计哲学借鉴了USB-C接口的理念——一个统一的接口标准，连接各种外设。在AI的语境下，MCP充当了LLM应用的"USB-C接口"：无论底层是哪种模型、哪个框架，只要实现了MCP协议，就能无缝连接各类数据源和工具服务。Anthropic将此协议以开源方式发布，希望推动整个AI行业走向更加开放和标准化的未来。
从战略意义上看，MCP的诞生是AI应用架构从"单体应用"向"协议化生态"演进的重要里程碑。它不仅降低了开发者的集成成本，更重要的是为AI应用建立了一个可组合、可扩展的"应用层协议"。正如HTTP协议定义了Web应用之间的通信标准，TCP/IP定义了网络层的数据传输标准，MCP有潜力成为AI应用领域中事实上的"上下文传输标准"。对于整个AI生态而言，这意味着更多的创新可以发生在应用层和协议层之上，而非被底层的集成细节所束缚。
在实际应用中，MCP解决了一个长期困扰AI开发者的核心矛盾：LLM需要访问实时、私密、海量的外部数据来提供有价值的回答，但传统的数据访问方式在AI语境下既不安全也不高效。MCP通过标准化的协议设计，在数据提供者和AI消费者之间建立了一个清晰、可控的边界，既让LLM能够"看到"需要的信息，又保证了数据源的访问安全性和可控性。这种设计正在被越来越多的AI开发工具和平台所采纳。
关键认知：MCP不是一个新的AI模型，也不是一个具体的AI应用，而是一个用于标准化LLM与外部世界交互的通信协议。它的地位类似于Web开发中的HTTP协议——定义了客户端和服务器如何交换请求和响应。
MCP采用了经典的三层客户端-服务器架构，这种架构设计并非偶然，而是经过了深思熟虑的权衡。整个体系由MCP Host（主机）、MCP Client（客户端）和MCP Server（服务器）三个核心角色构成。每一层都有明确的职责边界，使得系统具有良好的可扩展性和维护性。这种分层架构与Web开发中的三层架构有着异曲同工之妙，但在AI上下文中赋予了各层全新的语义和功能。
MCP Host 是用户直接面对的AI应用层，例如Claude Code桌面应用、Claude CLI终端工具，或其他任何集成了MCP协议支持的AI应用程序。Host的职责是承载整个交互过程，它负责管理用户会话、维护对话上下文、协调LLM的调用，以及将通过MCP Client获取的工具调用结果反馈给用户。从用户体验的角度看，Host是整个MCP生态的入口，也是用户感知协议价值的第一触点。
MCP Client 是Host与Server之间的通信桥梁，一个Host可以同时维护多个Client实例，每个Client连接到一台MCP Server。Client负责协议的底层实现细节：建立和维持与Server的连接（通过stdio或SSE两种传输方式）、发送初始化请求进行能力协商、将Host发来的工具调用请求转发给Server、接收Server返回的结果并传递回Host。Client层是协议实现的核心，它封装了所有通信的复杂性，使得上层Host和底层Server都可以专注于各自的核心功能。
MCP Server 是数据源和工具的提供者，每个Server专注于暴露特定领域的功能。一个Server可以暴露三种类型的能力：Tools（可被LLM调用的函数操作）、Resources（可被LLM读取的数据内容）和Prompts（预定义的提示模板）。例如，一个文件系统MCP Server可以暴露文件读写操作（Tools）和文件内容查看（Resources）；一个数据库MCP Server可以暴露SQL查询执行（Tools）和表结构信息（Resources）。Server的设计追求单一职责和高内聚，每个Server只做一件事但做到极致。
在连接机制上，MCP支持两种传输方式。stdio传输适用于本地集成场景：Host通过子进程启动Server，双方通过标准输入输出流进行JSON-RPC消息交换，这种方式延迟低、配置简单，非常适合开发者本地使用的工具场景。SSE（Server-Sent Events）传输适用于远程服务场景：Server作为独立的HTTP服务运行，Host通过网络连接，这种方式支持跨网络部署、多客户端共享和集中式管理，适合生产环境中的服务化部署。两种传输方式使用相同的协议语义，上层业务逻辑无需感知底层传输差异。
MCP的架构设计遵循了"关注点分离"（Separation of Concerns）原则。Host关注用户体验，Client关注协议通信，Server关注数据和服务。每一层都可以独立演进，这是MCP生态能够快速发展的架构基础。
MCP协议定义了三种核心原语（Primitives），构成了Server暴露能力的完整语义体系。这三种原语分别是：Tools（工具）、Resources（资源）和Prompts（提示）。理解三者的区别和适用场景，是掌握MCP协议的关键。从抽象层次上看，它们分别对应了"执行操作"、"读取数据"和"结构化引导"三种不同的交互模式，覆盖了LLM与外部世界交互的全部需求场景。
Tools（工具）是可被LLM动态调用的函数式接口。每个Tool有明确的输入参数（Input Schema，使用JSON Schema定义）和执行逻辑。当LLM在推理过程中判定需要执行某个外部操作时（例如查询天气、发送邮件、执行代码），Host将LLM发出的函数调用请求通过MCP Client转发给对应的Server执行，执行结果再返回给LLM进行后续推理。Tools的最大特点是具有"副作用"——它们会改变外部世界的状态或产生新的数据。这种"读-写"能力使Tools成为MCP中最强大也最需要谨慎使用的原语。
Resources（资源）是可被LLM读取的数据内容，类似于文件系统中的"GET"操作。Resources通过URI进行标识和定位（例如file:///path/to/doc.txt或db://schema/users），每个Resource可以包含元数据（MIME类型、描述信息等）和实际内容。Resources适合于暴露那些需要LLM实时获取的最新数据——例如当前的项目文件内容、数据库模式定义、API文档等。与Tools不同，Resources通常是"只读"的，不会产生副作用。Server可以通过Resource Templates机制暴露动态资源集合，实现类似RESTful API中路径参数的效果。
Prompts（提示）是预定义的提示模板，用于引导LLM的行为模式。每个Prompt包含模板名称、参数定义和模板内容。当用户需要LLM以特定方式执行任务时（例如"翻译这段文字到英文"或"总结这篇文档的要点"），可以通过Prompt直接激活预设的行为模式。Prompts本质上是一种"结构化提示工程"的工具，它将最佳实践和领域知识固化到可复用的模板中，降低用户编写高质量提示的门槛。Prompts也可以包含动态参数，使得同一个模板可以适用于不同场景。
| 原语 | 类比 | 是否改变状态 | 调用方式 | 典型用例 |
|---|---|---|---|---|
| Tools（工具） | API POST请求 / 函数调用 | 是（有副作用） | LLM按需动态调用 | 查询数据库、发送消息、执行代码 |
| Resources（资源） | 文件系统读取 / GET请求 | 否（只读） | LLM读取指定URI内容 | 读取日志、查看文档、获取配置 |
| Prompts（提示） | 模板引擎 / 预设命令行 | 否（引导行为） | 用户在特定场景激活 | 翻译模板、分析模板、报告模板 |
三大原语的组合使用使得MCP Server可以灵活地适应各种应用场景。例如，一个GitHub MCP Server可以同时暴露：查看仓库文件内容（Resources）、创建Issue（Tools）、以及"分析PR变更"的预设提示模板（Prompts）。这种设计避免了为每种交互模式分别定义协议的开销，同时保持了语义的清晰和一致性。在实际开发中，大部分MCP Server主要实现Tools和Resources，Prompts则更多由上层应用或框架提供。
理解重点：三种原语并非互斥关系，一个Server可以同时提供所有三种原语。区分三者的关键是弄清楚每一次交互是"在读数据"（Resources）、"在执行操作"（Tools）还是"在应用模板"（Prompts）。这种清晰的语义分层是MCP协议设计的重要优势。
MCP协议的一个重要设计亮点是能力协商（Capability Negotiation）机制。当MCP Client与MCP Server建立连接时，双方并不是简单地开始传输数据，而是首先通过一个握手过程来交换能力信息。这个机制的设计灵感来自HTTP的Upgrade机制和gRPC的能力协商，但在AI上下文中赋予了更加丰富的语义。能力协商确保了协议的前后兼容性——新版本的Server可以与旧版本的Client正常协作，反之亦然。
具体的协商流程如下：Client首先向Server发送一个initialize请求，其中包含Client支持的协议版本列表（例如["2024-11-05", "2025-03-26"]等）、Client自身具备的能力（例如是否支持采样请求、是否支持根目录访问等），以及Client的元信息（名称、版本等）。Server收到initialize请求后，响应中返回Server选择的协议版本、Server自身支持的能力列表（例如是否提供Tools、是否提供Resources、是否支持订阅通知等），以及Server的元信息。如果双方存在可用版本的交集，则继续建立连接；否则连接失败。
完成initialize请求-响应交换后，Client发送initialized通知，表示初始化完成。此后双方进入正常的消息交换阶段。在整个握手过程中，Server只是声明了自己支持哪些能力，但Client是否实际使用这些能力则由Client自主决定。例如，一个Server可能同时支持Tools和Resources，但如果Client（例如某个Host实现）只实现了Tools的调用逻辑，那么Client可以只使用Server的Tools能力，而忽略其Resources暴露。这种设计赋予了Client充分的灵活性，使得同一个Server可以在不同的Host环境中展现出不同的交互模式。
能力协商机制在实际运行中体现出了重要的工程价值。首先，它实现了前向和后向兼容性——当协议版本升级时，老旧的Client和Server仍然可以通过版本协商找到共同支持的协议版本继续工作。其次，它支持渐进式功能增强——新版本的Server可以添加新的能力而不会破坏与旧版本Client的兼容性。最后，它提供了清晰的错误边界——如果Client请求了某个Server不支持的能力，Server可以在能力响应中明确告知，Client据此可以给出清晰的错误提示而非神秘的连接失败。这种"优雅降级"的设计理念贯穿了整个MCP协议的实现。
实践提示：在开发自定义MCP Server时，务必准确声明Server的能力集。如果Server支持Tools，则在initialize响应中的capabilities.tools字段必须为有效对象。过度声明能力（声称支持但实际未实现）会导致Client端行为异常。反之，少声明能力只会限制功能不会导致错误，这是一种安全的保守策略。
在MCP出现之前，Function Calling（函数调用）是AI应用与外部工具交互的主流方式。OpenAI最早在GPT-4系列模型中引入了Function Calling功能，允许开发者以JSON Schema形式定义可调用的函数，LLM在生成回复时可以选择调用这些函数。随后各大AI平台纷纷跟进，形成了各自不同的实现方案。虽然Function Calling极大地推动了LLM在实际场景中的应用，但它本质上是一种API层面的机制，不同平台之间的Function Calling实现互不兼容。
MCP与Function Calling最大的区别在于抽象层级。Function Calling是模型层或API层的功能，由LLM平台直接提供支持，开发者需要按照特定平台的格式定义函数，依赖于该平台的LLM原生支持。而MCP是协议层的标准化方案，独立于任何特定的LLM或平台。一个实现了MCP的Server可以在任何支持MCP的Host中工作，无论是Claude、GPT还是其他模型。这种"一次编写，到处运行"的特性是MCP的核心价值主张。
从功能维度看，Function Calling只解决了"工具调用"这一个问题——定义函数、让LLM选择调用、获取结果。而MCP提供了更全面的解决方案：除了Tools（工具调用）之外，还包括Resources（数据读取）和Prompts（提示模板）。这意味着MCP不仅仅是一个工具调用标准，更是一个完整的"AI上下文协议"。特别是Resources原语填补了Function Calling生态中的一个重要空白——在没有MCP之前，LLM读取外部数据需要开发者自行实现数据获取逻辑，缺乏标准化的发现和访问机制。
| 对比维度 | MCP | Function Calling |
|---|---|---|
| 抽象层级 | 协议层（标准化通信协议） | API层（特定平台的功能接口） |
| 适用范围 | 跨平台、跨模型通用 | 绑定特定LLM平台 |
| 能力范围 | Tools + Resources + Prompts | 仅Tools（函数调用） |
| 传输协议 | stdio / SSE（JSON-RPC） | HTTP（RESTful API） |
| 能力发现 | 标准化initialize协商 | 无标准化机制，需手动配置 |
| 工具定义 | 统一的JSON Schema Input Schema | 各平台格式不同 |
| 扩展性 | 高（可添加自定义原语） | 低（受限于平台实现） |
| 社区生态 | 开源协作，社区驱动 | 各平台闭门造车 |
需要强调的一点是，MCP和Function Calling并非非此即彼的竞争关系。在实际实现中，MCP Client在将Server的Tools暴露给LLM时，底层仍然会使用LLM的Function Calling能力——因为目前LLM原生理解的"工具"语义就是Function Calling。MCP更多的是在Function Calling之上增加了一层标准化封装：它将工具的定义从LLM平台特定的格式转化为MCP统一的格式，然后由MCP Client在调用LLM时再转换成该LLM所需要的具体格式。因此，更准确的理解是：MCP是Function Calling的标准化包装层，而非替代品。
注意事项：不要将MCP与Function Calling对立起来。在实际的Claude Code等实现中，MCP Server暴露的Tools最终会通过Claude的Tool Use API（即Function Calling机制）传递给模型。MCP的价值在于让工具的定义、发现、连接过程标准化，而工具的执行仍然依赖底层LLM的Function Calling能力。
MCP自发布以来，已经在AI开发工具生态中引起了广泛的关注和快速采纳。作为Anthropic开源的核心协议，MCP与Claude Code形成了天然的共生关系。Claude Code是首个深度集成MCP协议的AI编程助手，它作为MCP Host，允许用户通过配置MCP Server来扩展其对项目文件、数据库、API服务等外部资源的访问能力。在Claude Code中，用户可以通过简单的JSON配置文件（通常命名为.mcp.json或在IDE配置中设置）注册任意数量的MCP Server，每个Server为Claude Code带来新的工具和资源能力。
从更广阔的视角来看，MCP与OpenAI的Plugins生态在理念上有相似之处——都是为了让AI应用能够与外部世界交互。但两者的实现路径存在本质差异：OpenAI Plugins采用集中式托管和审核模式，开发者需要向OpenAI提交插件并通过审核才能上架；而MCP采用开放的去中心化模式，任何开发者都可以构建和发布MCP Server，无需任何中心化审核。这种去中心化的设计使得MCP生态的发展更加迅速和多样化。截至2025年，社区已经涌现了数百个开源的MCP Server实现，覆盖了数据库、云服务、开发工具、内容管理系统等各个领域。
MCP社区生态正在快速成熟。在开源社区方面，GitHub上已经出现了多个MCP Server的集合仓库（如modelcontextprotocol/servers官方仓库和mcp-computer/mcp-servers社区仓库），提供了从文件系统、Git、SQLite数据库到浏览器自动化、Slack集成、GitHub API等各类Server的参考实现。在框架支持方面，多个流行的AI开发框架已经提供了MCP支持的SDK，包括Python官方SDK（mcp）、TypeScript官方SDK（@modelcontextprotocol/sdk），以及社区维护的Go、Java、Rust等语言实现。在企业应用方面，一些云平台和SaaS工具提供商也开始原生支持MCP协议，允许用户直接通过MCP接口访问其服务。
MCP被业界广泛称为"AI界的USB-C"。这个比喻非常形象地传达了MCP的核心价值：在USB-C出现之前，电子设备使用各种不同的接口标准（USB-A、Mini-USB、Micro-USB、Lightning等），用户需要携带多种数据线，设备之间的互连困难重重。USB-C通过一个统一的接口标准彻底改变了这种局面。同样地，在MCP出现之前，AI应用与外部工具和数据的连接方式五花八门，MCP通过统一的标准让"即插即用"成为可能。当然，与USB-C的普及历程一样，MCP的广泛采纳也需要时间和生态各方的共同努力。
核心要点总结：
1. MCP是一个开放协议，旨在标准化LLM应用与外部数据源及工具的通信
2. 采用三层架构：Host（应用层）、Client（协议层）、Server（服务层）
3. 三大原语：Tools（执行操作）、Resources（读取数据）、Prompts（引导行为）
4. 能力协商机制确保前后兼容性和灵活的能力组合
5. 相比Function Calling，MCP是协议层标准化，提供更全面的能力
6. "AI界的USB-C"——一个统一的接口标准连接各种AI工具和数据源