一句话看懂：开发者 Roee-Tsur 发布了一款名为 mcp-spec-check 的合规检测工具，对官方注册的 7,850 台 MCP 远程服务器进行扫描后，发现只有 1 台完全符合即将于 2026-07-28 生效的新版 MCP 协议。这意味着 MCP 生态正在经历一次从有状态到无状态核心的重大架构升级，且绝大多数服务器尚未完成迁移。
事件核心：发生了什么
MCP 协议即将发布自推出以来最大的一次修订（2026-07-28 版本）。本次修订的核心变化是移除 initialize 握手协议和 Mcp-Session-Id，转向无状态核心；同时将 Mcp-Method/Mcp-Name 路由头变为必需，并用多轮请求替代 SSE 交互。为了衡量实际生态的迁移进度，Roee-Tsur 开发了 mcp-spec-check 工具，对官方 MCP 注册表中所有 7,850 台服务器进行探测。在可正常联系到的 4,356 台服务器中，只有一台通过了“发现服务（discover）”、“路由头（routing-headers）”和“会话无关（session-independence）”三项必备检查，90.8% 的服务器尚未就绪。需要注意的是，7 月 28 日只是规范文本发布日，而非服务切换日——兼容版本协商依然有效，过期功能至少还有 12 个月支持期。但 SDK 和客户端已经在向无状态核心迁移，未迁移的服务器将随着支持窗口到期而被逐步抛弃。
为什么重要
MCP 是连接 AI 应用与大模型、外部数据源及工具的一个开放协议。此次从有状态到无状态的核心改造，本质上是为了解决大规模部署下的负载均衡和网关路由问题。只有实现无状态化，MCP 服务器才能在云原生环境中灵活扩展，对 Gateway、LLM 路由器的支持也会更强。当前生态迁移率极低（仅 0.02%），说明大多数服务器仍停留在旧协议上，这既反映了协议升级的惯性挑战，也暗示 AI 应用基础设施正处在从“能用”向“好部署”过渡的关键节点。如果 MCP 生态不能完成这次迁移，开发者的多模型调用、数据互通等高级功能将难以在“无状态”的架构上有效落地。
对用户/开发者/创作者的影响
对于使用 MCP 构建 AI 工具的开发者来说，这次升级意味着必须在其服务端实现三个新接口：server/discover（替代原来的初始化握手）、在所有请求中添加 Mcp-Method/Mcp-Name 头、并移除协议级别的会话 ID 以支持无状态路由。工具本身提供了快速诊断方式——运行 npx mcp-spec-check https://your-server.com/mcp 即可 30 秒内得出合规报告。对于普通用户和创作者，如果使用的 AI 应用（如基于 MCP 的智能助手、代码生成工具）后端服务器没有完成迁移，可能在负载增高时出现连接不稳定或功能降级，但短期内无直接中断风险。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
目前公开信息显示，MCP SDK 官方团队已在发布 2026-07-28 的 RC Beta 版本，而 mcp-spec-check 项目同时维护了一套包含已知真值服务器的自动化测试面板。接下来值得观察的是：1）主要 MCP 服务器（如 GitHub 的 MCP server、各 AI 公司的官方插件）的迁移时间表；2）MCP 工作组是否会针对 12 个月支持窗口期满后的强制迁移给出明确日期；3）mcp-spec-check 的扫描结果是否会被集成到官方注册表中，成为服务器上架的合规前置条件。另外，对于 OAuth 保护下的服务器，工具还提供了 auth-metadata 检查（RFC 9728），这也是企业级部署 MCP 时的一个隐性合规要求。
来源：github.com
