先看工具数再查宿主：MCP 装不上的三层筛

先看工具数再查宿主：MCP 装不上的三层筛

先把口径交代清楚。数据取自采集机的汇总文件，生成时间 2026-11-02T19:53:24.631Z，即北京时间 2026-11-03 03:53，mode 为 full、finalChunk 为 true，采集器版本 dev，采集机 Node v22.23.2。161 个 server 乘 17 个宿主，一共 2737 格。本文每个数字都是 2026-11-03 在原始 JSON 上现场重算的。判定口径见判定方法，各宿主自身的硬约束见宿主能力对照。

2737 格里，通过 1438 格、受限 59 格、失败 873 格、未测 367 格。看到 873，很容易直接得出「三成多装不上」。这个数是真的，但它不是「装不上」的量 —— 它是三层不同问题叠在一起的结果。按顺序拆开，每一层的结论都不一样。

第一层：这个 server 到底有没有工具

先把 toolCount 为 0 的挑出来。161 个 server 里有 51 个属于这一类，它们对外不提供任何工具，装上也没东西可调。

这 51 个 server 占掉 867 格，通过 0 格。其中 720 格失败、147 格未测。失败分布得很整齐：48 个 server 在全部可测宿主上一致失败，48 乘 15 等于 720，正好对上，一格不多。

把它们剔掉之后，只剩 110 个真正有工具的 server：1870 格，去掉 220 个未测，可测 1650 格、失败 153 格，失败率 9.3%。

同一个数据集，36.8% 和 9.3% 都是真的。区别是前者把「本来就没有工具」的 server 算进了「装不上」。这两件事的处置完全不同：前者要换一个 server，后者才需要排查环境。

工具数最大的一个是 628 个（adbutler__mcp-server），实测它首次列工具就要占用宿主不少时间 —— 这类 server 的问题在容量，不在配置。想按工具数筛同类，直接在清单页看每条的 toolCount。

第二层：宿主吃不吃这种传输

剩 110 个 server 后，失败从 873 降到 153。这 153 落在哪里，才是本题的重点。

按传输切：110 个里 99 个是 stdio、11 个是远程（streamable-http 或 sse）。再按宿主切，失败高度集中：

gemini-cli 与 qoder 两家在 stdio 上实测失败 141 格，占 153 的 92.2%。而这两个宿主在远程 server 上 11 格全过，一格没掉。

claude-desktop 恰好反过来：stdio 99 格全过，远程 11 格全挂。这是它只认本地 stdio 的直接后果，属于能力边界而不是配置错误，写在坑点清单 B 组里。

所以「这个宿主行不行」这句话本身不成立，得说成「这个宿主对这种传输行不行」。同一份 server 代码换个传输方式，结论就可能反过来 —— 拿一个宿主的经验推全局，是最常见的误判来源。

第三层：最后才怀疑配置

前两层排完，才轮到配置写法：command 与 args 怎么分、环境变量传没传、包名有没有写版本、依赖装没装、超时够不够。

这一层最容易白忙，因为很多「配置问题」其实是上一层的能力边界。动手前先确认包能取到：

npm view <包名> version dist-tags engines

返回空或 404，改配置一行都没用。有返回再逐项改，一次只改一处 —— 几处一起改，出问题也分不清是谁起的作用。

三层筛按什么顺序走

顺序不能换。先查配置是最常见的错，因为配置是你能改的东西，而工具数和宿主能力你改不了。但按比例算，前两层已经解释了 153 格里的绝大部分。

三层筛覆盖不到的两个边界

三层筛能解释 153 格，但有两类问题它答不了，遇到要单独处理。

一类是启动耗时。40 个 server 启动超过 5000 毫秒，最慢的一个 55285 毫秒（b1-mcp-server），其次 34517 毫秒。这类 server 在「装上了、连接也绿」之后才暴露问题：宿主拉工具列表时等不到返回，超时或空列表。它不属于任何一层筛，而是容量与超时设置的问题，处置方式是调大超时或换一个启动更快的同类。

另一类是授权。161 个 server 里只有 1 个需要凭据，在自动化环境里验不了，它会一直显示未测而不是失败。

这两类的共同点是：表格里的红格看起来和「装不上」一模一样，但原因既不是工具数、也不是传输、更不是配置。分不清这三者，就会一直在一个错的方向上改参数。

未测的格子不要当失败

367 个未测格里，322 个来自 codebuddy 与 opencode：各 161 格全未测，原因是采集机没装这两个平台的命令行工具，hostAvailability 里记的是 available:false、reason:"未知原因"。剩下 45 格是远程 server 在本机网络下连不上，没取得结论。

这类格子和失败在表里长得一样，读法完全不同。实测里有一处特别值得记住：server-everything 在 codebuddy 那列 161 格全未测，在 qoder 那列是失败 —— 同一行两列都显示不可用，但一列是没跑，一列是跑过不通。

一句话收口

873 不是「装不上」的数量。先按工具数分组、再按宿主与传输对齐，可解释的失败只剩 153 格，占 9.3%。想知道自己那个宿主到底测过没有，看宿主兼容矩阵，每一格都带证据来源。