图解 MCP

在之前的多篇文章中我们已经讨论过 MCP。但最近后台又收到一些读者关于 MCP 的疑问。

今天再使用两个类比，然后从技术的角度，希望能在 3 分钟内说清楚 MCP。

类比 1：语言学习

想象一下，你只会说英语。

• • 如果要向只懂法语的人获取信息，你就必须学法语；
• • 如果要向只懂德语的人获取信息，你就必须学德语；
• 
  
  

如此往复。

按照这种沟通方式，就算只学五门语言也会让人头疼不已！

但假如你有一位能听懂所有语言的翻译呢？

你只需要和翻译对话；

它能推断出你想了解的信息；

它能帮你选择要沟通的人；

它还能为你获取并转述回应。

这位“翻译”就好比 MCP！

它让你（Agent）通过一个统一的接口，与其他人（工具）进行对话。

在 Agent 的使用场景中，集成单个工具或 API 往往意味着要阅读文档、编写适配代码——就像要学一门新语言。

为简化这一过程，各大平台纷纷推出 MCP 服务器，开发者只需接入它们，Agent 就能立即使用相应的工具/API。

类比 2: USB-C

也可以将 MCP 看作是你的 AI 应用上的 USB-C 接口。

正如 USB-C 为各类设备与配件提供了一个标准化的连接方式，MCP 标准化了你的 AI 应用与不同数据源、不同工具之间的对接方式。

技术的视角

实现流程

MCP 并非在每个应用或 Agent 内部硬编码工具，而是通过以下方式实现：

• • 标准化工具的定义、托管和向 LLM 的暴露方式。
• • 让 LLM 能够轻松地发现可用工具、理解它们的模式（schema）并加以使用。
• • 在调用工具之前，提供审批与审计的工作流。
• • 将工具的实现（implementation）与使用（consumption）职责分离。

下面是一张说明该流程的图示：

MCP 服务器在右上角展示了一些工具。整个流程如下：

1. 1. 用户向 MCP 客户端（MCP Client）发送查询输入，同时将可用工具信息也一并传入客户端。
2. 2. MCP 客户端将查询和工具列表一起发送给 LLM。
3. 3. LLM 根据输入决定调用哪个工具、使用哪些参数，并将调用指令返回给 MCP 客户端。
4. 4. MCP 客户端向用户请求批准使用该工具。
5. 5. 用户批准后，MCP 客户端向 MCP 服务器（MCP Server）发送调用请求，并附上调用参数。
6. 6. MCP 服务器调用相应工具。
7. 7. 工具执行完毕后，将输出结果返回给 MCP 服务器，再由其转发给 MCP 客户端。
8. 8. MCP 客户端将工具输出和原始查询一起发送给 LLM。
9. 9. LLM 基于这些信息生成最终输出。

为什么这很重要？

下面是这种架构强大之处的一个例子：

假设你开发了一个天气查询 API。

在传统 API 模式下：

1. 1. 如果 API 最初需要两个参数（如地点和日期），用户会在各自应用中硬编码这两个参数来发送请求。

1. 2. 后来如果你要新增第三个必需参数（例如温度单位：摄氏度或华氏度），API 的契约就变了。

1. 3. 这意味着所有用户都必须更新各自的代码以加入新参数；否则，他们的请求可能会失败、返回错误或结果不完整。

而在 MCP 架构下：

1. 1. 客户端（例如 Claude Desktop）连接到 MCP 服务器（如你的天气服务）时，会先发送一个“能力查询”请求。
2. 2. 服务器会返回当前支持的工具、参数及相关说明。例如，如果最初仅支持地点和日期，这些信息会在响应中告知客户端。
3. 3. 如果你后来新增“温度单位”参数，MCP 服务器将在下次能力查询时动态更新它的能力描述。
4. 4. 客户端无需修改代码，只要在运行时重新查询服务器能力，就能识别并使用新的参数。

如此一来，客户端可以“随需应变”，在不改写或重新部署代码的前提下，动态适配最新的工具能力。

以上就是 MCP 的核心功能介绍。

希望通过这篇文章能让你搞懂 MCP ！