无状态核心具体怎么做到的

那么，新规范是怎么把这个死结解开的？三件事。

握手没了

initialize 和 notifications/initialized 这一对开场仪式被直接删除，Mcp-Session-Id 这个 HTTP 头也删了。以前握手时交换的信息，协议版本、客户端是谁、客户端支持哪些能力，现在改成每个请求自己带，塞在 _meta 字段里。服务器那边也建议在每个返回结果的 _meta 里报一下自己的身份。

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"}}}}

想提前问清楚服务器有什么本事，有个新方法

新增了一个 server/discover，用来查服务器支持哪些协议版本、有什么能力、自己是谁。这里的分工要看清楚：服务器必须实现它，客户端可以不用它。客户端愿意的话可以在干任何事之前先查一次，不查直接发请求也完全合法。这跟老的 initialize 有本质区别，那是必经的开场仪式，这只是一次普通查询。

规范把话说死了：连接不等于会话

顺带一提，像 subscriptions/listen 这种长连接也没破坏无状态：它本身仍然是一次普通的请求/响应，只不过那个「响应」是一条开着不关的通知流。它的状态属于那次请求，不属于底下的连接。

关键一点：状态没有消失，只是从暗处搬到了明处

但这里有个最容易被误读的地方，协议层没有会话了，不代表你的应用必须无状态。

如果你的服务器确实需要跨多次调用记事，官方给的做法是：从工具里发一个明确的「号码牌」（handle）出去，让模型把它当成普通参数，在后续调用里传回来。

官方在发布博客里给的理由是这个做法比藏在传输层里的会话状态更好用，原因就是模型能看见这块状态：

我们发现这样比把会话状态藏在传输层里更好，模型能看见这个 handle，能自己在不同工具之间把它串起来。

MCP 官方发布博客，2026-07-28（译文）

这里有个权衡值得说破：状态管理这件事并没有消失，它从「传输层偷偷帮你管」变成了「你自己在业务层明着管」。好处是透明、可排查、能水平扩展；代价是它现在归你的业务层了。

MRTR：服务器想问用户一句话，现在得跑两趟

既然服务器不能再主动开口，那它中途要问用户一句话怎么办？

先说这是个什么场景。一个工具跑到一半，需要用户确认点什么：Supabase 的 MCP 服务器要建个新项目，得先问一句「这会产生费用，确认吗」；或者一条 SQL 会删数据，得先让用户点头。

以前的做法是服务器直接从那条一直开着的双向流里，反向给客户端发一个请求，问一句（elicitation/create）、借用客户端的模型算一下（sampling/createMessage）、或者问文件目录在哪（roots/list）。前提是那条流得一直开着，而这正是无状态化要拆掉的东西。

新做法叫 MRTR（Multi Round-Trip Requests，多轮往返请求）：服务器不再发请求，改成「返回一个还没完成的结果」，把想问的问题装在里面；客户端问完用户，带着答案把原请求重发一遍。点下面五步看它怎么走：

Supabase 的产品负责人说这个模式让他们做成了一件想做很久的事：

支持询问用户这件事在我们路线图上放了一阵子了，但因为 Supabase MCP 是无状态跑的，一直不好做。MRTR 改变了这一点，它让我们的工具在动手之前可以先跟用户确认，比如新建一个项目的费用，或者一条会删数据的查询。

Inian Parameshwaran，Supabase 产品负责人（译文）

代价在两处

第一，原请求要整个重发。服务器可能得把前面的工作重做一遍，除非它把中间结果也编码进 requestState 里。

第二，requestState 是一颗需要小心处理的手雷。它在客户端手上转了一圈才回来，规范对此的要求相当硬：

服务器省掉的那套共享存储，变成了要自己写对的密码学签名。

另外 MRTR 有使用范围：只能用在 prompts/get、resources/read、tools/call 这三个方法上，其他请求上服务器不得返回 input_required。

网关终于看得懂 MCP 了（附一条发布博客没提的安全机制）

