49 个 server 工具数为零，其中 47 个没起来过

49 个 server 工具数为零，其中 47 个没起来过

兼容表上一个格子写着 fail，读者通常只会得到一条信息：这个装不上。但 fail 至少有三种来路 —— 真的装不上、装上了但没东西可调、以及压根没测出结论。这三种在表上长得一样，处置动作完全不同。

口径先钉住。数据取自子站五份分宿主采集文件（claude-code、codebuddy、opencode、gemini-cli、qoder），五份都是 mode=full，合计 754 格，server 目录以 161 个为全集。下文所有数字都是 2026-11-02 在原始 JSON 上现场重算的，没有引用任何二手汇编。判定字段的含义见判定方法，最常撞的几类现象见坑点清单。

三个数先分开：49、47、2

在 161 个 server 里，toolCount 为 0 的有 49 个。这 49 个里，startupMs 也为 0 的有 47 个。

两个零值高度重合，但不是同一个集合。差的那 2 个是 fixture-zero-tools 与 getmarrow__mcp —— 它们确实被拉起来过，启动耗时分别记到 979 ms 与 5,780 ms，只是起来之后工具数是 0。

这个包含关系要先记住：零启动耗时 ⊂ 零工具，47 是 49 的子集，剩下的 2 个才是「装上了、进程活着、但没有工具」。反过来「工具是零、进程起过」只可能是这 2 个，没有第三个。

47 个展开是 175 格

把这 47 个按五个宿主展开：claude-code 47 格、gemini-cli 47 格、qoder 47 格、opencode 28 格、codebuddy 6 格，合计 175 格。

这 175 格的结论分布是这样的：usable fail 159 格、na 15 格、pass 只有 1 格。

2026-11-02 在五份原始 JSON 上实测重算，这 175 格里通过率是 0.6%，175 分之 1。也就是说：一个 server 只要启动耗时记为 0，它在这张表上几乎注定是 fail，不管你换哪个宿主。

那 15 格 na 值得单独看一眼。它们是 3 个远程 server —— free-agent-tools、huggingface、sentry，note 写的是「本机网络连不上这个服务，未取得结论」。注意这是「没测出结论」，不是「测出来不通」。采集机当时连不上这三个端点，这件事与宿主、与 server 实现都无关。

剩下的 2 个才是「装上了但工具是空的」

fixture-zero-tools 在五个宿主上是 install pass、usable fail，note 全是「它没有对外提供任何工具，装上也没东西可调」。getmarrow__mcp 在 claude-code、opencode、gemini-cli 三个宿主上是同一形态。

这两个与上面那 47 个的区别很重要：47 个是进程根本没起来，你去查命令行、包名、权限；这 2 个是进程起来了、握手也过了，只是注册表是空的，你去查命令行是白查。

判断只看一个字段：toolCount。进程在不在、退出码是不是 0、日志有没有报错，这三个信号在这里都不解决问题。toolCount 是 0，就说明没有东西可调，跟装得好不好无关。想看这两个样本的逐宿主格子，直接翻fixture-zero-tools 与 getmarrow__mcp。

12 格「install 通过」里混着两种东西

全表 install=pass 但 usable=fail 的，实测共 12 格，逐格拆开是两种：

• 10 格 note 写「它没有对外提供任何工具」，对应 server 的 toolCount 是 0；
• 2 格 note 写「这个平台用不了它」，可 install 偏是 pass —— 分别是 codebuddy 上的 parallel-search 与 opencode 上的 nexus-windows-codex，而这两格在对应文件里的 startupMs 又是 0。

后 2 格是自相矛盾的：启动耗时为 0 意味着没起来，install 却是通过。这说明在这套采集里，install=pass 不等于「进程启动过」，两个字段不是同一层的判定。遇到这种格子，不要用 install 去推断进程状态。

一个副作用：毫秒数不通用，零值通用

有个细节必须交代，否则「启动耗时为 0」这句话会被误用。

同一批 server 的具体毫秒数在几份文件里并不一致：实测比对 codebuddy 与 qoder 交集的 89 个，其中 83 个的 startupMs 数值不同；opencode 在 126 个交集里有 99 个不同。所以「某 server 启动要 3,532 毫秒」这种话，只在某一台的某一份文件里成立。

但「是不是 0」这个分类是稳的。47 个零值在 qoder、claude-code、gemini-cli 三份文件里完全一致；opencode 的交集内只多 1 个、少 1 个，codebuddy 的交集内只多 1 个。零值是一个跨宿主稳定的 server 级属性，毫秒数是带宿主色彩的测量值。

这两件事要分开用：用零值筛「有没有被拉起来过」，不要用毫秒数比「谁启动快」。全表非零 startupMs 的中位数是 3,532 ms，最大 48,750 ms，超过 10,000 ms 的有 19 个 —— 这些数字能说明分布很宽，但不足以排快慢。

还有一类空格子：没测过

比 na 更隐蔽的是「连格子都没有」。codebuddy 那份文件只覆盖 110 个 server，qoder 的目录里有 72 个它没测过，而且这 72 个全部是 stdio。

表上看不见不等于表上是 fail。如果拿 codebuddy 的 110 个分母去和别人的 161 个分母比通过率，缺的 72 个既不进分子也不进分母，比率看起来会更漂亮，但那是分母缩小的结果，不是质量更好。

一眼筛：三步

第一步，看 startupMs。 是 0 就直接归到「没起来」，别去翻工具列表。这类格子占 175 格，通过 1 格，几乎没有例外。

第二步，非零但 toolCount 是 0 的，归到「装上了没东西」。 全表只有 2 个 server 属于这一类，两个的名字在上文都有。

第三步，剩下的才按 install 与 usable 分。 install fail 查命令与运行时；install pass、usable fail 才查握手与注册。想看逐格明细，从兼容矩阵进，宿主能力字段在宿主能力对照页。

一句话收口

同一种 fail，三种含义：没被拉起来（175 格）、拉起来了但没有工具（12 格里的 10 格）、根本没测出结论（15 格 na，另有 72 个连格子都没有）。把这三类混在一起算通过率，算出来的数会同时低估也高估 —— 低估是因为把「没测」当成「不通」，高估是因为把「没测」从分母里剔掉了。