一、Function Calling 的天花板#

在理解 MCP 之前，必须先理解它试图解决的问题。

Function Calling（函数调用）自 2023 年 OpenAI 首次引入以来，已经成为大模型与外部工具交互的事实标准。它的机制很直观：模型在生成回复时，识别出需要调用某个工具，输出一段结构化的 JSON，外部系统解析这段 JSON 并执行对应的函数，然后将结果返回给模型。

这个机制在简单场景下工作得很好。但当场景复杂化时，三个结构性问题开始显现。

第一个问题是工具发现。 在 Function Calling 模型中，所有可用工具必须在 Prompt 中预先定义。这意味着每增加一个新工具，就需要修改 Prompt、更新应用代码、重新部署。当工具数量从 5 个增长到 50 个时，Prompt 中工具定义的部分可能占据数千 token，直接挤压对话上下文的可用空间。

第二个问题是上下文断裂。 Function Calling 的调用是原子性的：模型输出调用指令 → 外部系统执行 → 结果返回 → 模型继续生成。如果一次任务需要连续调用多个工具（例如”先查数据库找出用户 ID，再查订单系统获取订单详情，最后发邮件通知”），整个过程需要在应用层手动编排。模型本身并不理解工具之间的依赖关系，它只是被动地等待每次调用的结果。

第三个问题也是最关键的问题：平台锁定。 OpenAI 的 Function Calling 格式与 Anthropic 的不兼容，与 Google 的也不兼容。一个为 GPT-4 写的工具定义无法直接在 Claude 或 Gemini 上使用。这意味着每支持一个新模型，开发者就要重写一遍工具集成逻辑。

这三个问题指向同一个结论：Function Calling 是一个模型层的功能，而不是系统层的协议。它解决的是”模型如何调用函数”，但没有解决”AI 应用如何与外部能力生态对接”。

二、MCP 的设计逻辑：从命令式到声明式#

MCP 的核心设计可以用一句话概括：把工具从 Prompt 中剥离出来，变成独立的服务。

具体来说，MCP 引入了三个角色：

• Host：运行 AI 模型的应用程序（如 Claude Desktop、Cursor）
• Client：Host 内部的组件，负责与 MCP Server 建立和管理连接
• Server：提供具体能力的服务端，可以是本地文件系统、数据库、GitHub API，甚至浏览器

这三个角色的关系不是”模型调用函数”，而是”Host 通过 Client 与 Server 协商能力”。这里的”协商”是关键词。

当 Host 启动时，MCP Client 会连接到所有配置的 MCP Server，发起一个 Capability Negotiation（能力协商）过程。Server 告诉 Client：我提供哪些工具、哪些资源、哪些预定义 Prompt；Client 告诉 Server：我需要什么权限、支持哪些传输协议。只有在协商成功后，双方才建立正式会话。

这个设计与 Function Calling 的根本区别在于：Function Calling 是命令式的（“调用这个函数”），MCP 是声明式的（“让我们看看有什么能力可用”）。

声明式设计带来三个直接收益：

工具即插即用。 新增一个 MCP Server 只需要在配置文件中添加一条记录，不需要修改 Prompt，不需要重新部署应用。Claude Desktop 的 claude_desktop_config.json 就是一个典型例子——用户通过修改一个 JSON 文件，就能让 Claude 获得文件系统、GitHub、数据库等新能力。

上下文持续。 MCP 会话是有状态的。在一次会话中，模型可以连续调用多个工具，工具之间可以共享上下文。例如，模型先通过文件系统 Server 读取项目配置，再通过 Git Server 获取提交历史，两个操作在同一个会话中完成，上下文自然延续。

跨模型兼容。 因为 MCP 是一个独立于模型的协议层，只要模型支持 MCP Client，它就能使用所有兼容的 MCP Server。Anthropic 的 Claude、OpenAI 的 GPT、Google 的 Gemini、甚至开源模型，理论上都可以接入同一个 MCP Server 生态。

三、为什么是 JSON-RPC？#