状态的问题解决了，那么还剩一个老问题：中间那些网关，一直不知道你在调什么。

新规范给每个 POST 请求加了必填的 HTTP 头。Mcp-Method 每个请求都要带，说这次调的是什么方法；Mcp-Name 只在点名了具体对象时才带，也就是 tools/call、resources/read、prompts/get 这三种请求，说调的是哪个工具、资源或提示词。加上一直都要带的 MCP-Protocol-Version，网关、限流器、防火墙读这几行就够了。

听着像个纯便利功能，但它配了一条硬性校验，这条在发布博客里没提：

还有个配套的新东西叫 x-mcp-header：服务器可以在工具的参数定义里标注「这个参数要镜像进 HTTP 头」，头名叫 Mcp-Param-{名字}，方便按租户之类的维度路由。这个功能对服务器是可选的，但客户端必须支持。记住它，后面讲安全时它还要出场。

工具清单终于能缓存了（顺带保住上游的 prompt 缓存）

无状态还带来一个顺手的好处：列表结果不再随连接变化，于是能缓存了。

tools/list、prompts/list、resources/list、resources/read、resources/templates/list 这五个方法的返回结果，现在必须带两个字段：

另外还有一条要求级别稍低、但值钱得多的：服务器应该按确定的顺序返回工具列表。

这条得解释一下才看得出它值钱在哪。工具清单是要拼进模型提示词里的，而提示词的缓存是从头开始逐字匹配的，开头只要变一个字，后面整段缓存就全部失效、重新计费。工具列表如果每次返回的顺序都不一样，上游的缓存就永远打不中。

一个「排序要稳定」的小要求，省下的是真金白银。

什么被删了，什么被判了缓刑

接下来是最该对着自查的部分，你手上的东西哪些会坏。这次 changelog 一共 9 条重大改动、12 条次要改动、4 条弃用，下面两张清单是其中最该盯的。

错误码也动了

资源找不到的错误码从 -32002 改成了标准的 -32602（参数无效），跟 JSON-RPC 规范对齐。另外三个新错误码重新编了号：-32020 头与体不一致、-32021 缺必需能力、-32022 协议版本不支持。规范顺手划了地盘：-32000 到 -32019 是历史遗留区，这些号是政策出台前各家自己占的，往后不许再往里分配新号，新实现也不该再用；-32020 到 -32099 归规范专用。

如果你的客户端代码里硬编码了 -32002 这个数字，这次要改，但别改过头：规范同时要求客户端仍然接受老版本服务器发来的 -32002，只是自己这边不再发了。

弃用政策本身是这次的新东西

以前弃用全凭默契，这次成文了。规范定义了功能的三种状态和一条最短时限：

这 12 个月是从「被标记弃用的那一版规范发布」算起，不是从提案定稿算起。除此之外还有两条配套：一是有一个统一的「待删清单」页面，不用自己去翻各版 changelog 拼图；二是第一梯队 SDK 被要求必须在下一个版本里用各语言原生的方式把弃用标出来（TypeScript 的 @deprecated、C# 的 [Obsolete]、Java 的 @Deprecated、Go 的 Deprecated: 注释），做不到会走降级流程。

扩展变成了正式通道

核心删瘦了，那么新能力往哪加？

以前想给 MCP 加能力，只能往核心协议里塞，Tasks 之前就挂在核心里当「实验性功能」。这次立了正式的扩展框架：核心保持精简，新能力走扩展，客户端和服务器各自在能力里声明自己支持哪些扩展。

Tasks 由 AWS 贡献，是首批官方扩展之一；AWS 那边说新规范和它的无状态核心已经在 Amazon Bedrock AgentCore 里可用。Tasks 的机制值得多说两句：服务器决定某个请求要跑很久时，返回一个任务号而不是最终结果，这个任务号是持久的句柄，客户端断线了、重启了，拿同一个号接着轮询就行。任务有五个状态：

