近12万次MCP探测揭示可用性与工具漂移

公共 MCP 服务到底稳不稳，Agent 缓存的工具列表又能信多久？MCP Checkup 持续探测了数千个远程端点，汇总出 119,510 份带签名的观测记录。结果是：多数服务在采样时能够响应，但工具列表变化相当普遍，客户端不能把第一次拿到的接口定义当成长期契约。

这份报告值得读，既因为样本规模，也因为作者交代了统计边界：没有凭证、每 12 小时探测一次、只读工具列表第一页。理解这些条件，才能判断数字对自己的 AI 应用有多少参考价值。

89.4% 全勤，为什么还不能当成可用性承诺

截至 2026 年 10 月 21 日 23:00 UTC，作者的探测清单有 5,916 个端点，其中 5,912 个在此前七天内留下了记录。最新记录中，3,564 个获得完整覆盖签名，1,898 个获得认证受限的部分覆盖签名，450 个未签名。

这里的「完整覆盖」只是全部检查都尝试过。一次典型记录在 15 项检查中只有 10 项得到结论，其余标记为 UNVERIFIED。例如 TLS 证书和延迟检查尚未运行，没有批准的基线时，也无法完成基线比较。

可用性统计使用 9 月 22 日至 10 月 20 日的 29 个完整 UTC 日，纳入至少有七个有效观测日的 4,961 个端点。其中，4,435 个在全部计入日期都能响应，占 89.4%。

但这个指标按天计算：当天每次探测都能到达服务才算正常；存在无响应记录则算故障；只有探测方无法下结论的日期会被排除。未认领服务每 12 小时检查一次，两次探测之间的短暂宕机可能完全看不到。

认证受限服务的全勤比例达到 93.2%，高于完整覆盖组的 90.7%。可这里的「响应」可能只是返回 HTTP 401，登录后的业务是否正常，作者并不知道。

统计规则也在中途收紧：握手期间的 HTTP 5xx 从 9 月 23 日起计为故障，连接失败从 9 月 27 日起计为故障，因此窗口前段偏向乐观。作者还排除了探测器当天部署三次、无法确认故障来源的 9 月 21 日；若纳入，全勤比例会从 89.4% 降到 88.3%。

这组数字说明服务在定时采样时通常能响应，不能替代业务成功率或分钟级可用性。

工具列表会变，缓存多久不能凭感觉决定

对 Agent 开发更有用的发现，是工具列表漂移（tool-list drift）。作者比较同一服务相邻两次返回的工具名称、描述和输入 schema，观察接口定义发生了什么变化。

七天窗口覆盖 3,029 个服务：25.8% 出现过变化，12.4% 增删过工具，7.7% 在名称不变时修改了 schema，5.6% 只修改描述。后三类互斥，每个服务按首先适用的类别归入一次。

30 天窗口中，815 个服务有 48.8% 出现变化，32.0% 增删过工具。但两个窗口的服务集合不同，不能据此推断变化正在加速。作者另外报告，最近五周的周变化比例维持在 26% 至 29%，工具增删比例为 12% 至 14%。

「潜在破坏性变化」包括工具消失、顶层参数被删除、参数声明类型改变，以及参数新增必填要求。七天窗口占 3.8%，30 天窗口占 14.1%。

这不是调用失败率。统计没有执行真实业务调用，类型变化也未必破坏已有请求。例如从普通类型改成 anyOf，可能扩大了接受范围，却仍被启发式规则计作类型变化；反过来，规则跳过嵌套 schema，也可能漏掉风险。

原文的三个匿名案例把问题讲得很具体：一个服务分十步增加约 60% 的工具，按周刷新会经常错过新能力；另一个拥有数百个工具的服务，在一次握手失败后几乎换掉了全部工具名；还有服务把 number 改成 integer，按新 schema 校验的客户端会拒绝此前允许的 2.5。

变化还集中在少数服务上。30 天内，1,509 个服务贡献了 5,054 次列表变化；其中 98 个变化至少十次，占全部变化的 29%。只有 41 次变化精确恢复到该服务此前的列表。