MCP 的通信协议选择 JSON-RPC 2.0，而非更流行的 REST 或 gRPC。这个选择本身反映了设计团队对问题域的深刻理解。

REST 是请求-响应式的，客户端发起请求，服务器返回响应，通信方向单一。但 AI 与工具的交互经常需要双向通信：模型请求工具执行某个操作，工具执行过程中可能需要向模型请求额外信息（例如”你想查询哪个数据库？”），这是一个双向对话过程。

JSON-RPC 支持两种传输模式，恰好覆盖了这个需求：

• stdio（标准输入输出）：用于本地 MCP Server，进程间通信，延迟最低
• SSE（Server-Sent Events）+ HTTP：用于远程 MCP Server，支持服务器主动推送

更关键的是，JSON-RPC 的批处理和通知机制让 MCP 能够高效处理多工具协调场景。模型可以一次性发送多个工具调用请求，Server 并行执行后统一返回结果，而不需要每个调用都经历一次完整的请求-响应往返。

当然，这个选择也有代价。JSON-RPC 的序列化开销高于二进制协议（如 gRPC 的 Protocol Buffers），在高频调用场景下可能成为瓶颈。但对于 MCP 定位的”AI 与工具交互”场景，通信频率远低于微服务间调用，可读性和调试便利性比极致性能更重要。

四、生态现状：谁在真正使用？#

截至 2026 年初，MCP 生态已经超越了”早期采用者”阶段，进入规模化落地期。

客户端侧：Claude Desktop 提供了最完整的 MCP 体验，原生支持配置管理、权限控制、会话可视化。Cursor 和 Windsurf 作为 AI 原生 IDE 也快速跟进。值得注意的是，JetBrains 在其 IDE 中采用了反向策略——不是作为 MCP Host 消费 Server，而是将 IDE 本身的能力暴露为 MCP Server，让外部 AI 工具能够操作代码库。

服务端侧：公开可查的 MCP Server 已超过 1000 个。按 GitHub Stars 排序，最活跃的领域是：

• 文件系统访问（64k stars）——让 AI 能读写本地文件
• Git 操作（64k stars）——版本管理的自然语言接口
• 数据库查询（43k stars）——SQL 的自然语言封装
• Web 抓取（85k stars）——Firecrawl MCP 让 AI 能解析任意网页

这些数据揭示了一个趋势：MCP Server 正在将传统开发者工具重新封装为”AI 可消费”的接口。不是替代现有工具，而是为它们增加一层 AI 友好的协议适配。

治理层面：Linux 基金会于 2025 年底正式接管 MCP 的治理，这是一个关键信号。这意味着 MCP 正在从 Anthropic 的”公司项目”转变为”行业标准”。OpenAI 在 2025 年宣布支持 MCP，Google 的 A2A（Agent-to-Agent）协议也选择与 MCP 互补而非竞争，进一步巩固了 MCP 作为”AI-工具”层标准协议的地位。

五、架构影响：从单体应用到能力网络#

MCP 对软件架构的影响，堪比 1990 年代 CORBA 或 2000 年代 SOAP 对分布式系统的影响——但这一次，协议的轻量化让它更有可能真正普及。

对 AI 应用架构的影响是深远的。在 MCP 之前，一个 AI 应用的架构通常是这样的：

1
用户 → AI 应用 → [模型 + 硬编码工具集成]

工具与模型紧密耦合，每增加一个工具就要修改应用代码。

在 MCP 之后，架构变成了：

1
用户 → AI 应用(Host) → MCP Client → [MCP Server 1, MCP Server 2, ...]
2
                      ↓
3
                    模型

工具通过标准化协议与模型解耦。模型不需要知道工具的具体实现，只需要知道工具的接口定义（通过 Capability Negotiation 获取）。工具可以独立演进，新工具可以在不修改应用的情况下被动态发现和使用。

这意味着 AI 应用正在从单体架构向能力网络架构演进。Host 不再是一个自包含的应用程序，而是一个连接节点，负责协调模型与各种 MCP Server 之间的交互。

