MCP协议第五版重磅升级：无状态请求响应正式落地

MCP协议第五版到底改了什么？

MCP协议发布第五个大版本后，最核心的变化只有一句话：从有状态双向协议，转向无状态的请求/响应协议。

这次升级不是小修小补，而是影响部署方式、网关路由、鉴权流程和服务扩展性的结构性变化。对很多团队来说，它意味着MCP服务器终于能更自然地融入现代云原生架构。

1. 会话ID退出，服务部署更自由

旧版MCP需要先握手，再分配 session ID。后续请求都要带着这个ID，服务端必须记住会话状态。

问题很明显：

• 请求会被绑定到某一台实例上
• 负载均衡不够灵活
• serverless、边缘计算、CDN后多实例部署都不够顺

新版协议把每个请求都设计成独立请求，自动携带协议版本和客户端信息。这样一来，MCP服务器更像普通HTTP服务，可以直接被分发到任意实例。

这对想做 无状态协议 部署的团队尤其友好。

2. 状态下沉到工具层，句柄机制更实用

如果业务确实需要跨请求状态，新规范建议把状态交给工具自己管理，而不是放在协议层。

常见做法是：

• 工具先生成一个 handle
• 模型在后续调用中继续传递这个 handle
• 真正的业务状态保存在服务端或业务系统里

这种方式的好处是更清晰，也更适合工程化落地。协议保持轻量，复杂状态交给业务处理，减少了长连接和会话粘连带来的维护成本。

3. MRTR让“中途确认”不再依赖双向流

新版本还引入了 MRTR，用来解决多轮往返中需要用户确认的问题。

比如：

• 创建项目之前先提示费用
• 删除数据前要求二次确认
• 执行敏感操作时先让用户补充信息

以前这类场景往往需要维持一个不断开的双向流。现在服务端可以先返回“需要输入”状态，客户端收到后带着用户回答重新发起请求即可。

这对工具调用链路更友好，也更适合标准 HTTP 风格的接口设计。

4. 请求头直接路由，网关和防火墙更省事

新版请求头新增了 Mcp-Method 和 Mcp-Name 字段。

这意味着：

• 网关可以直接按请求头做路由
• 防火墙可以直接做鉴权判断
• 不必先解析 JSON 请求体

对高并发场景来说，这类改动很实际。协议层把关键元信息前置，基础设施层就能更快做决策。

5. 授权与注册机制也更严格了

这次更新还强化了授权安全性，重点包括：

• 校验授权服务器的 issuer 参数
• 修复潜在的授权服务器混淆问题
• 动态客户端注册（DCR）正式废弃
• 改用客户端元数据文档（CIMD）

这些变化看上去偏底层，但对生产环境非常关键。尤其是涉及第三方授权、企业内网接入和多租户平台时，安全边界会更清晰。

6. 废弃策略终于明确了，迁移窗口更友好

新版协议还首次引入正式废弃策略：

• Roots、Sampling、Logging 标记为废弃
• 旧版 HTTP+SSE 传输进入废弃轨道
• 至少保留 12 个月过渡窗口

这点很适合生产团队。不是立刻强制切断，而是给出明确的迁移周期，方便排期改造、回归测试和灰度上线。

生态层面：SDK 和云厂商都在跟进

MCP这次升级之所以引发关注，还因为生态已经跟上了。

1. 主流SDK同步更新

四个一级SDK都已更新：

• TypeScript
• Python
• Go
• C#

Rust SDK 也以 beta 形式跟进。对于开发者来说，这意味着新规范不会停留在纸面，工具链已经开始适配。

2. 云平台和工具厂商开始支持

已经宣布支持新规范的厂商和平台包括：

• AWS Amazon Bedrock AgentCore
• Microsoft Foundry
• Cloudflare Workers
• Google Cloud
• Figma
• Supabase
• Honeycomb

这说明MCP的使用场景正在从“实验性集成”走向“正式基础设施”。

3. 迁移前最该注意什么

这次是破坏性变更，尤其是依赖会话标识符的实现，需要重新设计。

建议迁移前先做三件事：

1. 先阅读完整 changelog 和迁移指南
2. 梳理当前是否依赖 session ID、长连接或旧版 SSE
3. 评估网关、鉴权、SDK 和业务状态保存方式的影响面

如果当前生产环境已经跑着 MCP 服务器，不建议直接跳版本硬切，最好先灰度验证。

适合谁尽快升级？

如果你的项目符合下面几类，升级价值会更高：

• 需要多实例部署的 MCP 服务
• 想接入 serverless 或边缘计算
• 需要更清晰的请求路由与鉴权
• 业务里有频繁的确认、补充输入场景
• 正在规划 SDK 升级或平台迁移

反过来，如果系统仍然深度依赖旧会话模型，就要先处理状态管理逻辑，再推进协议升级。

总结：MCP正在从“会话协议”走向“现代HTTP式协议”

这次第五版升级，最重要的不是某一个字段变化，而是整个协议理念的转向。

它把状态从协议层移到业务层，把路由和鉴权变得更标准，把部署方式变得更灵活。对于希望长期生产化落地的团队来说，这一步很关键。

如果你正在使用 MCP，建议尽快关注新规范、SDK 更新和迁移指南，提前规划升级路径，避免后续被动调整。