图解｜MCP 与你上班每天用的API有啥不一样？

“模型上下文协议”（MCP）出来应该有一年了，今天我们来简单看看它到底是个什么"东西”。

以下内容都翻译自：https://blog.dailydoseofds.com/p/visual-guide-to-model-context-protocol 为了阅读顺畅略有修改。

MCP它不是个"东西"，呃，好像也不能这么说，简单来说，MCP 就像是你的 AI 应用的 USB-C 接口。USB-C 为各种设备和配件提供了标准的连接方式，让配件能连上电脑等设备，而 MCP 也一样，它为你的 AI 应用连接不同的数据源和工具（比如数据库、API、本地文件等）提供了一套标准化的方法。

img

im

从技术层面深入一点看，MCP 的核心是一种客户端-服务器（client-server）架构，在这种架构下，一个主应用程序可以连接到多个不同的服务器。

核心组件

它主要由三个关键部分组成：

• 主机 (Host)
• 客户端 (Client)
• 服务器 (Server)

在我们深入之前，先看一张总览图：

img

主机 (Host)：代表任何一个 AI 应用（比如 Claude 客户端、Cursor 等）。它为 AI 的交互提供了运行环境，能够访问工具和数据，并且运行着 MCP 客户端。

MCP 客户端 (Client)：在主机内部运行，主要负责和 MCP 服务器进行沟通。

img

最后，MCP 服务器 (Server)暴露特定的能力，并提供对如下数据的访问：

img

• 工具 (Tools)：让大语言模型（LLM）能通过你的服务器来执行某些动作。
• 资源 (Resources)：把你服务器上的数据和内容开放给大语言模型使用。
• 提示词 (Prompts)：创建可以重复使用的提示词模板和工作流。

MCP的客户端与服务器如何沟通？

要自己搭建 MCP 服务，理解MCP客户端和服务器之间的沟通方式至关重要。

我们先来看一张示意图，然后再一步步拆解：

img

首先，我们进行**能力交换 (capability exchange)**，过程如下：

• 客户端发送一个初始请求，以了解服务器的能力。
• 服务器随后会用其能力详情进行响应。
• 例如，一个天气 API 服务器在被调用时，可以回复其拥有的可用“工具”、“提示模板”以及任何其他可供客户端使用的资源。

一旦这个交换完成，客户端会确认连接成功，然后进一步的消息交换将继续进行。

这就是这种设置如此强大的原因之一。

在传统的 API 设置中：

如果你的 API 最初需要两个参数（例如，提供天气信息的服务端API需要 location 和 date两个参数），用户会在集成API的应用程序中用这两个确切的参数来发送请求来获取天气信息。

后来，如果你决定增加第三个必填的参数（例如，unit 用于表示温度单位，如摄氏度或华氏度），此时API 的定义就发生了改变。

这意味着所有使用你 API 的用户都必须更新他们的代码以包含这个新参数。如果他们不更新，他们的请求可能会失败、返回错误或提供不完整的结果。

MCP 的设计通过以下方式解决了这个问题：

• MCP 引入了一种动态且灵活的方法，这与传统 API 的方式形成鲜明对比。
• 例如，当一个客户端（例如像 Claude 桌面版这样的 AI 应用）连接到一个 MCP 服务器（例如你的天气服务）时，它会发送一个初始请求来了解服务器的能力。
• 服务器会响应其可用工具、资源、提示和参数的详细信息。例如，如果你的天气 API 最初支持 location 和 date，服务器会在其能力中传达这些信息。

如果你之后添加了一个 unit 参数，MCP 服务器可以在下一次交换中动态地更新其能力描述。客户端不需要硬编码或预定义这些参数——它只需查询服务器当前的能力并相应地进行调整。

通过这种方式，客户端可以动态地调整其行为，使用更新后的能力（例如，在请求中包含 unit），而无需重写或重新部署代码。

这就是MCP与传统API的差异，后面有时间了再跟大家分享MCP的使用场景，还有如何创建自定义的 MCP 服务器。