MCP（Model Context Protocol）协议机制调研

调研/复核日期：2026-07-29 证据来源：以 MCP 官方 specification、正式 tag 和 changelog 为主；二手材料单独标注。

当前稳定 spec 版本：2026-07-28（正式 tag 2026-07-28 已发布）。它相对 2025-11-25 有破坏性变化：协议核心改为无状态，移除初始化握手、HTTP 会话和 GET 事件流，并引入 MRTR、server/discover、标准请求头、缓存语义与正式扩展机制。旧实现不能只改版本号，必须按迁移规则兼容。

1. 传输层（Transport）

两种标准传输都承载 UTF-8 JSON-RPC 2.0：

stdio：client 启动 server 子进程；每行一条消息，消息内不得包含换行。server 只能向 stdout 写 MCP 消息，日志写 stderr。2026 版仍使用同一条双向字节流，但连接/进程不代表会话，server 不得从此前请求推断上下文。

Streamable HTTP：单一 MCP endpoint（如 /mcp）只要求支持 POST。每个 request/notification 都用新的 POST；request 的响应可以是单个 application/json 对象，或与该请求绑定的 text/event-stream。长期通知通过 POST subscriptions/listen 建立 SSE 响应流，不再使用独立 GET 流。

2026 版的关键约束：

• 删除 Mcp-Session-Id、HTTP GET/DELETE 会话操作、SSE event ID 和 Last-Event-ID 续传；断流后必须用新 JSON-RPC ID 重发。
• 每个 POST 必须带 MCP-Protocol-Version；每个 JSON-RPC request 还必须带 Mcp-Method，tools/call、resources/read、prompts/get request 另带 Mcp-Name。本版 core 不定义经 HTTP 发出的 client notification，因此也未定义其 method header 要求。body 是事实源，header 缺失、格式错误或与 body 不一致时返回 HeaderMismatch（-32020）。
• server 必须验证出现的 Origin；非法值返回 HTTP 403。公开部署还必须做鉴权，本地部署应只绑定 loopback。
• SSE 可发送 comment 作为 keep-alive；关闭某个 request 的 SSE 响应流即取消该请求。

向后兼容分两个“时代”：2025-11-25 等版本仍使用 initialize/session/GET SSE；2024-11-05 使用已弃用的双端点 HTTP+SSE。client 应按官方 versioning/transport fallback 流程探测，不能把任意 4xx 都当成同一种旧协议。

2. 消息层与无状态生命周期

消息仍分 request（有 id）、response（result 或 error）与 notification（无 id）。2026 版移除了 initialize、notifications/initialized 和连接级 capability 协商；每个 request 都在 _meta 中携带协议版本和 client capability：

{"jsonrpc":"2.0","id":"discover-1","method":"server/discover","params":{"_meta":{
  "io.modelcontextprotocol/protocolVersion":"2026-07-28",
  "io.modelcontextprotocol/clientInfo":{"name":"ExampleClient","version":"1.0.0"},
  "io.modelcontextprotocol/clientCapabilities":{}}}}

server 必须实现 server/discover，返回支持版本、capabilities、身份信息以及缓存字段；client 可选择调用，也可直接发业务 RPC 并处理 UnsupportedProtocolVersionError（-32022）。所有成功 result 新增必需的 resultType：通常为 "complete"，需要补充输入时为 "input_required"；为兼容旧 server，缺失时按 "complete" 处理。

2026 版不再允许 server 主动发 JSON-RPC request。需要 sampling、elicitation 或 roots 输入时，server 返回 InputRequiredResult；client 收集输入后，用新 request ID、原参数、inputResponses 和原样回传的 requestState 重试。这就是 Multi Round-Trip Requests（MRTR）。

3. 核心原语

