我原以为 MCP 装完就能用，直到工具列表是空的

周一晚上十一点，我把包装上、配置写好、宿主重启，返回码 0。那一刻我以为这件事结束了，还截图发了条只有自己可见的动态，写了两个字：搞定。第二天早上我想让它读一个本地文件，点开工具面板，里面一条都没有。

周一：没有报错，我就当它成了

装的过程确实顺：npm i 一条命令，配置文件里加一段 JSON，重启宿主，面板上多了一个条目。没有红字，没有弹窗，宿主也没说「加载失败」，条目旁边的状态还是绿的。我当时判断「能用」的依据只有一条------它出现在了列表里。

现在回头看，这个依据弱得可笑。宿主能把一个 server 列出来，只能说明它读到了配置，不说明它连上了，更不说明对面有工具。

打开工具面板：零条

不是灰的，不是加载中，是一条都没有。我按顺序做了这些事：刷新面板、重启宿主、删掉重装、换了个端口、清了一次缓存。列表还是零。

中间我甚至怀疑过包本身，去翻它的 README，看到一行「提供 HTTP 端点」，但没往心里去------我配的是本地进程那种写法，脑子里根本没把这两个当回事。

换了个宿主，工具全出来了

真正让我转向的是一个很土的动作：把同一段配置粘到另一个宿主里。那个宿主的工具列表里出来一排，我数了数，十几个。

我把两边的配置并排贴出来看了很久，一个字都没差。同一台机器、同一个包、同一份 JSON，唯一变的是宿主。这说明 server 没坏，坏的是「server 怎么被拉起来」这件事。我原来配的是让宿主起一个子进程（stdio），但这个包只给 HTTP 端点；子进程起来发现没有可用的传输，自己退了，宿主不报错，只是显示 0 个工具。

改成填 URL 之后，原来那个宿主也正常了。折腾一晚上的问题，根因是传输方式配错，跟版本、权限、缓存都没关系。

我踩的第二个误会：装上和能调是两件事

那天之后我才去查站点那份兼容矩阵。它给每个「server × 宿主」的格子记两个字段：install（装得上吗）和 usable（工具能调吗）。

2026-11-02 的快照里，153 个 server 乘 17 个宿主共 2,601 格：install 通过 1,398 格（53.7%），usable 通过 1,339 格（51.5%）。这两个数只差 59 格。

我原以为会差很多。毕竟我遇到的就是「装上了但调不出」，直觉上这种事应该很常见。

结果 98% 的格子根本没区分

59 格，占 2,601 格的 2.3%。剩下 2,542 格里，两个字段要么一起通过，要么一起失败，要么一起是 na。

这个数字把我之前的判断翻了个面：装得上却调不出，不是常态，是少数。所以当它发生在你身上时，它更像一个明确的信号，而不是「MCP 就是这样，忍忍」。

也正因为少见，一旦两个字段分开，定位反而快：分层去看，问题只可能落在中间那一层。

空的工具列表，多半是 server 自己没工具

15 格「install 通过、usable 失败」里，13 格是同一个 server 在 13 个宿主上的同一表现------它根本没有对外提供任何工具。整份快照里 toolCount 为 0 的 server 一共 50 个。

所以「列表是空的」至少有两种含义：一种是 server 没工具，换宿主也没用；一种是宿主没把 server 拉起来，换个宿主就好。我那天是后者。

分清它们不需要猜：直接问 server 要一次工具列表，数长度。0 就是前者，非 0 就是后者。这个动作比换宿主、降版本、清缓存都便宜。

我也看错过一次「0%」

看宿主通过率时，我扫到 codebuddy 和 opencode 都是 0%，第一反应是「这两个宿主不能用」。后来才看清，那 153 格全是 na------采集机没装它们的命令行工具，压根没测。

真正的低分是 qoder 的 21.6%；trae、vscode-copilot、codex-cli、cline、roo-code、continue、workbuddy 并列 67.3%。

na 和 fail 混在一起读，结论会完全反过来。这件事我记住了：看到 0 先问一句「是失败还是没测」。

na 内部还分两种：2,601 格里 351 格未测，其中 306 格是采集机没装那个平台的命令行工具，45 格是本机网络连不上服务。前者是「没法测」，后者是「测的时候那边不通」，都不能拿来当宿主的能力结论。

还有一类我没预料到的失败

44 格 limited，原因分三种：30 格是「它提供资源项，但这个平台不支持这类能力」，集中在 zed；11 格是「这个平台是否支持远程 MCP 缺少可靠资料，不做判断」，集中在 lingma；3 格是工具数超过宿主上限（628 对约 40、628 对约 100、108 对约 40）。

前两类不是坏，是「不支持」和「没测」。第三类才是我自己能处理的------工具太多，删到上限以内就能跑。

顺便说一下传输方式：153 个 server 里 139 个是 stdio、14 个是 http，对应 2,363 格和 238 格。我那天栽的正是这 14 个之一，占比不到一成，但踩中就是百分之百。

我现在的顺序

先问 server 要工具列表，数长度。0 就换 server，不要换宿主。
非 0，再看传输：stdio 还是 http，配置文件里写对的哪一种。
传输对了，再看宿主本身的支持情况。
最后才怀疑版本------它排在最后，是因为我试过，几乎没解决过问题。

另外我会看一眼证据类型。快照里真机 756 格、协议实测 597 格、文档推断 1,248 格。文档推出来的「通过」不能当我自己的实测结果用，这一条我吃过亏。

总结

那天真正浪费的不是排查时间，是「以为已经完成」的那几个小时。我现在的判断标准只有一条：工具列表里有几条。有就是有，没有就是没有，中间不存在「应该能用」。

适合与不适合

适合：手上几个 MCP server 要在多个宿主之间搬的人；正卡在「装上了没反应」这一步的人；愿意先数数字再动手的人。

不适合：想要一份「哪个宿主最好用」排名的人------这份快照里 1,248 格是文档推断，不是真机；只用过一个宿主、一个 server 的人，遇到这事的概率低，读它的收益也低；想要步骤化教程的人，这里只有顺序，没有可复制的命令。

标签：MCP、DeepSeek Harness、踩坑复盘、兼容矩阵

上面这些顺序和数字都是我这几天实测、亲手核对出来的，写错的地方我自己改。