装上了但工具列表是空的：MCP 的两级验收

装上了但工具列表是空的：MCP 的两级验收

一次安装会给出两个结论，多数人只取第一个。

install 记通过，意思只是「配置格式被这个宿主接受了」；usable 记通过，才是「进程起来了、工具列表拿到了、模型能调」。全量快照里这两个字段并不相等：install 实测通过 1,398 格，usable 实测通过 1,339 格，中间这 59 格就是本文要拆的东西。

两个字段是两道门，不是一件事

2,601 格里 install 通过 1,398 格占 53.7%，usable 通过 1,339 格占 51.5%，相对差 4.2%。在只报 install 的报告里，这 59 格会被整片记成「可用」；而在真出问题的时候，出问题的往往正好是这 59 格。

59 格差额里，15 格是真断裂

44 格属于「装上了但被打折」：工具数越过宿主上限被截断，或者远程支持缺资料。剩下 15 格是彻底的空转 —— 配置被接受，工具一条都拿不到。

第一行那个条目实测启动耗时 22,675 毫秒，工具列表却是 0 条 —— 进程起来了，慢，而且什么都没提供。它一个人贡献了 13 格，占 15 格的八成以上。

另外 2 格是另一种形态：两个条目的启动耗时都是 0，在 12 个文档规则列里 install 判的是失败，唯独在 claude-code 真机列上 install 记了通过、usable 记了失败。同一批条目在同一张表里被判成两种结论，差别只在「谁去装的」。

50 个零工具条目，占了三成

153 个真实条目里有 50 个 toolCount=0，实测占 32.7%。它们不是同一类东西：

前两类合计 47 个，这 47 个正好就是 11 个文档规则列那恒定的 47 格失败 —— 逐格核对过，集合完全相等，一格不多一格不少。也就是说：文档规则列里的失败数不是宿主指标，是这 47 个条目自己的状态，换哪个宿主都是 47。

claude-desktop 是唯一例外，58 格失败。多出的 11 格不是这 47 个，而是它只认 stdio、把 11 个远程条目判死了。

第三类那 3 个 http 条目从来没被量过：free-agent-tools、huggingface、sentry，每个 17 格全无数据。它们的零工具字段是「没取到」，不是「取到了 0」，不能并进上面两类。

一个反例：16 个工具、起了 10.5 秒，真机三列全败

把视角从宿主换到条目，能看到更极端的一种情况。

wavespeed__mcp 实测有 16 个工具、启动 10,460 毫秒、资源项 1 个，配置格式没问题 —— 它在 11 个文档规则宿主上全部通过，1 个宿主记部分可用。但在三个有真机数据的宿主上，claude-code、gemini-cli、qoder 全部失败。

同一条目、同一份配置，文档规则判「格式对」，真机判「跑不起来」。这两套判据量的根本不是同一件事，而 install 字段只反映前者。

坑一 · 只看 install 就宣布「这个宿主能用」

现象：安装命令返回成功，工具面板却空着。原因：install 只核配置键名与格式，不启动进程、不拉工具列表。解决：装完立刻看一次 tools/list 的长度，为 0 就是没通，别等模型报「找不到工具」。

坑二 · 把零工具当成「这个宿主不支持它」

现象：某个条目在一列里失败，于是把所有零工具条目都算成该宿主的缺陷。原因：47 个零工具条目在 12 个文档规则列逐格相同，失败数恒为 47，与宿主无关。解决：先按 toolCount=0 过滤，剩下的失败才归因到宿主。

坑三 · 把「起了 22 秒」当成「慢但能用」

现象：启动耗时非零、install 通过，看起来只是慢。原因：该条目的工具列表是 0 条，慢是因为它在等一个永远不会返回的东西。解决：启动耗时与工具数要一起看，只有耗时非零、工具数也非零，才算「慢但可用」。

坑四 · 用 install 通过率去评价宿主质量

现象：两个宿主的 install 通过率差不多，就判它们质量相近。原因：install 通过率主要反映配置格式兼容性，而文档规则列的通过面本来就是同一个数（103），差异全在部分可用怎么记。解决：评价宿主用 usable，并且只用真机列。

一份验收顺序

第一步，装完先拉工具列表。长度大于 0 才算过，长度等于 0 就回去看启动耗时是 0 还是非零。

第二步，耗时非零、工具为零的，去查它到底在等什么，不要靠调编码或加重试绕过去。

第三步，工具数大于 0 但比预期少的，数一遍服务端声明的总数，与宿主上限比一下，超了就精简启用集。

第四步，才轮到评价宿主。用真机列、用 usable 字段、用同一批条目。

失败现象的分类在 坑点清单 里按五组整理好了，零工具这一类单列了一组；宿主侧的工具数上限与传输约束在 宿主能力表，属规则推导。想复现「配置对但跑不通」这条路径，排查方法 里的顺序比逐个试快；工具数正常的条目可以从 server-filesystem 或 context7 进去对照，字段含义见 名词表。

数据口径

数字取自 2026-11-02T19:53:24Z 的全量快照，mode=full、finalChunk=true，采集机 node v22.23.2；真机三列的命令行版本为 claude-code 2.1.311、gemini-cli 0.66.0、qoder 1.1.80。统计剔除 8 个 isFixture 内部占位，153 个真实 server × 17 宿主 = 2,601 格。

toolCount 与 startupMs 是条目级字段，同一行在所有宿主上取同一个值；install 与 usable 是格级字段，逐宿主独立判定。本文出现的「47 恒定」只对 12 个走文档规则的宿主列成立，真机列不适用。

总结

install 与 usable 是两道独立的门，通过数差 59 格，其中 15 格是真空转、44 格是被截断。装完先拉一次工具列表，长度为零就回去看启动耗时；评价宿主时只看 usable 与真机列。把这两件事分开验收，能省掉大部分「装了却调不动」的排查。

适合与不适合

适合：刚装完一个 MCP 服务、工具面板却空着的人；在给团队做宿主准入清单的人；正在核对「配置一模一样、换个客户端就不行」的人；需要引用兼容数据、得说清 install 与 usable 差别的人。

不适合：只想找一条能复制粘贴的配置模板的人 —— 本文没有配置；只用一个宿主、不打算换客户端的人；以及希望把零工具条目当成「宿主缺陷」报出去的人。

标签：MCP、install、usable、零工具、验收顺序

本文由 DeepSeek Harness Hub 自动整理，数据来源于 MCP 兼容性采集快照（2026-11-02），口径见文末。