MCP(Model Context Protocol)官方于 2026-07-28 发布新规范,取代 2025-11-25,这是它自诞生以来改动最大的一次修订,核心是重构传输层与生命周期,而非往上堆特性。

背景:旧版握手与有状态会话

旧版(2025-11-25 及更早)Streamable HTTP 交互流程:

  1. 客户端发 initialize 握手,服务端返回能力集。
  2. 客户端再发 notifications/initialized。
  3. 服务端下发 Mcp-Session-Id,之后每个请求都得带上。

代价:

  • 会话 ID 只在签发它的机器上有效,水平扩容要么开 sticky session,要么集群共享会话存储。
  • 连接一断状态就没了,客户端得重新握手。
  • 网关/限流器想知道请求在干什么,只能解开 JSON-RPC body。

无状态协议内核

  • SEP-2575 删除握手,SEP-2567 删除协议级会话与 Mcp-Session-Id。
  • 协议版本、客户端身份、能力全部放进 _meta 键(io.modelcontextprotocol/protocolVersion、/clientInfo、/clientCapabilities),版本对不上返回 UnsupportedProtocolVersionError。
  • 一次工具调用完全自包含,普通轮询负载均衡即可,不需要共享存储或会话亲和。

容易漏的一点:SEP-2575 同时移除了 SSE 流的可恢复能力,Last-Event-ID 不再适用,响应流断了在途请求就丢,客户端要用新 ID 重发。

server/discover

新增的发现端点:客户端可提前查询服务端支持的协议版本、能力集与身份信息。服务端 MUST 实现,客户端 MAY 调用,跳过它直接发工具调用完全合法。

显式状态句柄

协议不管状态,不等于应用不能有状态。官方做法是由工具签发句柄,让模型作为普通参数在工具之间传(如 add_item 返回 basket_id,后续调用带上它)。模型能看到句柄,能自己决定哪些调用要带,官方认为比传输层会话状态更好用。

多轮请求 MRTR(SEP-2322)

旧版靠 elicitation/create、sampling/createMessage、roots/list 这类服务端反向请求,要求服务端一直保持 SSE 流不断开。无状态后没有常驻连接,替代方案是 Multi Round-Trip Requests(MRTR):

  • 服务端把要问的东西放进返回值,tools/call、prompts/get、resources/read 可返回 resultType: input_required 的结果,内含 inputRequests 和 requestState。
  • 客户端收集完回答,用同样键放进 inputResponses,连同原样 requestState 重发一次原始调用,第二次由哪台机器处理都行。

其他要点:

  • resultType 是 RC 之后补的字段,现在每个 result 都必须带;普通结果是 complete,老版本服务端不带时按 complete 处理。
  • SEP-2260 规定服务端只能在处理某个客户端请求的过程中发起请求,弹窗都能追溯到主动动作(如 Supabase 靠 MRTR 实现删数据前先确认)。

路由头 Mcp-Method 与 Mcp-Name(SEP-2243)

Streamable HTTP 的 POST 请求必须带两个标准头:Mcp-Method 标明方法,Mcp-Name 标明具体的工具/资源/prompt 名。网关拿到就能路由、限流、计量,不用解 body;头和 body 对不上直接 HTTP 400(-32020)。同一 SEP 还支持用 x-mcp-header 把工具参数映射成自定义 HTTP 头。

列表结果缓存(SEP-2549)

tools/list、prompts/list、resources/list、resources/read、resources/templates/list 的返回值多带两个字段:

  • ttlMs:新鲜度提示,单位毫秒。
  • cacheScope:public 或 private,决定共享中间层能不能缓存。

语义照 HTTP Cache-Control,与原有 listChanged 通知并存。会话没了之后列表端点不再随连接变化,客户端避免每次调用都重拉工具目录。

链路追踪(SEP-414)

把 W3C Trace Context 的 traceparent、tracestate、baggage 固定在 _meta 里。之前各 SDK 键名不统一串不起来;统一后一条 trace 能从宿主应用一路连到下游服务。

扩展框架(SEP-2133)

  • 每个扩展有反向 DNS 风格的 ID,通过 ClientCapabilities / ServerCapabilities 里新增的 extensions 映射协商。
  • 扩展代码放独立仓库,按自己的节奏发版,新能力不再需要写进核心规范、触发带破坏性改动的版本升级。
  • 两端都声明才生效,没声明就当它不存在。

