MCP 新规范生效前扫描：4356 台服务器仅 1 台合规

距离 MCP 2026-07-28 新规范生效还有半个月，一份对 4356 台可达公开服务器的扫描显示，仅有 1 台完全通过兼容性检查。这个数字撕开了 MCP 快速铺开背后的老账。

距离 MCP 新规范（2026-07-28 版本）正式生效还剩半个月，一位叫 Roee Tsur 的开发者干了件所有人都没干的事——把公开可达的 MCP 服务器挨个扫了一遍。

结果发在 Hacker News 上：4356 台可达服务器，只有 1 台完全通过新版规范的兼容性检查。这不是零点几的问题，是 0.023%。你没看错。

MCP 服务器规范兼容性扫描结果柱状图，横轴为规范条目，纵轴为通过率

4355:1，这是怎么扫出来的

Roee 的工具叫 mcp-spec-check，思路很直接：拿到 MCP Registry 的服务器列表，逐个发起握手，按照 2026-07-28 版本 RC（Release Candidate）里定义的行为做一轮探测——能不能正确响应新版能力协商、旧的 Mcp-Session-Id 头是不是还硬编码在返回里、认证流程走的是哪一套 OAuth 应用类型、扩展字段有没有按反向 DNS 命名。

可达的 4356 台里，绝大多数卡在这几处：

仍然依赖 Mcp-Session-Id。这个头在 SEP-2567 里被移除了，配套的协议级 session 也一起下线。老实现里几乎所有做长连接的 server 都在用它维持状态，一旦客户端不再发送，那边直接 400。
服务端主动发起请求的时机不合规。新规范（SEP-2260）明确要求：server 只能在正在处理某个 client 请求的窗口内向 client 发起 request。这堵死了过去很多 server 的"闲聊"式回调设计。
扩展字段命名混乱。SEP-2133 引入了反向 DNS 命名规范，扩展要走 ext-* 独立仓库、由委派的 maintainer 独立发版。老 server 里那些自定义能力，绝大多数还挂在裸字段上，没做迁移。
OIDC application_type 缺失。SEP-837 让客户端在动态注册时显式声明 native 还是 web，避免授权服务器把 desktop/CLI 客户端默认当成 web 然后拒绝 localhost 回调。修得不多，但影响面广。

真正令人不舒服的是那个"1"。它甚至不是某家大厂的官方 server，只是一个不知名开发者的项目。Anthropic 自家的参考实现、GitHub 官方 MCP server、一堆头部厂商的服务，都不在这个"1"里面。

这不是新问题，是老问题终于摊到桌面上

看到这个数字，业内不该感到意外。MCP 从去年下半年爆发式增长以来，一直有一种"先跑起来再说"的味道。

Registry 在 2025 年 9 月才发预览版。在那之前，MCP server 的发现和分发处于半散养状态，很多 server 挂在个人博客、Gist、Notion 页面上。
协议本身还在快速演进。Streamable HTTP、Task 生命周期、MCP Apps 这些能力都是过去半年才逐步固化。SEP-2663（Tasks 扩展）直接改写了无状态模型下的调用生命周期——server 可以先返回一个 task handle，客户端再用 tasks/get、tasks/update、tasks/cancel 拉状态。这几乎意味着，任何做长任务的 server 都得改一遍。
社区先前默认"兼容就是 stdio 起得来就行"。绝大多数 server 作者从来没跑过一遍完整的规范符合性测试，因为过去也没有这样的测试工具。

再叠上 MCP Apps（SEP-1865），server 可以往 host 里塞可交互的 HTML 界面，跑在 sandboxed iframe 里。这是个巨大的能力升级，也是个巨大的安全和兼容性负担——host 端要实现完整的沙箱，server 端要把 UI 逻辑重新组织。你可以想象一下老 server 面对这个特性的迁移成本。

知乎上有过一篇挺犀利的分析，说 MCP 存在四大问题：协议自身认证机制不标准、缺乏工具风险提示、客户端和服务器耦合、分布式身份鉴权没解决。当时看起来像是学术批评，现在这份扫描结果算是给这些批评上了个实证补丁。

编辑观点：这个 1/4356 不完全是坏消息

