161 个样本换掉 70 个：MCP 通过率不能跨天比的原因
三天后重采，样本条数仍是 161，但只有 91 个 server 与上次重合，另外 70 个换成了新的。同一宿主的整体通过率只动两三个点，拆开看却是同分母 89.0%、新增样本仅 42.9%。跨天比较通过率，比的其实是样本构成而非宿主本身。
161 个样本换掉 70 个：MCP 通过率不能跨天比的原因
先给结论：同一张 MCP 兼容矩阵，隔两天再看，整体通过率可能只动两三个百分点，看着很稳。但那个稳定是假象 —— 样本换了将近一半，两天的数字根本不是同一批 server 算出来的。想判断「宿主变好了还是变差了」，必须先把分母锁死。
口径交代。两次采集用的是同一台采集机、同一套脚本。基线是汇总文件 mcp-data.json，generatedAt 为 2026-11-02T19:53:24Z，mode 为 full、finalChunk 为 true，161 个 server 乘 17 个宿主、2737 格。重采是 11 月 5 日凌晨跑完的三份单宿主分片：claude-code 于 17:49Z、gemini-cli 于 18:43Z、qoder 于 20:05Z，三份都是 mode: full、各 161 个 server。下面每个数字都是今天在原始 JSON 上现场重算的。宿主侧的配置键名与能力边界见宿主能力对照，字段定义见术语表。
一、161 没变，样本换了 44%
第一件容易被忽略的事：两次的 server 条数都是 161，一个不多一个不少。数字没变，很容易让人以为「采集的是同一批东西」。实际比对 slug 之后：
| 项目 | 数量 | 占比 |
|---|---|---|
| 两次都在（可做同分母对比） | 91 | 56.5% |
| 今天新增（上次没有） | 70 | 43.5% |
| 上次有、今天已轮出 | 70 | 43.5% |
按 name 字段再核一遍，70 个新增与 70 个轮出的样本之间没有一组能对上，也就是说这不是「改名」，是真的换了一批。今天这三份分片彼此完全一致（交集 161、两两交集都是 161），所以「换样本」发生在两天之间，不是发生在宿主之间。
这就带来一个直接后果：拿 11 月 2 日的 67.7% 和 11 月 5 日的 68.9% 相比，得到的差值里混了两个变量 —— 宿主有没有变，以及样本换没换。而后者的量级远大于前者。
二、表面变化和真实变化差一个量级
把三个有真机结论的宿主逐列拆开，用三种口径各算一次：
| 宿主 | 11-02 全表 | 11-05 全表 | 表面变化 | 同 91 格（11-05） | 新增 70 格（11-05） |
|---|---|---|---|---|---|
| claude-code | 109 / 161（67.7%） | 111 / 161（68.9%） | +2 | 81 / 91（89.0%） | 30 / 70（42.9%） |
| gemini-cli | 40 / 161（24.8%） | 40 / 161（24.8%） | 0 | 34 / 91（37.4%） | 6 / 70（8.6%） |
| qoder | 39 / 161（24.2%） | 36 / 161（22.4%） | −3 | 33 / 91（36.3%） | 3 / 70（4.3%） |
看懂这张表只需要一件事：同一个宿主，同一时刻，两批样本的通过率差了一倍到八倍。claude-code 在留存的 91 个上是 89.0%，在新增的 70 个上只有 42.9%；gemini-cli 是 37.4% 对 8.6%；qoder 是 36.3% 对 4.3%。
所以「gemini-cli 两天都稳定在 24.8%」这句话是巧合，不是稳定。它的留存部分 34 个通过、新增部分只进来 6 个，两个数凑出来正好还是 40。实测这三列的表面变化合计只有 5 格，而同分母与新增之间的差距是 46 个百分点 —— 真正值得解释的量级在后一列，不在前一列。
三、新增样本为什么通过率低
不是新 server 质量差，是样本构成变了。把 91 个留存样本和 70 个新增样本的结构并排：
| 结构特征 | 留存 91 个 | 新增 70 个 |
|---|---|---|
| 工具数为 0 | 10（11.0%） | 38（54.3%） |
| 类别为「未分类」 | 5（5.5%） | 35（50.0%） |
| 传输方式 http（远程） | 14（15.4%） | 0 |
| 需要认证 | 1（1.1%） | 0 |
新增的 70 个里超过一半是零工具 server，一半是未分类的尾部项目，而且全部是本地 stdio、全部不需要认证。这类样本本来就不容易在宿主里跑通 —— 它们连工具都列不出来。上一轮那 91 个里包含 14 个 http 远程 server 和 8 个官方参考实现，天然通过率高。
实测这两批的差距是结构性的：留存 91 个里零工具只占 11.0%，新增 70 个里占到 54.3%，而这个字段本身就是最强的失败预测因子（工具数为 0 的 server 在 850 格里通过格是 0 个）。
四、锁死分母之后，噪声基线是 1.1% 到 5.5%
真正能用来判断「重测稳不稳」的，只有那 91 个共同样本。逐格比对两期判定：
| 宿主 | 同分母格数 | 判定变化格数 | 变化率 |
|---|---|---|---|
| claude-code | 91 | 1 | 1.1% |
| gemini-cli | 91 | 4 | 4.4% |
| qoder | 91 | 5 | 5.5% |
合计 10 格变化，方向恰好对半：5 格由 pass 变 fail，5 格由 fail 变 pass。明细里有一条很说明问题 —— firecrawl 在三个宿主上同时由 pass 变 fail，而它自己的工具数从 3 变成了 0、启动耗时从 2117 毫秒变成 0。也就是说这一格变化的原因在 server 侧，三个宿主只是同时反映了它。
反向的 5 格同样成组：server-time 与 server-fetch 在 gemini-cli 和 qoder 上同时由 fail 变 pass，50heads__mcp 在 qoder 上由 fail 变 pass。
由此得到两条可直接用的判据。第一，单格变化先查 server 侧（工具数、启动耗时），再看宿主；一个 server 在多个宿主上同时翻转，几乎不会是宿主的问题。第二，差两三个点不要解释成宿主升级或退化 —— 在 91 格这个量级上，1 到 5 格的自然波动就能造成 1.1% 到 5.5% 的差，低于这个幅度的变化没有信息量。
五、判定稳住了，耗时完全没有
同一个 91 格样本里，另一个字段的表现完全不同。取两期都大于 0 的 82 个启动耗时做对比：
- 相对倍数中位数 2.52，也就是同一天重跑，普遍慢了一倍半。
- 变化幅度区间 0.48 倍到 14.9 倍。
- 82 个里 66 个（80.5%）变化超过 20%，45 个（54.9%）变化超过一倍。
具体到单条：server-fetch 从 3623 毫秒变成 7110 毫秒，cyanheads__git-mcp-server 从 5411 毫秒变成 13395 毫秒。判定一点没变，耗时翻了一倍多。
中位数整体上移 2.5 倍，更像采集环境的负载或网络变化，而不是几十个 server 同时变慢。所以耗时这一类结论只能当次有效：用它排「谁最慢」可以，用它跟两天前的数字比「有没有变快」不行。想量启动耗时，见方法说明里的取数口径。
六、三条口径，可以直接拿去用
- 比通过率必须先锁分母：只对两次都出现的 slug 求差，并明确写出共同样本数。数字变了分母没锁，结论不成立。
- 样本条数恒定不等于样本恒定：这次两期都是 161，重合只有 91。固定条数的滚动抽样最容易制造「稳定」的错觉。
- 字段可信度分级：判定（pass / fail / limited / na）可用，同分母噪声 1.1% 到 5.5%；耗时不可跨天比，同分母中位漂移 2.5 倍；证据级别（文档 / 真机 / 协议实测）必须跟着结论一起引用。
收尾
一句话：跨天看 MCP 兼容表，先问分母是不是同一批 server。是，就按 1.1% 到 5.5% 的噪声去判；不是，就只能各自描述，不能相减。
今天这批样本里，server-time 与 server-fetch 两个参考实现在两个宿主上由 fail 转 pass，可以拿它们的详情页当作「重测会回升」的实例。逐宿主的能力边界在宿主能力对照，按现象反查原因在坑点清单。
结论采集于 2026 年 11 月 5 日，实测方法见 数据怎么来的。