Tasks 与 MCP Apps 扩展

  • Tasks(SEP-2663):从核心协议实验特性移入 io.modelcontextprotocol/tasks 扩展并重构:阻塞式 tasks/result 换成 tasks/get 轮询;新增 tasks/update(客户端可往运行中的任务送输入);删除 tasks/list;服务端可主动返回 task handle;变更通知改到统一的 subscriptions/listen 流。
  • MCP Apps(SEP-1865):第一个官方扩展(2026 年 1 月已 Final),让 Server 下发可交互 HTML 界面,宿主在沙箱 iframe 渲染,工具要提前声明 UI 模板供预取和安全审查;界面动作走与直接调用工具相同的审计与授权路径。

授权收紧

六个 SEP,方向是向生产环境 OAuth 2.0 / OIDC 部署形态对齐,值得注意的几条:

  • 授权服务器 SHOULD 带 iss,客户端换 token 前 MUST 校验(SEP-2468,对应 RFC 9207),防 authorization server mix-up 攻击。
  • 注册时 MUST 指定 application_type(SEP-837);桌面端/CLI 常报 redirect_uri 错误,就是授权服务器默认按 web 类型拒了 localhost 回调。
  • 客户端凭据绑定到签发它的 issuer(SEP-2352),持久化时按 issuer 分开存。
  • Dynamic Client Registration 正式废弃,方向是 Client ID Metadata Documents,兼容期内继续可用。

错误码变化

以前基本全是 HTTP 200 + body 内错误;现在传输层失败返回真实 HTTP 状态码,应用层结果才留在 body:

情况 2025-* 版本 2026-07-28
未知方法 HTTP 200 + body 错误 HTTP 404
协议版本不支持 不统一 HTTP 400,-32022
头绑定字段缺失/不匹配 不统一 HTTP 400,-32020
缺少必需客户端能力 无 -32021

坑:资源不存在的错误码从 MCP 自定义的 -32002 改成 JSON-RPC 标准的 -32602(SEP-2164),客户端里硬匹配过的要检查。logging/setLevel 不再可用,改用每请求的 io.modelcontextprotocol/logLevel 字段。

废弃能力与生命周期策略(SEP-2596)

MCP 第一次有了正式特性生命周期:Active / Deprecated / Removed 三种状态。最短窗口:从标记 Deprecated 的版本发布算起至少保留十二个月才可移除;安全事故可加速,但至少留九十天。

本次废弃:Roots(改用工具参数、资源 URI 或服务端配置)、Sampling(改为直接对接 LLM 提供方 API)、Logging(stdio 用 stderr,观测用 OpenTelemetry)、旧 HTTP+SSE 传输。四项至少一年内仍可用,但新实现别再依赖。

SDK 支持与升级方式

升级是 opt-in 的,版本按请求选(如 Amazon Bedrock AgentCore Gateway 可同时声明两个版本,按请求头走对应行为)。四个 Tier 1 SDK 发布当天全部支持:

  • Python:mcp v2,FastMCP 更名 MCPServer,升级后一个端点同时应答两个协议版本。
  • TypeScript:v2 拆包成 @modelcontextprotocol/server 和 /client,ESM only,要求 Node.js 20+。
  • C#:2.0.0 系列,v1.x API 继续可用。
  • Go:v1.7.0 起支持,模块路径不变;Streamable HTTP 只有在 Stateless 打开时才接受新版本请求,否则协商降级到 2025-11-25。TypeScript 也是显式选择,Python 和 C# 默认走新版本。

总结与迁移评估

会话和握手去掉后,MCP Server 就是一个普通 HTTPS 端点,可部署到 serverless 和边缘节点。评估影响优先看四件事:

  1. 有没有把应用状态放在协议会话里。
  2. 有没有依赖长连接做 elicitation 或 sampling。
  3. 有没有硬匹配 -32002。
  4. 有没有在用 logging/setLevel。

7 月 28 日只是规范文本发布日,跑在 2025-11-25 上的实现不受影响,废弃项还有至少十二个月,迁移节奏自定;新写的 Server 直接按无状态来。

原文:Claude MCP 新版本特性:无状态内核、MRTR、扩展性及授权收紧!(公众号「脑子进煎鱼了」)