独立开发者 Roee Tsur 在 2026 年 7 月 12 日，把官方 MCP 注册表里的 7,850 个远程服务器挨个探了一遍。能公开访问的有 4,356 个，其中只有 1 个同时通过了三项必测——discover、routing-headers、session-independence。剩下 90.8% 尚未就绪，距离 2026-07-28 新规范发布不到半个月。
这个比例乍一看像是一场即将爆发的生态崩溃，但作者自己先按住了这个解读：规范文本在 7 月 28 日发布，不是开关一键切换，版本协商照常工作，废弃功能还有至少 12 个月过渡期。他把这次扫描定义为"测适配进度"，不是"倒计时报警器"。
换掉的不是小修补，是整个会话模型
新规范要拆掉的，是 MCP 从诞生起就在用的握手式会话：客户端先 initialize，服务器发个 Mcp-Session-Id，之后所有请求靠这个会话 ID 认领身份。这套东西在负载均衡后面天然别扭——请求可能被分发到任意一台后端，服务器必须记住"这个 ID 对应哪个客户端"，状态没法随便漂移。
新规范换成无状态核心：server/discover 取代握手，Mcp-Method / Mcp-Name 这两个路由头变成每次请求必带，网关靠头信息路由，不用服务器记状态。SSE 长连接式的 elicitation 被 Multi Round-Trip Requests 取代，几个错误码也跟着改。官方 MCP 博客对这套改动的描述和作者在工具里给出的技术细节能对上，说明这不是工具作者自己脑补的解读，而是规范本身的定案方向。
这套改动被作者称为"MCP 自发布以来最大的一次修订"，理由站得住——它动的是协议底层的状态模型，不是加个字段那么简单。
一个数字能不能信，得看验证方法
真正让这次扫描有说服力的，不是"1/4356"这个数字本身，而是作者怎么证明这个数字没数错。他搭了三层校验：CI 里跑两台参照服务器，一台是旧规范的官方 SDK v1，一台是新规范的 RC 版 SDK，工具必须对这两台机器给出唯一正确的判定，任何一个方向的回归都会拉红构建；另外拉了一批行为已知的公开服务器做"已知真值面板"，比如带认证墙的 GitHub MCP 服务器应该判为可读取但无法打分；最后拿官方 conformance suite 单独跑一遍 RC 参照服务器做交叉验证。
90.8%未就绪不是坏消息，是GA前该有的样子
这也是为什么这次的"90.8%未就绪"更接近历史规律而不是异常——协议大迁移历来如此，HTTP/1 到 HTTP/2、OAuth 1 到 2，早期适配率低是常态，真正该警惕的从来不是低适配率本身，而是过渡期结束后仍然按兵不动的那批实现。
- 风险.注册表里约 44.5% 的条目没被计入"可达"范围，原因不明，可能是失效条目也可能是认证墙，这部分被排除在 90.8% 之外，真实的生态就绪率可能被低估或高估。
"1个可达"是怎么被传成假新闻的
这次调研过程里有个很值得记一笔的插曲：另一份检索到的转述把"4,356 个可达、1 个就绪"简化成了"仅 1 个服务器可达"，跟原文陈述明显矛盾。原始数据链路已经做了三层校验，传到二手转述这一步，照样能被压缩成一个错误的结论。
这提示的不是"这份数据不可信"，而是反过来的事：越是权威的一手扫描，越容易在传播过程中被简化、被曲解，读者拿到的"结论"和原始数据之间可能已经隔了好几层信息损耗。看到一个吓人的生态采纳率数字时，先问一句分母是谁、口径是什么，比直接转发更有用。
谁该现在动，谁可以再等等
对已经上线的 MCP 服务器运营者，12 个月的过渡窗口给了缓冲，但 SDK 和主流客户端已经开始往无状态核心迁移，等窗口关闭再动手会踩空。对下游依赖这些服务器的 AI Agent 产品和企业集成方，值得现在就用类似工具摸一遍自己接的第三方服务器名单，看看哪些还卡在旧握手模型上。接下来最该盯的，是规范正式 GA 之后的下一轮扫描数字会不会明显往上走——如果几个月后适配率还在个位数，那才是真正该拉警报的时候。