MCP规范概览

模型上下文协议（MCP）是大型语言模型与分散数据源体系之间的接口层。过去，将LLM连接到特定数据库、文件系统或内部API需要为该特定的模型-应用对编写定制适配器。随着模型数量 ($N$) 和数据源数量 ($M$) 的增长，维护这些点对点集成的复杂程度呈指数级增长 ($N \times M$)。

MCP通过严格界定一份契约来解决此可扩展性问题。任何实现了MCP规范的服务器都能与任何遵循MCP的客户端通信。这使得复杂程度从指数曲线变为线性曲线 ($N + M$)，开发人员只需为某个数据源构建一次服务器，即可使其普遍适用于受支持的AI助手。

上下文的标准化

该规范不规定AI模型如何处理信息或数据库如何存储数据。相反，它对用于交换信息的传输和消息格式进行了标准化。这种架构模式类似于HTTP标准化网络通信的方式；浏览器（客户端）无需了解Web服务器的内部逻辑即可渲染页面，只要两者都遵循HTTP标准即可。

在MCP架构中，该规范规定通信通过定义的传输层，使用JSON-RPC 2.0消息进行。该协议原则上与传输方式无关，但当前优先考虑本地进程的标准输入/输出 (Stdio) 和远程HTTP连接的服务器发送事件 (SSE)。

下图阐明了从直接集成到基于协议方法的结构性转变。

直接多对多集成与集中式协议方法的比较。

核心原语

MCP规范将所有交互分为三种主要原语。这些原语决定了数据如何呈现以及模型如何与服务器交互。遵循规范的服务器可以根据具体应用场景，实现其中一个、两个或全部三个原语。

资源

资源代表客户端可读取的被动数据。它们的功能类似于REST API中的GET请求或文件系统中的文件读取。资源为模型提供上下文，例如日志文件的内容、数据库模式或变量的当前状态。

资源通过URI（统一资源标识符）识别。服务器定义可用资源列表，客户端通过URI请求特定资源的内容。此原语仅用于读取数据；它不产生副作用，也不修改系统状态。

提示

提示是预定义模板，协助引导用户与模型之间的交互。资源提供原始数据，而提示提供结构化指令。MCP服务器可以呈现一个提示库，客户端应用可以向用户显示这些提示。

例如，连接到代码仓库的服务器可能会呈现一个名为review-code的提示，该提示自动提取相关文件内容（资源），并将其包装成指令，供LLM进行代码审查。这有助于标准化与特定数据源交互的最佳实践。

工具

工具是可执行函数，使模型能够执行操作或获取需要计算的动态信息。与资源不同，工具可能产生副作用。它们相当于POST请求或函数调用。

当服务器呈现一个工具时，它必须提供定义预期参数的JSON Schema。LLM使用此schema生成正确的输入参数。客户端随后在服务器上执行该工具，并将结果返回给模型。这是使代理能够执行诸如使用特定参数查询数据库或在项目管理系统中创建工单等任务的主要机制。

能力与生命周期

该协议强制执行严格的初始化生命周期。在任何数据交换之前，客户端和服务器必须执行握手。在此阶段，双方交换一个能力对象。

能力对象声明了支持哪些功能。例如，服务器可能声明支持resources和tools，但不支持prompts。此外，它还可能声明支持logging或sampling。这种协商确保了向下兼容性，并允许客户端在服务器不支持特定功能时优雅降级。

从数学角度看，我们可以将能力协商视为集合的交集。设 $C_{client}$ 为客户端支持的功能集合， $C_{server}$ 为服务器支持的功能集合。会话的活动功能集合 $F$ 为：

$F = C_{client} \cap C_{server}$

这确保了双方都不会尝试调用对方无法处理的协议方法。

安全模型

MCP规范将安全边界置于传输连接层面。该协议本身不在JSON-RPC消息中强制执行用户身份验证（如OAuth）。相反，它假定传输层是安全的，或者服务器运行在受信任的环境中（例如用户启动的本地进程）。

访问控制由主机应用（客户端）管理。客户端负责在向服务器发送敏感数据或允许服务器执行可能修改系统状态的工具之前请求用户许可。这种设计使服务器实现保持简洁，同时将安全决策集中在面向用户的应用中。

控制流显示了用户操作和LLM上下文需求如何对应到特定的MCP原语。

错误处理与日志记录

可靠性是此规范的组成部分。该协议定义了基于JSON-RPC规范的标准错误码和消息结构。当工具执行失败或资源不可用时，服务器必须返回结构化错误响应，而不是静默失败或导致连接崩溃。

此外，MCP包含一个专用的日志原语。这允许服务器将日志消息（调试、信息、警告、错误）推送到客户端。在开发环境中，这些日志会显示在主机的调试控制台中（例如MCP Inspector），从而提供服务器内部状态的可见性，而不会污染用于协议通信的标准输出流。