MCP

MCP 最新版规范 (2026-07-28)

模型上下文协议新版规范发布，带来了无状态协议核心、多往返请求（MRTR）、基于头部的路由、可缓存的列表结果、授权强化、正式扩展框架以及更新的 Tier 1 SDK。

admin

• 6 min read
MCP 最新版规范 (2026-07-28)
AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

自去年十一月发布以来，MCP 以惊人的速度持续增长。在我们的 Tier 1 SDK 中，每月下载量接近五亿次，TypeScript 和 Python SDK 的总下载量都突破了 10 亿次大关。在短短几个月内，该协议继续作为代理工作流的数据和交互基础层而增长。

今天，我们正式按下发布按钮，推出下一版本的 MCP 规范 2026-07-28，以及让您能够立即开始构建客户端和服务器的 SDK。

此版本的亮点是无状态协议核心——MCP 正从双向有状态协议转变为请求/响应无状态协议。这是开发者最高度要求的功能之一，他们渴望为其 MCP 服务器获得更好的可靠性和可扩展性。

当然，我们在此版本中介绍的内容不止于此：

  • 每个请求都是自描述的，对于想要预先获取能力的客户端提供可选的发现调用，因此任何请求都可以通过普通轮询负载均衡器落地到任何实例。
  • 方法和工具名称通过 Mcp-Method 和 Mcp-Name HTTP 头传输，因此网关可以直接在头部上进行路由和授权。
  • 服务器到客户端的请求（如采样和引出）正在重新设计为使用多往返请求 (MRTR)，消除了对持续打开的双向流的需求。
  • 列表响应携带缓存提示和确定性顺序，因此客户端可以缓存工具目录并在重连时保持上游提示缓存稳定。
  • 正式锁定在适当的扩展框架上，任务与其他扩展（如 MCP 应用程序和企业托管授权 (EMA)）一起加入。
  • 一组授权强化变更，包括 RFC 9207 发行者验证，以及从动态客户端注册 (DCR) 正式转向客户端元数据文档 (CIMD)。
  • 正式弃用策略，最短窗口期为十二个月，以便您可以计划升级而不是被动应对。

TypeScript、Python、Go 和 C# SDK 已更新以匹配，带有针对破坏性变更的详细迁移说明——您现在就可以开始使用新规范。

1、变更内容

1.1 不再有握手或会话

随着新规范版本的发布，我们正式弃用了 initialize/initialized 交换以及 Mcp-Session-Id 头（参考 SEP-2575、SEP-2567）。现在每个请求独立传输，在 _meta 中携带其协议版本、客户端身份和客户端能力。如果客户端想在执行任何操作之前了解服务器的能力，有一个新的 server/discover 远程过程调用 (RPC)；但是，它不是必需的。现在任何请求都可以通过普通轮询负载均衡器落地到任何服务器实例，无需共享存储。

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

删除协议级会话不会强制您的应用程序成为无状态的。如果您的服务器需要在调用之间保持状态，请从工具中生成一个显式句柄，并让模型将其作为参数传回。我们发现这比隐藏在传输中的会话状态更好——模型可以看到句柄并在工具之间传递它。

1.2 多往返请求 (MRTR)

MRTR 取代了之前需要保持打开流的服务器发起的 elicitation/create、sampling/createMessage 和 roots/list 请求。

有时工具需要在调用过程中从用户那里获取某些内容，例如确认或缺失的参数。MRTR (SEP-2322) 在无状态协议上启用此场景：服务器返回 resultType: "input_required" 以及需要回答的请求，客户端使用附加在 inputResponses 中的答案重试原始调用。

1.3 基于请求头的路由

可流式传输的 HTTP 请求现在必须包含 Mcp-Method 和 Mcp-Name (SEP-2243)。您的网关、速率限制器或 WAF 可以在这些头上进行路由和计量，而不是解析 JSON 主体。

1.4 列表结果可缓存

tools/list、prompts/list、resources/list 和 resources/read 的响应现在携带 ttlMs 和 cacheScope (SEP-2549)。这允许客户端确定响应的最佳缓存策略，并减少不必要的重新获取。

1.5 授权

根据过去一年与实施者的讨论，授权是实施者花费最多集成时间的地方。通过此规范修订，我们继续发展 MCP 认证和安全态势。

  • 授权服务器应根据 RFC 9207 返回 iss 参数，客户端必须在兑换代码之前验证它 (SEP-2468)。这关闭了授权服务器混淆漏洞。
  • 客户端在动态客户端注册 (DCR) 期间设置 application_type，以便授权服务器停止拒绝桌面和 CLI 应用程序的 localhost 重定向 (SEP-837)。如果您曾经想知道为什么 CLI 客户端的 OAuth 流程收到 redirect_uri 错误，这可能就是原因。虽然我们正在转向客户端 ID 元数据文档 (CIMD) 作为标准，但这是使协议符合 OAuth 规范要求的强化措施。
  • 客户端凭据绑定到铸造它们的发行者。不能跨授权服务器重用 (SEP-2352)。
  • 动态客户端注册本身现在正式弃用，转而支持 CIMD。DCR 继续为向后兼容而工作，但将在未来版本的 MCP 规范中删除。

1.6 任务

任务从实验核心移至 io.modelcontextprotocol/tasks 扩展，采用基于轮询的 tasks/get 和新的 tasks/update (SEP-2663)。变更通知从旧的 HTTP GET 端点移至客户端按通知类型选择加入的单个 subscriptions/listen 流。

1.7 弃用

Roots、Sampling 和 Logging 已弃用 (SEP-2577)。它们仍然有效，并且至少在十二个月内会继续工作。新实现不应采用它们。遗留的 HTTP+SSE 传输也被认为正式弃用，具有一年的过渡期。

2、SDK

所有四个 Tier 1 SDK 从今天开始支持 2026-07-28：

  • TypeScript
  • Python
  • Go
  • C#

除了 Tier 1 集合之外，Rust SDK 也支持新规范的 beta 版本。

SDK 实现了允许您使用新规范版本构建服务器和客户端的 API。正如我们在 SDK beta 博客文章中提到的，会有一些迁移成本，特别是对于依赖会话标识符的开发者；但是，我们纳入了早期测试反馈，使此过程变得更容易。

3、快速开始

我们很高兴开发者在新规范上构建。要开始，请参考以下资源：

原文链接: The 2026-07-28 Specification

汇智网翻译整理，转载请标明出处