这支持按服务分别制定刷新策略，但没有证明每个服务都需要高频轮询。

签名能证明记录没被改，不能证明服务可靠

119,510 份签名记录证明的是观测记录的来源和完整性。作者使用 Ed25519 签名，并放入 DSSE envelope；验证者可以检查记录是否由对应密钥签发，以及内容是否被修改。

它不保证服务明天仍然正常，也不覆盖登录后才能看到的行为。其中一份测试记录用了未公开的开发密钥，验证器会拒绝它，说明「存在签名」和「通过可信密钥验证」也有区别。

认证受限记录只覆盖四项：可达性、重定向策略、传输和认证元数据。其他检查带原因标记为 UNVERIFIED，覆盖范围写入签名载荷。这类签名从 10 月 20 日才开始生成，更早的同类记录未签名。

协议兼容性同样需要保留边界。完成握手的 3,602 个服务中，50.1% 声明 2025-11-25，29.0% 声明 2026-07-28，16.5% 声明 2025-06-18，另外仍有 2024-11-05 和 2025-03-26。

探测器先通过 server/discover 提议 2026-07-28，不支持时退回 initialize，提议 2025-11-25。共有 761 个服务，即 21.1%，返回更早版本。这属于协议允许的协商行为，不能直接判为故障。

认证方面，2,150 个携带 WWW-Authenticate challenge 的 HTTP 401 响应中，2,011 个按 RFC 9728 指向 OAuth 受保护资源元数据文档。单次抓取发现，其中 1,997 个与 challenge 一致，10 个 scopes 声明矛盾，4 个返回 HTTP 错误。认证入口存在，仍需要检查它是否自洽。

如果要验证下载的签名封装，需要先取得 checks 仓库和官方密钥列表。原文给出的验证命令如下，解决的是记录真实性检查：

node packages/verifier/verify-attestation.mjs --envelope --keys keys.json

注意 --keys keys.json：验证依赖可信密钥列表，同时检查密钥是否撤销，以及 observed_at 是否处于有效期。验证器本身不联网，要求 Node.js 22.18+ 或 24+，没有安装步骤。

我的判断

我认同作者把可达性、接口漂移和签名可信度分开处理。对接入 MCP 的应用来说，这三件事对应不同问题：能否连上、原来的调用是否还成立、观测证据是否可信。压成一个总分，反而容易掩盖差异。

但这些结果来自单一 Cloudflare Workers 观测位置，没有凭证，也没有真实业务调用。它们不能直接代表国内网络环境、登录用户体验或生产任务完成率。工具列表只读取第一页，漂移统计还排除了七个分页服务和三个探测更频繁的已认领服务。

刷新工具列表是合理方向，具体多久刷新一次，报告没有给对照实验。每日刷新、调用失败后刷新、按服务变化历史刷新，哪种成本更低、恢复更快，仍需各团队验证。

描述变化也不能一律当成噪声。描述会参与模型选择工具和组织参数，但报告没有测量描述变更对 Agent 行为的影响，不能据此声称调用质量已经下降。

能拿来做什么

• 在 Node MCP 客户端保存工具名称、描述和输入 schema 的快照。刷新时记录差异，优先关注工具删除、参数类型改变和新增必填参数，让失败调用有可追溯的接口依据。
• 给 AI 编程助手区分连接失败、认证失败和工具调用失败。HTTP 401 只能证明认证入口作出了响应，前端状态页应分别展示连接、登录和实际任务的结果。
• 为工具缓存设计受控的刷新与恢复流程。出现工具不存在或参数校验失败时，可以重新获取列表并重新规划调用；涉及写入操作时，应先确认执行状态，避免直接重试造成重复操作。
• 把签名验证作为观测证据的校验步骤，同时读取 coverage 和 UNVERIFIED 原因。评估生产接入时，再补充目标网络、有效凭证和真实任务下的测试。