对开发者工作流的影响同样显著。以前，开发者需要为每个 AI 平台单独编写工具集成代码；现在，开发者只需要编写一次 MCP Server，所有支持 MCP 的客户端都能使用。但代价是增加了协议层的复杂性——调试一个 MCP Server 比调试本地函数要困难得多，因为涉及进程通信、协议协商、会话管理等多个环节。

六、局限与真实成本#

MCP 不是银弹。在评估是否采用时，需要清醒认识以下几个局限。

性能开销。 JSON-RPC 的文本序列化、进程间通信（stdio 模式）或网络往返（SSE 模式）都会引入延迟。对于需要高频调用的场景（例如实时数据分析），MCP 的响应时间可能难以接受。内部测试数据显示，本地 stdio 模式的 MCP 调用延迟约为 50-100ms，而同等功能的本地函数调用延迟在 1ms 以下。

安全模型尚未成熟。 MCP Server 本质上是外部进程，它可以执行任意代码、访问文件系统、发起网络请求。目前的安全机制主要依赖 Host 层的沙箱和权限控制，但不同 Host 的实现差异很大。Claude Desktop 提供了相对完善的权限管理（用户可以精确控制每个 Server 能访问哪些目录），但其他 Host 的安全策略参差不齐。

调试困难。 当 MCP 调用失败时，问题可能出在 Client、Server、传输层或协议本身中的任何一个环节。错误信息经常不够具体，开发者需要手动检查 JSON-RPC 消息流来定位问题。生态中缺乏成熟的调试工具，这增加了开发和维护成本。

中心化风险。 尽管 Linux 基金会已经接管治理，但 MCP 的核心设计仍然带有 Anthropic 的技术偏好（例如对 Claude 使用场景的优化）。如果未来出现与 Anthropic 商业利益冲突的技术决策，社区能否保持中立仍然有待观察。

七、开发者的实际决策框架#

面对 MCP，开发者需要回答的不是”MCP 好不好”，而是”我的场景是否需要 MCP”。

适合使用 MCP 的场景：

• 应用需要接入多种外部工具（5 个以上），且工具会频繁新增或更新
• 应用需要支持多种 AI 模型（Claude、GPT、Gemini 等），不希望为每个模型重复写工具集成
• 工具需要独立部署和维护（例如数据库查询工具由 DBA 团队维护，AI 应用由前端团队维护）
• 需要让非技术用户通过配置文件就能扩展应用能力（如 Claude Desktop 的配置文件方式）

不适合使用 MCP 的场景：

• 只有 1-2 个简单工具需要集成，Function Calling 已经足够
• 对延迟极度敏感（如实时推荐系统），本地函数调用的性能优势明显
• 安全要求极高，无法信任外部 MCP Server 的执行环境

构建 MCP Server 的建议：

1. 从官方 SDK 开始（TypeScript 或 Python），不要从零实现协议
2. 明确 Capabilities 的粒度——太细会导致工具数量爆炸，太粗会降低灵活性
3. 为每个工具写清晰的描述文档，模型依赖这些描述来决定调用哪个工具
4. 实现完善的错误处理和日志记录，MCP 的调试成本远高于本地函数

八、结语#

MCP 不是又一个 AI 框架的昙花一现。它正在做的事情——为 AI 应用与外部能力建立标准化的接口层——是 AI 基础设施从”玩具”走向”工程”的必经之路。

但这个协议本身也处于早期阶段。性能、安全、调试工具、治理机制，都还有大量工作要做。对于开发者来说，最务实的态度是：在合适的场景下开始使用它，同时保持对局限性的清醒认识。

Function Calling 不会消失，它仍然是简单场景的最佳选择。MCP 的价值在于填补了 Function Calling 无法覆盖的规模化、标准化、生态化缺口。

最终，AI 应用与外部工具的集成方式将从”每个应用自己造轮子”走向”接入标准化的能力网络”。MCP 正在推动这个转变，但它只是开始，不是终点。