4356个MCP服务器仅1个适配2026规范

背景

MCP（Model Context Protocol）是一个用于 AI 模型与外部工具/数据源交互的开放协议。自推出以来，MCP 经历了多次迭代。2026-07-28 版本是该协议发布以来最大的一次修订，核心变化是引入无状态（stateless）架构，移除初始化握手（initialize handshake）和会话 ID（Mcp-Session-Id），新增路由头部（Mcp-Method / Mcp-Name），用多轮请求（Multi Round-Trip Requests）替代 SSE 触发（SSE elicitation），并调整了多个错误码。尽管版本协商机制会保证向后兼容，废弃特性至少保留 12 个月，但 SDK 和客户端已经开始迁移至无状态核心，因此服务器如果迟迟不跟进，将在支持窗口过期后被落下。

作者构建了一个名为 mcp-spec-check 的黑盒探测工具，用于快速检测远程 MCP 服务器对 2026-07-28 规范的准备程度。该工具无需访问服务器代码，仅通过 HTTP 探测实时端点，即可给出「准备好了」「未准备好」「无法判断」的结论。

核心内容

作者在 2026 年 7 月 12 日扫描了官方 MCP 注册表中的所有远程服务器（共 7,850 个）。其中，作者能够公开访问的服务器有 4,356 个。在这 4,356 个可达服务器中，恰好只有 1 个通过了全部三项必要检查，而 90.8% 的服务器尚未准备就绪。这表明向无状态核心的迁移几乎还未开始，而这在规范尚未正式 GA 之前是符合预期的。

mcp-spec-check 的工作方式如下：

• 针对给定的服务器 URL，运行三项必要检查（必过项）：
  • discover：服务器能否正确响应 discover 请求？
  • routing-headers：服务器是否支持 Mcp-Method / Mcp-Name 路由头部？
  • session-independence：服务器是否以无状态方式工作（不依赖会话 ID）？
• 三项全过 → 结论为 YES（已就绪）；任何一项失败 → NO（未就绪）；否则为 UNKNOWN。
• 其余检查（如 auth-metadata 等）为 warn 级别（可选或前瞻性），单独不会导致「未就绪」结论。
• 如果服务器回答过于模糊导致无法判断，该检查标记为 inconclusive，不参与计分；若过多 inconclusive，则工具报告 ?（无法评估）并返回 exit code 2。

工具的正确性通过以下方式保证：

1. 两个参考服务器（旧版 spec 的官方 SDK v1 和 RC beta 版）在 CI 中运行，mcp-spec-check 必须对这 8 项检查产生预期的确切结论。
2. 已知真实世界的服务器（如 GitHub 的 MCP 服务器、官方 MCP 服务器等）作为交叉验证。
3. 官方一致性测试套件（conformance suite）作为独立验证器。

工具的使用方法：

• npx mcp-spec-check <url> 输出人类可读报告和字母等级。
• npx mcp-spec-check <url> --json 输出机器可读 JSON。
• 支持 --verbose、--timeout、--bearer、--header 等参数。
• 即使服务器需要认证（auth-walled），auth-metadata 检查仍能通过 .well-known/oauth-protected-resource 探测获取就绪信号。

退出码：0 表示就绪，1 表示至少一项检查失败，2 表示无法测试（探测错误、端点需要认证、不可达、不是 MCP、或回答过于模糊）。

探测伦理：注册表扫描仅对官方公开注册表中自愿发布的 connect URL 进行；每个主机串行发送请求（一次一个），只读协议调用，无副作用，User-Agent 为 mcp-spec-check-scan 并指向仓库。每台服务器的结果仅保留在运行扫描的机器上，仅发布汇总计数和百分比。

关键要点

• 在 4,356 个可达的官方注册表远程 MCP 服务器中，仅有 1 个完全符合 2026-07-28 规范的三项必要检查。
• 90.8% 的服务器未准备好，迁移至无状态核心的工作几乎尚未启动。
• 2026-07-28 是规范文本发布的日期，并非强制切换日期；版本协商和废弃特性保留至少 12 个月保证过渡期。
• 工具 mcp-spec-check 是完全黑盒的 HTTP 探测，无需安装、无需访问代码、零运行时依赖。
• 只有三项检查会直接判定「未就绪」：discover、routing-headers、session-independence。其他检查（如 auth-metadata）仅为警告级别，不单独导致失败。
• 工具通过 CI 中的参考服务器和已知真实服务器确保探针正确性，任何误判被视为最高优先级 bug。
• 对于需要认证的服务器，工具仍能通过 auth-metadata 检查给出部分就绪信号（RFC 9728 探测）。
• 退出码设计用于 CI 流程：0 就绪，1 至少一项失败，2 无法测试。

意义与影响

1. 倒逼服务器开发者关注升级：尽管规范发布日不会强制中断服务，但 SDK 和客户端已经转向无状态核心，因此服务器如果不及时迁移，可能会在客户端更新后失去兼容性。该工具提供了一个清晰的「就绪」指标，帮助开发者快速定位差距。

2. MCP 生态成熟度的晴雨表：扫描结果（仅 1/4356 达标）揭示了协议迁移的早期阶段。这表明大多数服务器仍处于旧版本，未来半年到一年将是迁移关键期。注册表管理员可参考此数据推动更新。

3. 简化兼容性验证流程：传统的兼容性测试需要部署、配置 SDK 或接入一致性测试框架。mcp-spec-check 提供了一条 30 秒的快速验证路径，使得运维人员、CI 流水线、甚至最终用户都能轻松检查服务器是否就绪。

4. 向后兼容与弃用策略的示范：MCP 团队通过明确的版本协商和 12 个月废弃保留期，确保了过渡的平滑性。该工具的设计也体现了这一理念——它测量的是对新规范的采纳程度，而非制造中断恐慌。

5. 开源协作与透明验证：工具仓库公开了扫描的完整数据（每个比例附分母、主机聚合敏感度视图），并接受 issue 和 PR。任何误判都可被及时修正，社区可以信赖其结论。这种透明性有助于建立对协议演进路径的信心。