MCP 协议为什么被称作 AI 应用的 USB-C

MCP（Model Context Protocol，模型上下文协议）是 Anthropic 于 2024 年 11 月开源的开放协议，为 AI 应用与外部数据源和工具之间提供统一的连接标准，常被比作「AI 应用的 USB-C 接口」。在 MCP 出现之前，每个 AI 应用要接入 M 个数据源、每个数据源要适配 N 个应用，集成成本是 M×N；MCP 把它变成了 M+N——应用和资源方各自只需实现一次协议。本文整理自 MCP 官方文档（modelcontextprotocol.io）架构与概念章节（协议版本 2026-07-28）。

一、三大角色：Host、Client、Server

MCP 官方文档的定义（原文）：

角色	官方定义
MCP Host	协调并管理一个或多个 MCP 客户端的 AI 应用（如 Claude Code、Claude Desktop）
MCP Client	维持与 MCP Server 连接、并从 Server 获取上下文供 Host 使用的组件
MCP Server	向 MCP 客户端提供上下文的程序

MCP 遵循客户端-服务器架构：一个 Host 可连接一个或多个 Server，Host 为每个 Server 创建一个专属的 Client。官方举例：Visual Studio Code 作为 Host，连接 Sentry MCP Server 时实例化一个 Client 对象，再连接本地文件系统 Server 时会实例化另一个 Client 对象。

Server 的运行位置不受限制——本地服务器（如 Claude Desktop 启动的 filesystem server，STDIO 传输，运行在同一台机器）或远程服务器（如官方 Sentry MCP Server，运行在 Sentry 平台，Streamable HTTP 传输）皆可。

二、双层协议设计

官方文档将 MCP 概念上分为两层（原文：”Conceptually the data layer is the inner layer, while the transport layer is the outer layer.”）：

数据层（Data Layer）：定义基于 JSON-RPC 2.0 的客户端-服务器通信协议，包括能力与版本发现、核心原语（tools、resources、prompts）和通知机制；
传输层（Transport Layer）：定义使数据交换成为可能的通信机制与通道，包括传输特定的连接建立、消息分帧和授权。

传输层将通信细节从协议层抽象出来，使相同的 JSON-RPC 2.0 消息格式可跨所有传输机制使用。

三、服务端三大原语（Primitives）

官方文档强调：「MCP 原语是 MCP 中最重要的概念，它们定义了客户端和服务器能彼此提供什么。」

原语	官方定义	示例
Tools（工具）	AI 应用可以调用的可执行函数，用于执行动作	文件操作、API 调用、数据库查询
Resources（资源）	为 AI 应用提供上下文信息的数据源	文件内容、数据库记录、API 响应
Prompts（提示）	帮助构建与语言模型交互结构的可复用模板	系统提示词、少样本示例

每种原语都关联三类方法：*/list（发现）、*/get（检索）和 tools/call（执行）。

四、客户端原语与协议演进

当前有效的客户端原语是 Elicitation：「允许服务器向用户请求额外信息。当服务器作者想从用户那里获得更多信息、或请求对某个操作的确认时非常有用。」通过 elicitation/create 方法以多轮往返请求（MRTR）模式完成。

协议版本 2026-07-28 的重要变化——两个原语被标记为弃用：

Sampling（原「允许服务器请求客户端 AI 应用完成语言模型补全」）：官方建议新实现直接集成 LLM 提供商 API；
Logging（原「服务器向客户端发送日志消息用于调试」）：官方建议新实现记录到 stderr 或使用 OpenTelemetry。

五、无状态设计与发现机制

MCP 是无状态协议（原文：”MCP is a stateless protocol.”）：每个请求都在 _meta 字段中携带协议版本和相关能力，因此服务器可以独立处理每个请求。server/discover 请求完成三件事：

协议版本协商——版本不匹配时返回错误，客户端以双方支持的版本重试；
能力发现——双方声明各自能力，「不支持的操作永远不会被尝试」；
身份交换——用于调试与兼容性。

六、两种传输机制

传输方式	官方描述	典型场景
STDIO	使用标准输入/输出流在本地进程间直接通信，无网络开销、性能最优	本地运行的 Server
Streamable HTTP	用 HTTP POST 传输客户端到服务端的消息，可选 Server-Sent Events 实现流式；支持 bearer token、API key 等标准 HTTP 认证，官方推荐使用 OAuth 获取令牌	远程 Server

七、一次完整的交互生命周期

官方文档示例的典型流程：

Discovery：客户端发送 server/discover（响应通常可缓存）；
Tool Discovery：发送 tools/list，响应中每个工具对象包含 name（命名空间内唯一标识）、title（人类可读名称）、description（详细说明）和 inputSchema（JSON Schema 定义的输入参数）；
Tool Execution：发送 tools/call，name 必须与发现响应中的工具名完全一致，响应通过 content 数组返回文本、图片、资源等多格式内容；
Real-time Updates：订阅变更通知，当服务器的可用工具变化时收到提醒。

