MCP 7月大版本来了：无状态化、Breaking Changes、MCP Apps——你的Server要改吗？

MCP · 协议 · 工程实践

MCP 7月大版本来了：无状态化、Breaking Changes、MCP Apps——你的Server要改吗？

2026-06-30 · RC已发布 · 正式版2026-07-28生效

⚠️如果你在生产环境跑MCP Server，这篇文章你必须看完。2026年7月28日，Model Context Protocol将发布自诞生以来最大规模的版本更新。breaking changes级别。

先说结论

MCP 2026-07-28 版本不是一次普通的版本升级。它动到了协议核心：无状态化。

这意味着：

• 如果你自建了MCP Server——session ID将从协议层面移除，你的server必须改。
• 如果你是重度MCP用户——你依赖的server会不会断，取决于它什么时候迁移。
• 如果你在做Agent基础设施选型——"是否支持无状态MCP"应该成为评估项。

RC已经于2026年5月21日发布，现在正处于10周验证窗口期。7月28日正式版发布后，主流客户端会逐步切换。拖到那时候再动就是被动迁移。

MCP现在是什么体量？

MCP已经从Anthropic的一纸规范，成长为Linux Foundation治理下的行业基础设施。这么大的生态，每一次breaking change都要付出巨大迁移成本。但这次不得不改——因为现协议的基础设施局限性已经到了天花板。

旧协议有什么问题？

当前的MCP协议（2024-11-25规范）基于session模型：

• 客户端和server建立session，后续请求依赖session内的状态
• 部署远程server时，必须配sticky session（粘性会话）
• 负载均衡器开session亲和性，扩容缩容都得小心翼翼
• 挂一个实例，在途session全断

这对本地开发没问题。但一旦上生产、做远程server——这些基础设施层面的限制就成了真痛点。

同时还有几个次生问题：

tools/list无法缓存：每个客户端连上来就全量拉一次工具列表，Server多的时候延迟和流量都很可观。
无法水平扩展：session状态粘在实例上，云原生的弹性伸缩几乎不可能。
运维复杂度高：需要共享session store、deep packet inspection网关——这些运维负担劝退了很多潜在的server开发者。

2026-07-28版本的核心变化

变化一：协议无状态化

旧版部署：

upstream mcp_servers { ip_hash; # session亲和，否则请求落错实例就断 server mcp1:8080; server mcp2:8080; }

新版部署：

upstream mcp_servers { round-robin; # 任意实例处理任意请求 server mcp1:8080; server mcp2:8080; server mcp3:8080; # 随时加，不中断 }

变化二：Mcp-Method/Mcp-Name HTTP头

每个请求必须携带这两个头，负载均衡器可以直接按方法名做路由，不用解包JSON body。

# Streamable HTTP Transport 新增必需头 Mcp-Method: tools/call Mcp-Name: my-search-server # 网关可以直接路由，无需解包 if ($http_mcp_method = "tools/call") { proxy_pass http://mcp_executor; }

Server端会校验头和body的一致性，不一致直接拒绝。

变化三：tools/list可缓存

server声明ttlMs+cacheScope，客户端按策略缓存工具列表。

{"result":{"_meta":{"ttlMs":300000,"cacheScope":"global"},"tools":[...]}}

新能力：MCP Apps

这是本次版本最引人注意的新特性——SEP-1865：MCP Apps。

以前tools只能返回文本或结构化数据。现在tools可以返回交互式HTML界面，客户端在沙箱iframe中渲染。

工作流程：

1. Server声明工具可用的UI模板（host可预取、缓存、安全审查）
2. Host在沙箱iframe中渲染UI
3. UI通过postMessage与Host通过JSON-RPC双向通信
4. 每次UI触发的动作走与直接tool call相同的审计和同意路径

Claude、ChatGPT、VS Code + GitHub Copilot、Goose已经采用MCP Apps。

MCP Apps ≠ Web应用。MCP Apps是在AI对话流中嵌入的交互式UI组件——比如一个数据查询工具返回一个可排序的表格界面，而不是markdown表格文本。

新能力：Tasks扩展

Tasks从实验性功能正式升级为一级扩展。

以前处理耗时任务（几秒到几分钟）只能靠持有SSE流。Tasks解决了这个问题：

• server调用tools/call返回task handle
• 客户端通过tasks/get、tasks/update、tasks/cancel驱动生命周期
• tasks/list被移除（无session下无法安全做scope限定）

Breaking Changes清单

必须改的

已弃用（12个月后移除）

迁移路线图

给你的行动建议

• 自建MCP Server的团队：现在就去读RC公告，对照breaking changes清单评估迁移量。
• 重度MCP用户：关注你依赖的Server是否跟进。正式弃用政策意味着旧版本的兼容窗口有了明确期限。
• Agent基础设施选型：把"是否支持无状态MCP"加进评估项。能水平扩展的MCP网关和不能的，半年后运维成本不是一个量级。

迁移示例：Node.js Server改动前后

旧版 - 依赖session：

import{Server}from"@modelcontextprotocol/sdk/server";constsessionState=newMap();// session粘性状态constserver=newServer({name:"my-server",version:"1.0.0"},{capabilities:{tools:{}}});// 需要sticky session才能保证状态一致性

新版 - 无状态：

import{Server}from"@modelcontextprotocol/sdk/server";constserver=newServer({name:"my-server",version:"2.0.0"},{capabilities:{tools:{}},cacheTtlMs:300000,cacheScope:"global"});// 状态从session移到了工具参数里server.setToolHandler("query",async(args)=>{// args.sessionToken - 显式传入，不依赖会话状态});

这次升级意味着什么？

1. 从"Anthropic的协议"变成"行业基础设施"。无状态化、标准追踪、缓存策略——这些都不性感，但LSP当年也是靠这种不性感的工程细节赢的。一个协议真正成为基础设施的标志，就是基础设施层面的特殊性越少越好。

2. Server开发门槛降低。无状态意味着你可以用普通HTTP服务的方式开发MCP Server，不需要理解session管理、状态同步这些复杂概念。这会进一步加速Server生态的爆发。

3. 企业级部署成为可能。无状态+水平扩展+标准化认证+W3C追踪——这些是企业IT采购MCP的必备条件。7月版本第一次让MCP具备了真正的"企业就绪"属性。

4. MCP Apps改变交互范式。从一个纯文本/数据交换协议，进化为可以承载交互式UI的协议。这对Agent应用的体验设计有深远影响。

最后一句：10周验证窗口不是留给观望的。如果你的Server在生产线上，现在就应该拉一份RC Spec，跑一遍兼容性测试。7月28日不是deadline——是旧版本倒计时的开始。

参考来源：MCP官方博客《The 2026-07-28 MCP Specification Release Candidate》(2026-05-21) · Gravitee《What Every MCP Builder Needs to Know Before July》(2026-06-19) · MCP Migration Studio《Every breaking change in the 2026-07-28 MCP spec》(2026-06-09) · AIEII《MCP要无状态化了》(2026-06-13) · 志趣《MCP协议与生态指南》(2026-06-22) · 36氪《从25000个星标看MCP协议的真机遇与伪泡沫》(2026-06-21)

版权声明：本文技术细节基于MCP官方RC公告及社区分析综合整理。如有更新请以官方2026-07-28正式版Spec为准。