先泼一盆冷水。0.023% 的通过率，说明 MCP 生态目前离"可以放心用"还有相当距离。特别是企业侧，如果你现在正在评估要不要在生产环境里接一堆公开 MCP server，这个数据应该让你退一步。至少在 7 月 28 日之后的一两个月里，你会碰到一波集中的兼容性坍塌。

但换个角度看，这也是 MCP 第一次有了自我清理机制。过去一年 MCP 的野蛮生长里，没有人真正衡量过"合规"这件事。现在有了 registry、有了 spec-check 这样的工具、有了强制废弃的老特性（比如 SEP-2577 明确废弃了三个核心特性），生态才第一次有了"什么叫合规"的公共答案。

对比一下别的协议：

| 协议 | 从发布到主流实现基本合规 | 备注 | |------|------|------| | HTTP/2 | 约 2 年 | 大厂主推，浏览器强推 | | gRPC | 约 3 年 | 工具链先行 | | GraphQL | 约 2 年 | 半野蛮生长，从未真正统一 | | MCP | 迄今约 1 年半 | 目前 0.023% |

MCP 的时间线其实并不比同类协议差多少，只是这次有人拿着放大镜把过程晒出来了。别的协议早期也一样是"能连就行"，只不过没人做过这样的公开扫描。

220 个工具的 Zabbix MCP server 是另一个信号

就在这份扫描结果发布的同一周，Reddit 上有人开源了一个覆盖 Zabbix 全部 57 个 API 组、暴露 220 个工具的 MCP server。你可以把它理解成"我要把 Zabbix 的整个操作面都塞给 LLM"。

这里就有意思了：

一方面，MCP 生态在广度上还在猛涨。一个协议能让一家运维厂商愿意把 220 个工具挂出来，本身说明这条路走通了。
另一方面，这种"批量导出全部 API"式的 server，恰恰是最容易在新规范下崩掉的类型。它们通常有大量长任务、需要 server 主动通知、session 管理复杂。

换句话说，规模最大的那批 MCP server，规范迁移压力反而最大。这也是为什么这次扫描的低通过率格外让人在意——它意味着未来几个月里，我们会看到大量"能连接但行为异常"的中间状态。

时间表：7 月 28 日之后会发生什么

按 modelcontextprotocol.io 的日程，2026-07-28 是新规范正式生效的日期。这之后：

主流 host（Claude Desktop、Cursor、各家 IDE 插件）会陆续切换到新版协议协商。旧 server 会开始出现"能启动但用不了"的报错。
Registry 会更新元数据字段，标记 server 声明的规范版本。合规的 server 会在客户端里被优先推荐。
过渡期大概会持续到 Q4。经验上，这种协议级迁移永远不会真正干净——总有一批 server 会长期停在旧版本上，直到 host 端彻底停止兼容。

对开发者来说，接下来两周该做的事很清楚：

把自己维护的 MCP server 拿 mcp-spec-check 跑一遍（GitHub 上已经开源）。
检查代码里对 Mcp-Session-Id、initialize 响应结构、server-initiated request 时机、扩展命名的假设。
如果用了 OAuth，确认 application_type 声明。
如果做长任务，尽早往 Tasks 扩展迁移。

一点行业侧的观察

MCP 现在的处境其实很像 2016 年前后的 gRPC——协议本身设计得不错，但生态实现质量参差不齐。区别在于，MCP 直接把"AI 调用外部工具"这件事标准化了，所以它的失败代价比 gRPC 更高：一旦生态碎裂，AI agent 的可用工具集就会跟着碎裂。

这也是为什么 OpenAI 至今没有明确表态是否会全盘接受 MCP。有一种可能性是它会推自己的规范，那才是真的"小院高墙"。但从这次 1/4356 的数据看，MCP 阵营首先要把自己内部的合规问题解决掉——否则外部竞争者不用出手，生态自己就先散了。

顺带一提，如果你在用 OpenAI Hub 这类聚合平台，MCP server 的兼容性问题目前不会直接影响到 API 调用侧——聚合的是模型能力，MCP 是 client-tool 侧的协议。但如果你在自己的 agent 里同时用了聚合模型和 MCP 工具链，就要留意 7 月 28 日之后的这波协议切换。

最后，那个通过检查的"1"是谁，值得所有 MCP server 作者去看看它的实现。这大概是过去半年里 MCP 生态里最有含金量的一次单点认证。