7.3 模型上下文协议（MCP）

就像早期的电脑接口各不相同，直到USB标准的出现才统一了设备连接方式一样。大模型的外部交互能力也需要统一。2024 年底 Claude 母公司 Anthropic 发布了 模型上下文协议（Model Context Protocol，MCP），它正是为了解决这个问题而诞生的。

7.3.1 什么是 MCP？

MCP 是一个开放协议，它规范了应用程序向 LLM 提供上下文的方式。正如 USB-C 提供了一种标准化的方式将您的设备连接到各种外围设备和配件一样，MCP 也提供了一种标准化的方式将 AI 模型连接到不同的数据源和工具。

简单来说，MCP 是为“模型-外部系统”之间的数据交互建立的一种统一上下文协议层，让模型不仅能“看懂”用户输入，还能"理解"环境状态、会话历史、工具链信息，甚至主动“做事”。

7.3.2 MCP工作原理

MCP 由三个部分构成：

• MCP Host： 主机或者说连接大模型的应用程序，负责协调各模块、维护统一的上下文状态（比如 Cursor、Cline、Claude Desktop 等）
• MCP Client： 作为应用程序的接入点，负责将用户请求转换为标准 MCP 格式与 MCP Server 通信
• MCP Server： 作为服务模块，提供上下文、工具和提示，处理来自 Client 的请求并返回标准化的响应

它们之间的关系（如图 7-5）

图 7-5 MCP组成架构

一个用于与大模型对话并支持 MCP 的应用程序，我们就可以称之为 Host（本节中的应用程序未特殊说明均指的是 Host）。

应用程序中的 MCP Client 负责与 MCP Server 通信。

而 MCP Server，我们可以将它理解为一个服务，它可以提供 资源（Resources）、提示词（Prompts）、工具（Tools） 等。

• 资源（Resources）： 指的是可由 MCP Client 读取并用作大模型交互上下文的一组数据或内容。
• 提示词（Prompts）： 指的是可由 MCP Client 读取并用作大模型交互上下文的一组提示词模板。
• 工具（Tools）： 指的是可由 MCP Client 读取并可以被调用执行的外部工具（可以理解为函数）。

当然，我们这里着重介绍 Tools，这也是大多数人会关注的点。

假如我们开发了一个名字叫 weather 的 MCP Server，它有两个 Tool，即两个工具函数：

• get_weather(location,date)：获取天气方法
  • location：地点
  • date：时间
• get_current_date()：获取当前时间

针对 MCP Server，我们可以在本地启动一个 MCP Server，通过标准输入输出也就是 stdio 模式与我们要使用的支持 MCP Client 的产品通信，也可以使用 SSE 模式直接输入一个 MCP Server 链接以 HTTP 协议与我们要使用的支持 MCP Client 的产品通信。具体的使用可以参考各个应用程序的 MCP Server 配置文档。

当我们把这个 MCP Server 配置到应用程序中时（以 Claude Desktop 为例），Claude Desktop 中的 MCP Client 会尝试给这个 MCP Server 发送质询，如图 7-6。

图 7-6 MCP Client质询流程

整个质询流程结束后，MCP Client 就已经就绪了，它已经知道并记录了 MCP Server 所有能力，落实到程序中，其实就是 Client 向 Server 发送一段标准 JSON Schema，Server 收到后回复 Client 一段标准 JSON Schema。注意，这整个流程发生在用户发送问题之前的准备阶段，即打开 Claude Desktop 时或者是在 Claude Desktop 中新添加一个 MCP Server 时。

当用户在 Claude Desktop 中发送”北京今天天气“时：

