MCP 2026-07-28 规范，说点人话

7 月 28 号 MCP 出了新版规范。官方把它吹成"自发布以来最大的一次修订"，这话不算夸张，因为它把协议底层的玩法整个换了一套。下面用大白话讲三件事：到底改了什么、以后会往哪走、你现在手上的 MCP 该怎么升。

这次主要改了什么

老版本的 MCP 是"有状态"的。意思是客户端要先跟服务器握手，拿到一个 session id，之后每次请求都得带着这个 id，服务器也默认你接下来的请求都打到同一台机器上。这套东西在本地跑没问题，一旦你想把 MCP 服务器挂到云端、用负载均衡横向扩展，就开始拧巴了。session id 把请求钉死在某台机器上，普通轮询负载均衡用不了，得搞会话粘滞，运维成本高。

新版直接把 session 这层砍了。每个请求自带协议版本和客户端身份，发到哪台机器都能处理，机器之间不用共享状态。说白了，MCP 现在就是个普通的 HTTP 请求响应，跟访问一个 REST API 没本质区别。这一改，MCP 服务器可以像普通 web 服务那样随便扩。

顺带还改了几样：

• 路由靠 HTTP 头。方法名和工具名放进 Mcp-Method、Mcp-Name 两个头里，网关、WAF、限流器不用再扒 JSON 报文体就能决定这个请求往哪转、要不要拦。
• 工具列表能缓存了。tools/list 的响应带了 ttlMs，客户端可以在有效期内缓存，不用每次重连都重新拉一遍，上游的 prompt 缓存也不至于老被打断。
• 授权更严了。强制 RFC 9207 的 issuer 校验，堵上授权服务器混淆漏洞；客户端注册时能声明 application_type，CLI 和桌面端的 localhost 回调不再被莫名拒绝。如果你以前写过 CLI 客户端被 redirect_uri 报错坑过，多半就是这个原因。
• 有了正式的扩展框架。Tasks 从实验内核挪进了 io.modelcontextprotocol/tasks 扩展，改成轮询式（tasks/get、tasks/update），通知走一条 subscriptions/listen 流。长时间运行的任务不用再占着一条打开的流干等。
• 工具调用中途能问用户要输入了。MRTR（多轮往返请求）让服务器可以返回 input_required，客户端拿到用户答复后再重试。以前要实现"执行前确认一下"这种交互挺费劲，现在协议层就支持了。

MCP 以后会怎么演变

从这次修订能看出三个方向。

第一，彻底 web 化。官方原话是"让 agent 基础设施像 web 的其余部分那样工作：无状态、可缓存、可路由、全球可伸缩"。翻译过来就是，MCP 不想当个特殊协议，它想变成 HTTP 之上一个平平无奇的约定，享受 web 那套成熟基建（CDN、网关、负载均衡、可观测性）。

第二，靠扩展而不是塞核心。把 Tasks、MCP Apps、企业托管授权（EMA）都放进正式扩展框架，核心协议尽量瘦身。这意味着以后新功能大概率走扩展，核心不会再频繁动。

第三，奔着企业级去。授权对齐 OAuth 2.0 / OpenID Connect，引入客户端元数据文档（CIMD）替代动态客户端注册（DCR），分布式追踪键也标准化了。这些改动单独看都不大，但合起来明显是冲着"让大公司敢在内部生产环境用"去的。

需要注意几个东西进了弃用倒计时：Roots、Sampling、Logging 这三个老功能被标为 deprecated，但官方给了至少 12 个月的过渡期，期间照常工作。传统的 HTTP+SSE 传输也一并弃用，同样一年退出期。新项目别再用它们，老项目尽快规划替代路径。

现有的 MCP 怎么升级

Server 作者要做的

最核心一条：别再要求握手了。把每个请求当独立请求处理，不要假设它来自某个会话。

如果你的服务器内存里有会话状态（比如登录态、上下文），赶紧挪到外部存储（Redis、数据库之类），让任意一台实例都能接任意一个请求。这一步是迁移里最容易踩坑的地方，因为你得把隐式的"服务器记着你"改成显式的"客户端把句柄传回来"。官方的建议是让工具签发一个显式 handle，让模型自己当参数传回来，这样模型看得见这个 handle，能在不同工具之间串起来，比藏传输层里的会话状态好维护。

路由改成认 Mcp-Method 头。工具列表加上 ttlMs 声明缓存窗口。工具的输入 schema 升级到完整的 JSON Schema 2020-12，以前用松散子集或者靠验证器怪癖混过去的，新版会严格校验，直接拒掉。顺手翻一遍代码里有没有用 Roots、Sampling、Logging，提前想好替代方案。

长任务搬到 Tasks 扩展上。认证对齐 RC 的 OAuth/OIDC 要求，老规则写的授权服务器风险最高。

Client / Host 集成者要做的

别再发 initialize 了，直接发自包含的 2026-07-28 请求。

别假设请求会固定打到同一台服务器，要适配"任何实例处理任何请求"的设计。老老实实按 tools/list 返回的 ttlMs 缓存工具列表，不要每次重连都重新拉。

认证流程对齐新的 OAuth/OIDC 要求。如果依赖 Roots、Sampling、Logging，现在就动手搭替代路径，别等 12 个月倒计时见底。

有个坑要注意：旧版服务器和新版服务器没法平滑互操作，协议线上不兼容。如果你维护一个有存量用户的产品，别指望一夜切换，得在客户端做个过渡期，让新老板本能协商着用一段时间。

现在哪些软件适配了

四个 Tier 1 SDK 在 7 月 28 号当天就支持了新规范：TypeScript、Python、Go、C#。Rust SDK 是 beta 支持。这些 SDK 同时能写客户端和服务器，升级直接拉新版就行。

TypeScript SDK 的主线已经升到 v2（@modelcontextprotocol/server、@modelcontextprotocol/client 两个包）。微软发了 C# SDK v2.0 的公告，明确说"2026-07-28 修订重新设计了 HTTP 上的工作方式，默认无状态"。

除了官方 SDK，这些产品在官方博客里明确表态已经适配或正在适配：

• Amazon Bedrock AgentCore。无状态内核已经用上，AWS 贡献的 Tasks 扩展进了官方。
• Cloudflare Agents SDK。首日支持，能在 Workers 里直接跑 MCP 服务器，不用承担传输会话开销。Sentry、Linear 这些 Cloudflare 客户能首日用上。
• Figma 的 MCP 服务器。已经切到无状态架构。
• Google Cloud、Microsoft Foundry、Netlify、Supabase、FastMCP、Manufact、Runlayer 这些也都在公告里说了适配情况。Manufact 还提到新 SDK 让他们的包体积缩了约 83%，还快了 25%。

还在推进中的：IBM 的 ContextForge 开了 GitHub issue（#5166）专门跟踪 RC 适配，包含 Tasks 扩展的采用指标。这类第三方工具要等它们各自发版，别假设你装的版本已经支持，动手前先查 release notes。

📌 给个实在建议：如果你的 MCP 服务器现在是线上在跑的，先别急着全量切。挑一个非核心服务跑通新规范，把会话状态外移这套流程走顺，再铺开。12 个月的窗口够用，没必要抢第一周。