直白点说，MCP 就像是 AI 应用的 USB-C 接口。

就跟 USB-C 能以标准化的方式把各种设备和配件连接起来一样，MCP 也把 AI 应用连接到不同数据源和工具的方式给标准化了。

咱们再深入一点，从技术角度瞅瞅。

说到底，MCP 采用的是客户端 - 服务器架构，一个宿主应用可以连接到多个服务器。

它有三个关键组成部分：

• 宿主
• 客户端
• 服务器

在深入之前，先大致瞅瞅它们的概览👇

宿主 代表任何 AI 应用（比如 Claude 桌面版、Cursor），它为 AI 交互提供环境，访问工具和数据，并运行 MCP 客户端。

MCP 客户端 在宿主内部运行，用来和 MCP 服务器进行通信。

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

• 工具：让 LLM（大型语言模型）能够通过你的服务器执行操作。
• 资源：将服务器上的数据和内容暴露给 LLM。
• 提示模板：创建可复用的提示模板和工作流。

搞清楚客户端和服务器之间的通信，对于构建自己的 MCP 客户端 - 服务器来说至关重要。

那咱们就瞅瞅它们是怎么通信的。

在一步步拆解之前，先看看下面这张图…

首先，是能力交换：

• 客户端发送一个初始请求，去了解服务器的能力。
• 然后服务器回复它的能力详情。
• 比如说，一个天气 API 服务器被调用时，就可以回复可用的“工具”、“提示模板”以及任何其他资源，供客户端使用。

完成这个交换后，客户端就会确认连接成功，之后就可以继续进一步的消息交换了。

这玩意儿厉害的地方就在于：

在传统的 API 设置里：

• 假如你的 API 最初需要两个参数（比如天气服务的 location 和 date），用户就得按照这些精确的参数来集成他们的应用。

• 后来，要是你决定再加一个必填的参数（比如温度单位的 unit，是摄氏度还是华氏度），API 的契约就变了。

• 这就意味着，所有使用你 API 的用户都得更新他们的代码，把新参数加进去。要是他们不更新，请求可能就会失败，报错，或者返回不完整的结果。

MCP 的设计是这样解决这个问题的：

• MCP 引入了一种动态且灵活的方法，和传统的 API 形成鲜明对比。
• 比如说，当一个客户端（比如像 Claude Desktop 这样的 AI 应用）连接到一个 MCP 服务器（比如你的天气服务）时，它会发送一个初始请求，去了解服务器的能力。
• 服务器会回复它可用的工具、资源、提示和参数的详情。比如，要是你的天气 API 最初支持 location 和 date，服务器就会把这些作为它的能力的一部分进行沟通。

• 要是后来你加了一个 unit 参数，MCP 服务器可以在下一次交换时动态更新它的能力描述。客户端不需要硬编码或者预先定义参数——它只需要查询服务器当前的能力，然后相应地调整就行。

• 这样一来，客户端就可以在运行时调整自己的行为，使用更新后的能力（比如在请求中加上 unit），而不需要重写或者重新部署代码。

希望这能帮你搞清楚 MCP 是干啥的。

本专栏将继续探索创建自定义的 MCP 服务器，并且动手搞一些演示，记得关注哦！