• 首先 Claude Desktop 会将问题描述和当前所有 MCP Server Tools 的信息一起发送给大模型。
• 大模型觉得需要调用 get_current_date 获取今天的日期才行，于是解析 get_current_date 的 Tool 名、参数等信息发送给 Claude Desktop
• Claude Desktop 接收到调用 get_current_date 的信号后，其 MCP Client 会将调用信息发送给对应的 MCP Server 执行并拿到返回结果（2025-06-24）
• Claude Desktop 会将原始问题、get_current_date 返回结果、MCP Server Tools 信息再次发送大模型
• 大模型觉得还需要调用 get_weather 获取天气，于是解析get_weather的信息，将 Tool 名、参数（地点北京、时间 2025-06-24）发给 Claude Desktop
• Claude Desktop 接收到调用 get_weather 的信号后，其 MCP Client 会将调用信息发送给对应的 MCP Server 执行并拿到返回结果
• 还是重复的流程，Claude Desktop 会将原始问题、历史信息、get_weather 返回结果再次发送大模型
• 大模型收到后回复”今天是 2025-06-23 日，北京天气阴转晴“，再由 Claude Desktop 展现给用户

整个示例的 MCP 流程（如图 7-7）。

图 7-7 MCP调用流程

在整个交互流程中 MCP 协议仅作用于 MCP Client 和 MCP Server 之间，而是否调用、调用哪个 MCP Server 中的 Tool，取决于大模型的自主决策，这并不在 MCP 协议的范围内。

所以我们可以说 MCP 和大模型没有直接关系，它是一个处于大模型上层的协议，通过大模型的自主决策去选择调用。大模型收到 MCP Server 传递的丰富上下文（包含 Tool 列表、环境状态、用户输入等）后，会基于自身理解做出两类决策：

• 仅生成文本回复：若判断当前任务不需要调用外部工具，模型直接回复自然语言内容
• 生成 Tool 调用意图：若模型认为需要“行动”才能满足用户需求，它会生成标准化的 Tool 调用请求

这种调用意图是大模型基于上下文自主形成的，不同模型可能有不同的“行动偏好”，但 MCP 规范了其输出格式，基于标准输出格式就确保了 MCP Client 可以正确向 MCP Server 发送调用请求。

不同的应用程序，比如 Cursor、Claude Desktop、Cline 它们在处理大模型调用 MCP Server 的方式各不相同，最简单的就是靠提示词约束大模型的调用意图，甚至还可以通过 Function Calling 机制来实现大模型的 Tool 调用输出。

7.3.3 Function Calling VS MCP

虽然 Function Calling 和 MCP 从表面上看，都是让大模型“具备行动能力”，但它们的定位、作用、技术架构完全不同。

Function Calling 是一种大模型根据上下文自动选择调用并执行函数的机制。不同的模型厂商有不同的 Function Calling 实现，代码集成的方式也不一样，开发者需要考虑如何将函数暴露给大模型去调用。当我们想要为一个 AI 应用集成一些外部能力时，使用 Function Calling 需要我们为之开发一个个功能函数，尽管这些功能函数非常普遍我们依然要去重复造这个“轮子”。

但 MCP 不同，它是一个统一的标准，我们只需要按照 MCP 标准规范去开发 MCP Server，那么所有支持 MCP Client 的 Host 或者说应用程序，都可以去调用这个 MCP Server，真正做到了一次开发一劳永逸。当我们开发一个 AI 应用时，想要集成一些外部能力，甚至可以不去开发 MCP Server，只需要支持 MCP Client，市面上所有的开源 MCP Server 都可以接入进来。

如果大家都认可并且遵循这个规范，那么第三方只需要按照标准规范提供 MCP Server 就可以接入所有支持 MCP Client 的大模型或者说应用程序，标准统一的情况下，MCP Server 可以遇见的会越来越多，只要有足够多的 MCP Server，理论上大模型可以调用一切，与数据、文件系统、开发工具、Web 浏览器自动化、生产力工具等各种生态集成，实现强大的协作能力，它的价值不可估量，所以MCP异常火爆。

当然，这并不代表 Function Calling 就没用了，Function Calling 和 MCP 属于不同层面的东西，在使用 MCP 的同时，依然可以配合 Function Calling 去使用。应用可以选择在 MCP 之上通过 Function Calling 与模型交互，也可以在 MCP 范式下使用其他不基于 Function Calling 的方式与模型或数据源交互。

简单来说，MCP 与 Function Call 是两条并行的赛道，它们不互为前提条件，可以各取所需。