Model Context Protocol(MCP)将推出自诞生以来最激进的一次更新。RC 从 5 月 21 日锁定,经历 10 周的 SDK 验证和社区反馈,最终版规范在 7 月 28 日正式定稿。

一句话总结变化:MCP 变无状态了。
这次更新由六个 SEP(规范增强提案)协同完成,目标一致——干掉协议层的状态。

Mcp-Session-Id 头被彻底移除。请求不再需要路由到同一台服务器实例,负载均衡器不再需要 sticky session,也不再有共享 session store。任何请求可以落到任何实例上,和 HTTP 的设计哲学终于对齐了。
initialize / initialized 握手流程也被删掉了。协议版本、客户端信息、能力声明不再在"连接时"一次性协商,而是通过每个请求的 _meta 字段传递。这也意味着你的服务器再也不能在连接时做一次权限校验就了事——每次请求都得自己能站住。
跨调用的状态怎么办?MCP 维护者的回答是:显式化。服务器返回一个不透明的 handle(比如 basket_id),模型在后续调用中主动传回来。团队的说法很直接——"显式 handle 模式只是把状态从协议层藏起来变成了模型可见。"换句话说:别偷偷摸摸记状态,让模型自己管。

服务器到客户端的请求也被约束了。以前服务器可以随时推送(比如请求用户输入),持续维持 SSE 连接。现在服务器只能在处理客户端请求期间发起反向请求,结果通过 InputRequiredResult 带一个 requestState token 返回。客户端重新发起原调用时带上 inputResponses。任何实例都能接住这个重试,不需要去找原来的服务器。
还有两个新增的强制请求头:Mcp-Method 和 Mcp-Name。有了它们,网关和负载均衡器不需要解析请求 body 就能做路由决策——这对企业部署是实打实的利好。
扩展在这次更新中变成了一等公民。用反向 DNS 标识(如 ext-*.mcp.io),通过 extensions 能力映射协商,独立的 Extensions Track 管理生命周期。社区的创新可以独立于核心规范演进和版本化。
两个具体的扩展值得关注。一个是 MCP Apps(SEP-1865):服务器可以在沙箱化 iframe 中提供 HTML UI,工具预先声明 UI 模板以支持预加载和缓存。UI 与宿主之间的通信走的是同一套 JSON-RPC 协议,审计和授权路径与直接工具调用一致。
另一个是 Tasks 从实验性核心功能毕业到扩展(SEP-2663)。改为轮询模式——tasks/get、tasks/update、tasks/cancel。任务创建变为服务端决策(客户端声明支持,服务端决定是否走异步),tasks/list 被直接移除,因为缺乏 session 后无法安全限定范围。
认证方面,六个 SEP 把 OAuth 2.1 安全实践写进了规范正文:客户端必须验证 iss 参数防止 mix-up 攻击、支持 Dynamic Client Registration、凭证绑定到颁发服务器、刷新 token 流程文档化、scope 累积规则明确。旧式的密码授权和隐式授权被彻底剔除。
inputSchema 和 outputSchema 现在完整支持 JSON Schema 2020-12——oneOf、anyOf、allOf、条件、$ref、$defs 全部可用。输入 schema 的根节点仍约束为 type: "object",输出 schema 不受限制。规范明确要求:不要自动解引用外部 $ref URI(防 SSRF),应该限制 schema 深度和校验时间。
Roots、Sampling、Logging 三个原语进入 12 个月倒计时。Roots 改用工具参数或资源 URI 替代,Sampling 直接调 LLM API,Logging 用 stderr 或 OpenTelemetry。协议还引入了一个全生命周期的特性淘汰策略:Active → Deprecated → Removed,每个阶段至少 12 个月,一个 SEP 要上到 Final 级别必须有对应的合规测试用例落地。
对于今天就必须动手改的东西,三个硬断裂今天生效。
第一,Mcp-Session-Id 头没了。传输层里如果有 sessionIdGenerator 配置,删掉。协议版本和客户端信息改从 _meta 读取。第二,initialize / initialized 握手没了。能力校验逻辑从握手阶段移到每个工具调用的入口。第三,错误码变了。资源未找到的错误码从 MCP 自定义的 -32002 改为 JSON-RPC 标准的 -32602(Invalid Params)。所有硬编码该值的地方都要换。
Akamai 的安全研究团队在这个 RC 上做了一轮审计,结论很诚实:无状态化确实消灭了协议层的 session 劫持、未经请求的服务端推送、弱认证方式。但同时也把五个新的攻击面摆到了台面上。
跨 agent 工作流劫持——如果 tracking ID 是可预测的,或者 state 对象未经校验,攻击者可以劫持其他用户的工作流。_meta 对象注入——如果服务器盲目信任元数据做路由或授权决策,无签名的自定义字段就是提权通道。头部与 body 反序列化冲突——Mcp-Method 头和 JSON-RPC body 不一致时可能绕过安全控制。MCP Apps 中的存储型 XSS——沙箱 iframe 的 UI 仍然面临钓鱼和数据窃取风险。一击脱离 DoS——攻击者发一个昂贵的长时间任务然后立即断开,服务器自己扛所有计算成本。
以前协议层帮你挡掉的脏活,现在搬到应用层了。
MCP 这次更新的方向是对的。session 的引入原本就是工程上的捷径——让一个天生无状态的 JSON-RPC 协议背上有状态包袱,部署复杂度直接翻倍。切掉之后,水平扩展回到纯 HTTP 的玩法,这对企业级部署是及格线而不是加分项。
显式 handle 模式也是个聪明的选择。让模型自己管理状态,不是增加了复杂度,而是让复杂度发生在它本来就该发生的地方——推理层。对调试和审计也更友好:所有的状态传递都在参数里可见。
短期阵痛主要在迁移——任何深度依赖 MCP session 机制的服务需要重写状态管理逻辑。但那些本来就不依赖 session 的简单工具服务,基本不受影响。
12 个月的弃用窗口给足了时间。问题是,有多少人会等到第 11 个月才开始动手。
参考来源: