关于模型上下文协议（MCP）的讨论近段时间热度极高，今天我们就来深入解析它的本质。我们可以将其视为AI应用中的“USB-C接口”——如同USB-C标准化了设备与各类配件的连接，MCP在AI应用与数据源、工具之间构建了一套统一且标准化的沟通协议。

从技术架构来看，MCP的核心基于客户端-服务器设计：一个主机应用能够同时连接多个服务器。它主要由三个关键组件构成：主机（Host）、客户端（Client）以及服务器（Server）。

先通过一张整体概览图来帮助理解全局框架。

三大组件各自的分工

主机（Host）
指的是任何提供AI交互运行环境的应用程序，例如Claude桌面、Cursor这类工具。主机负责运行MCP客户端，并能够访问各类工具与数据资源。

MCP客户端（Client）
运行于主机内部，专门负责与MCP服务器进行通信。它充当了主机与服务器之间的桥梁与连接枢纽。

MCP服务器（Server）
负责提供具体的功能实现与数据访问能力，其内部包含三个核心组成部分：

• 工具：使大语言模型能够通过服务器执行具体操作
• 资源：向LLM公开服务器中存储的数据与内容
• 提示：创建可重复使用的提示模板与工作流

客户端与服务器的通信机制

要动手搭建自己的MCP客户端与服务器，关键在于理解客户端的通信流程。以下是逐步拆解的具体步骤：

首先是能力交换阶段：

1. 客户端发送初始请求（Initial Request），向服务器询问其所具备的能力。
2. 服务器回应自身的能力详细信息（Initial response）。

举例来说：当请求一个天气API服务器时，服务器会返回它能够提供的“工具”、“提示模板”以及相关资源。完成能力交换后，客户端确认连接成功，并开始后续的消息交互。

MCP与传统API的核心差异

这种设计的主要优势体现在哪里？与传统API进行对比就能一目了然。

在传统API模式下：如果你的API最初只要求两个参数（例如地点和日期），用户会将这些参数硬编码到请求中。但随后你新增了一个必要的参数（比如温度单位——摄氏还是华氏），那么API的接口契约就发生了改变。

这意味着所有使用该API的用户都必须更新代码才能适配新的参数。否则，请求可能失败、返回错误，或者给出不完整的响应结果。

而MCP则引入了一种更为动态、灵活的机制：

• 当一个客户端（比如Claude桌面这类AI应用）连接到某个MCP服务器（例如天气服务）时，它会先发起初始请求，获取服务器当前支持的能力信息。
• 服务器返回它会提供的工具、资源、提示以及参数详情。例如，最初仅支持地点和日期，服务器就将这些信息作为能力的一部分告知客户端。
• 如果后续你新增了“单位”参数，MCP服务器只需在下一次能力交换时动态更新自己的描述即可。客户端无需硬编码任何参数——它只需要查询服务器当前的能力，然后自行适配。

这样一来，客户端可以即时调整自身行为，使用更新后的能力（例如在请求中自动加入“单位”参数），整个过程中完全不需要修改或重新部署任何代码。

未来我们将继续探索如何创建自定义MCP服务器，并围绕它们搭建实际应用案例。敬请期待。