• Tools：tools/list 发现、tools/call 调用。inputSchema/outputSchema 采用完整 JSON Schema 2020-12；structuredContent 可为任意 JSON 值。描述、annotations 和结果都应视为不可信输入。
• Resources：URI 寻址的数据与上下文，由宿主应用驱动读取；resources/read 可返回文本或二进制内容。
• Prompts：server 提供、由用户/宿主选择的模板化消息；通过 prompts/list、prompts/get 使用。
• Elicitation：server 请求用户或外部流程补充信息；2026 版通过 MRTR 承载，不再是 server 主动 RPC。
• Subscriptions：subscriptions/listen 订阅 tools/prompts/resources 的变化通知；它是长生命周期 request，不是会话。
• Caching：tools/list、prompts/list、resources/list/read 等返回 ttlMs 与 cacheScope（public/private），与 listChanged 通知互补。
• Extensions：以 reverse-DNS ID 独立协商和版本化。官方扩展包括 MCP Apps（sandboxed iframe UI）和重新设计的 Tasks；Tasks 已从实验性 core 移出，使用 tasks/get、tasks/update、tasks/cancel，没有 tasks/list。

Roots、Sampling、Logging 与 OAuth Dynamic Client Registration 在 2026-07-28 标记为 Deprecated，仍可用但新实现不应采用；最早移除时间为 2027-07-28 及之后的正式版本。Sampling 的推荐替代是 server 直接集成模型 API。

4. 鉴权（远程 HTTP）

MCP server 是 OAuth 2.1 protected resource，授权服务器（AS）独立发现。关键要求：

• 用 RFC 9728 Protected Resource Metadata 发现 AS；AS metadata 可来自 RFC 8414 或 OpenID Connect Discovery。
• authorization 与 token request 都必须带 RFC 8707 resource，token 必须绑定目标 MCP server；禁止 token passthrough。
• Client ID Metadata Documents（CIMD）是无预注册关系时的优先注册方式；RFC 7591 DCR 仅作为兼容 fallback，2026 版已弃用。
• AS 应按 RFC 9207 返回 iss；client 必须校验出现的 iss 与已记录 issuer 完全匹配。PKCE、精确 redirect URI、scope 最小化仍是基础要求。
• 无效/过期 token 返回 401；scope 不足返回 403，并可用 WWW-Authenticate 触发 step-up authorization。

stdio 不应使用这套 HTTP OAuth 流程，凭证应通过环境或本地安全机制取得。

5. 治理与生态边界

MCP 已由 Linux Foundation 旗下 Agentic AI Foundation 托管，属于跨厂商协议。生态采用情况可以通过官方 registry 与各厂商实现判断，但“server 数量”受聚合器、重复项和私有部署影响；没有可复现快照时，不应引用 8,000–12,000 之类精确区间。

6. 安全相关面

• 工具描述/schema/返回值中的 prompt injection 与 tool poisoning。
• server 接入后改变工具定义或行为的 rug pull；缓存使变更检测策略更重要。
• OAuth confused deputy、issuer mix-up、token passthrough 与 audience 混淆。
• 多 server 下的工具重名、shadowing 和错误路由。
• MCP Apps 的 iframe sandbox、消息桥权限与 UI 发起工具调用的同意边界。
• 显式 state handle 泄露或跨用户复用；cacheScope 错配导致跨租户缓存泄露。
• 不可信 resources/prompts 与私有数据、外发工具组合形成的“lethal trifecta”。

引用清单

• MCP 2026-07-28 specification
• 2026-07-28 changelog
• Streamable HTTP transport
• Authorization specification
• Deprecated features registry
• Official tag 2026-07-28

关联

• 与 A2A 的定位区分见 a2a-protocol.md：MCP 主要连接 agent 与工具/数据，A2A 连接独立 agent。
• MCP 的 SSE 只是 Streamable HTTP 的一种响应形式，不应概括为“MCP 基于 SSE”。安全议题后续与 agent-security/ 下的 prompt injection/tool-use abuse 笔记交叉分析。