通知机制为 opt-in：客户端需在 subscriptions/listen 过滤器中声明关注的事件；通知是「尽力而为」的，客户端仍应依靠轮询保证结果新鲜度。协议还支持可选扩展，例如 Tasks 扩展——让服务器为长时间运行的请求返回持久句柄，客户端稍后轮询状态并取回结果。

八、MCP 的边界

官方文档明确：「MCP 只专注于上下文交换的协议——它不规定 AI 应用如何使用 LLM 或如何管理所提供的上下文。」MCP 项目包含协议规范、官方 SDK、开发工具（含 MCP Inspector 调试器）和参考 Server 实现。目前 Claude Desktop、Claude Code、Cursor、Zed 等主流 AI 应用均已原生支持 MCP，社区服务器生态快速增长。

九、深入 Tools：协议规范细节

三大原语中，Tools 是 Agent 场景最核心的一个。官方规范（版本 2026-07-28）的关键定义：

「MCP 允许服务器暴露可被语言模型调用的工具。工具使模型能够与外部系统交互，例如查询数据库、调用 API 或执行计算。每个工具由名称唯一标识，并包含描述其 schema 的元数据。」

两个重要的设计原则（原文）：

模型控制（model-controlled）：「语言模型可以基于对上下文的理解和用户的提示，自动发现和调用工具」；
人在环（human in the loop）：「出于信任与安全考虑，应当始终有人类在环，并有能力拒绝工具调用」。

工具发现（tools/list）的请求与响应示例（官方规范原文）：

// 请求
{
  "jsonrpc": "2.0", "id": 1,
  "method": "tools/list",
  "params": { "cursor": "optional-cursor-value" }
}

// 响应
{
  "jsonrpc": "2.0", "id": 1,
  "result": {
    "resultType": "complete",
    "tools": [
      {
        "name": "get_weather",
        "title": "Weather Information Provider",
        "description": "Get current weather information for a location",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": { "type": "string", "description": "City name or zip code" }
          },
          "required": ["location"]
        }
      }
    ],
    "nextCursor": "next-page-cursor",
    "ttlMs": 300000,
    "cacheScope": "public"
  }
}

规范要求服务器必须以确定性顺序返回工具列表（「相同的工具集合在多次请求中保持相同排序」），因为这能让客户端可靠地缓存列表，并提高工具列表进入模型上下文时的 LLM 提示缓存命中率。

工具执行（tools/call）的请求与响应示例（官方规范原文）：

// 请求
{
  "jsonrpc": "2.0", "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "New York" }
  }
}

// 响应
{
  "jsonrpc": "2.0", "id": 2,
  "result": {
    "resultType": "complete",
    "content": [
      { "type": "text", "text": "Current weather in New York:\nTemperature: 72\u00b0F\nConditions: Partly cloudy" }
    ],
    "isError": false
  }
}

双错误机制

规范定义了两类错误，处理方式截然不同：

错误类型	适用场景	返回方式	给模型吗？
协议错误 Protocol Errors	未知工具、请求格式不合规、服务器错误	标准 JSON-RPC 错误（如 code -32602）	可以提供，但模型较难自我修复
工具执行错误 Tool Execution Errors	API 失败、输入校验失败（日期格式错误等）、业务逻辑错误	结果中 isError: true + 可操作的文本反馈	应当提供——模型可自我纠正并用调整后的参数重试

安全要求清单

官方规范的原文要求（MUST / SHOULD 级别）：

服务器必须（MUST）：验证所有工具输入；实现适当的访问控制；对工具调用限流；净化工具输出；
客户端应当（SHOULD）：敏感操作前请求用户确认；调用服务器前向用户展示工具输入（避免恶意或意外的数据外泄）；将结果传给 LLM 前先验证；为工具调用实现超时；记录工具使用日志以备审计。

此外，规范还支持 outputSchema（工具输出也用 JSON Schema 约束）、structuredContent（结构化内容与文本内容并存）以及 InputRequiredResult（工具执行中途向用户征求输入的多轮机制）等进阶能力。

参考来源

MCP 官方文档：架构（modelcontextprotocol.io/docs/concepts/architecture）
MCP 官方文档：入门介绍（modelcontextprotocol.io/docs/getting-started/intro）
MCP 规范与 SDK（github.com/modelcontextprotocol）

本文为技术文档摘录整理，内容合并自下列官方资料（官方文档、官方 GitHub 仓库、论文与权威媒体报道），技术数字以官方原文为准，版权归原作者所有。