深色的三个是终态，到了就不再变。中途要问用户，任务转到 input_required，客户端用新的 tasks/update 回答，不需要第二条连接，也不需要服务器主动发消息。

授权这块收紧了四处

删的加的都讲完了，但还有一块官方单独拎出来说：过去一年里，实现方花时间最多的地方就是授权。这次改了四处。

你要是纳闷过为什么你的命令行客户端 OAuth 流程报 redirect_uri 错，多半就是这个原因。

MCP 官方发布博客，谈 application_type 那条改动（译文）

第三方安全分析：责任从协议搬到了开发者身上

但以上都是官方口径。规范正式发布前，有第三方把这套新规范当攻击面研究了一遍，Akamai 在 6 月发布了一份分析，结论被 SecurityWeek 报道。

他们的判断是：新规范确实去掉了几类漏洞，但同时开出了几片新的攻击面，而且这些新风险高度依赖开发者怎么实现。

既然协议转向了无状态模型，还引入了富 UI 应用和异步任务，那么关键的安全边界现在完全取决于开发者怎么实现。

Maxim Zavodchik，Akamai 威胁研究高级总监，据 SecurityWeek 报道（译文）

他们的总结是，这些改动的分量超过了增量改进。它从根本上重塑了安全责任落在谁身上：以前由协议强制保障的安全决策，现在越来越多地交给了 MCP 服务器的开发者和平台运营方。

报道在这里补了一句同样重要的话：MCP 协议本身并没有变得更脆弱，变大的是基于新规范搭起来的那些 MCP 服务器的攻击面。

那我现在要不要动手

那么说了这么多破坏性改动，最后回答那个最实际的问题。答案跟「最大规模破坏性更新」这个印象是相反的。

具体的兼容路径有三条：

一，新客户端遇到老服务器会自动退让。说 2026-07-28 的客户端碰上只会 2025-11-25 或更老版本的服务器时，会回落到原来的 initialize 握手，新旧照常互通。反过来，老服务器收到不带协议版本头的请求，可以当成 2025-03-26 处理。

二，SDK 的大版本升级是另一码事。Python 和 TypeScript 都出了 v2，这是各自的破坏性大版本，什么时候升由你自己定，跟 7 月 28 日没关系。TypeScript SDK 的 v1.x 在 v2 正式发布后还会继续修 bug 和安全问题至少 6 个月，Python 的 v1.x 分支继续收关键 bug 修复和安全补丁。

三，升级 SDK 本身不一定改变你在网线上说什么，而且四个 SDK 的行为不一样，这点容易踩：

四个第一梯队 SDK（TypeScript、Python、Go、C#）当天就支持新规范，Rust SDK 是 beta 支持。真正要动手改的是下面这几类，对着过一遍：

新规范把开场握手和会话号一起删了。每个请求自己带上协议版本、客户端是谁、支持哪些能力，服务器处理完就忘。负载均衡器（把请求分给多台机器的调度员）不用再记谁属于哪台，轮着发就行。

协议层没了会话，应用照样可以记事，做法换了个地方：服务器从工具里发一张明面上的号码牌出去，让模型当成普通参数，在下次调用时传回来。

状态管理这件事并没有消失，它从「传输层偷偷帮你管」挪到了「你自己在业务层明着管」。

服务器不能再主动开口，那它中途要问用户一句话怎么办。新规范给的办法叫 MRTR（多轮往返请求）：服务器先返回一个「我还差信息」的半成品结果，客户端问完用户，把原请求带着答案整个重发一遍。

代价在两处：原请求要整个重发，服务器可能得把前面的活重做一遍；那张号码牌在客户端手上转了一圈才回来，规范因此把它定成「攻击者可以随便改的输入」，凡是牵涉授权和权限的，服务器必须给它打上一个仿不出来的签名，验不过直接拒。省掉的共享存储，换成了要自己写对的密码学签名。

这次改动清单一共 9 条重大、12 条次要、4 条弃用。最该对着自查的是这两张单子。