MCP server 最后用哪个协议修订答复我们？

我们的探测器向一台 MCP server 要工具列表之前，双方要先商定一个协议修订。探测器每次运行都会记下这次握手得出的修订，签名结果里带着它。2026-09-30 00:12 UTC，目录中 1,468 台 server 里有 1,004 台的最新结果有签名，这些结果记录的修订如下：

记录到的修订	server 数
2025-06-18	580
2026-07-28	394
2025-11-25	14
2024-11-05	11
2025-03-26	5

这就是 /zh/servers/stats 上的协议面板在那一刻的计算结果。面板每天重算一次，所以页面上可能已是更新的数字。

我们怎么问

握手分两步，表里的大部分情况由这两步决定。

第一步，探测器按 2026-07-28 修订的定义发出 server/discover 请求。答复了的 server 会列出它支持的修订，我们记下列表中的第一项。

如果 server 对这个请求回的是 HTTP 2xx 或 4xx，且内容既不是可用的 discover 结果，也不是可识别的新版 JSON-RPC 错误，探测器就回退到较早的 initialize 握手，提出 2025-06-18，并记下 server 答复的修订。这是 2026-07-28 修订给出的兼容规则。支持所提修订的 server 一般会原样答复这个修订。429（要求我们稍后再来）则会结束本轮，不回退。

无论走哪一步，记下的都是我们这次握手得出的修订。它不代表 server 支持的最新修订，方法论页也是这么写的。

两个大数说明什么

2025-06-18 是我们回退时提出的修订。 接受这个提议的 server 都会被记成它，不管它还支持什么。所以 580 数的是「握手落在我们所提修订上」的 server，不是「最新修订是 2025-06-18」的 server；其中有些可能支持更新的修订，只是答应了我们提出的那个。

2026-07-28 是当前修订。 有 394 台，占有签名结果的 39%。这是一个下限，不是准确的台数：被记成其他修订的 server 也可能支持 2026-07-28。

其余 30 台被记成另外三个修订之一。本文不按「哪一步得出的」拆分这张表。

表里没有什么

只统计有签名的结果。目录里另外 464 台的最新结果没有签名。未签名的观测我们只作为原始观测展示，从不当作结论，所以它不进我们作为发现发布的分布。

这张表也不是排名。一台 server 停在较早的修订上，本身并不说明它做错了什么。之所以发布这个数，是因为 agent 连上一台 server 时要回答的问题和我们的探测器一样，知道这件事通常怎么收场会有帮助。

如果你维护一台 server

你的报告页在 protocol_revision 那一行显示最近一次 run 记录到的修订。如果它显示 2025-06-18，而你已经实现了 2026-07-28，最可能的原因是你的 server 对 server/discover 回了 HTTP 2xx 或 4xx，且响应体既不是可用的 discover 结果，也不是可识别的新版 JSON-RPC 错误，于是我们的探测器回退并提出了 2025-06-18。除 429 以外，任何这样的答复都会触发回退，包括 401、403、404、405，不只是说明方法不存在的答复。

数字从哪里来

表格就是 2026-09-30 00:12 UTC 那次计算得出的 /zh/servers/stats 协议面板，读自页面的公开数据 /servers/stats.json。面板把目录中最新结果有签名的 server 按记录到的修订分组。合计 1,004 与目录的 1,468，都是同一页「签名结果」一节里的数字。关于握手的描述取自探测器的握手代码。

更新（2026-10-01）：从套件 0.10.0 起，对 server/discover 的 2xx 答复如果既不是 discover 结果、也不是可识别的新版 JSON-RPC 错误，同样会触发回退；此前只有 4xx 会。上文的数字记录于这次改动之前。