MCP 通过率 0% 与「工具找不到」：两种灰区的自查清单

一张 17 行 × 153 列的表摊开，最先扎眼的是两个 0.0%。往下翻，又能在别的宿主那一列看到「模型说找不到这个工具」。这两种现象被问得最多，成因却不在一个层面上：前者是根本没测，后者是测了、连上了、能力被宿主截了一刀。

2,601 个格子的分布是 pass 1,339（51.5%）、fail 856（32.9%）、limited 55（2.1%）、na 351（13.5%）。二值读法会把后两类硬塞进前两类，于是 0% 被当成「全军覆没」，limited 被当成「可以用」。想先看同类插件的实测口径，可以对照 MCP 兼容手册；要按宿主逐个比，完整插件清单与汉化避坑指南 那张总表更直观。

三种症状，三种不同的病

你看到的	表里那一格写的是什么	它其实在说	先查哪一头
某宿主通过率 0.0%	153 格全 na	这台机器上没跑过这一列	采集机有没有该宿主的入口
工具少一半，模型说找不到	limited，reason 提到工具数上限	连上了，但超出宿主容量	累计工具数 vs 宿主上限
资源取不到，界面不报错	limited，reason 提到资源项	宿主不支持 resources 原语	宿主文档的 Supported Features
配了 url 连不上，也没报错	fail，或压根没条目	该宿主只吃 stdio 配置	宿主的传输类型

坑一 · 把 na 读成失败，得出「全军覆没」

现象：某个宿主的通过率是 0.0%，看上去像「这个宿主完全不支持 MCP」。原因：那 153 格全部是 na，hostAvailability 里 available:false，reason 写「未知原因」。351 格 na 里 306 格的原因是采集机没装这个平台的命令行工具，另 45 格是本机网络连不上这个服务。「没测」被当成了「测了不通」。解决：读表先过滤 na 再排名，或者改算有效通过率 pass/(总格数−na)。那 7 个并列 68.7% 的宿主就是这么算出来的；分母为 0 的宿主判「未测」，不参与排名。

坑二 · 把 limited 读成可用，直到模型说找不到

现象：单元格不是 fail，连接状态正常，于是归档成「能用」。原因：55 格 limited 拆开是三类——zed 30 格（server 有资源项，平台不支持这类能力）、lingma 11 格（远程 MCP 是否支持缺可靠资料，不做判断）、cursor 10 格加 windsurf 4 格（工具数超宿主上限，需精简后可用）。55 格落在 45 个不同 server 上，说明同一个 server 会在多个宿主各判一次。解决：limited 单独一列，别并进 pass；按 reason 分派动作，能减工具的就减，缺资料的留待验证，缺原语的换宿主。

坑三 · 工具数超上限，被截断的那部分不报错

现象：部分工具莫名不可见，模型说找不到，但宿主界面没有红色报错。原因：单个 server 的工具数就有 628 个，同时越过「约 40」与「约 100」两种上限，在两种宿主上各记 1 格；108、79、48 个工具的 server 同因。cursor 那条约 40 的软上限，本地用 41 / 45 / 90 三个合成样本验过边界。解决：接之前先数 tools/list 的长度；超过上限就精简启用集，或用宿主的工具筛选只暴露必要项。连接成功不等于工具齐全，这两件事要分开验收。

坑四 · 只认 stdio 的宿主，配了 url 也不报错

现象：配置里写 url 不生效，界面上一个工具都看不到，也没有任何报错。原因：Claude Desktop 的 config 是 stdio-only，远程端点根本不会被解析。解决：二选一——用 Connectors UI 走 OAuth 连接，或用 mcp-remote 把远程地址包成本地可执行命令再按 stdio 配。同类「看着对却连不上」的还有键名问题：Windsurf 远程用 serverUrl、Roo Code 必须显式写 type、Gemini CLI 的 httpUrl 与 url 语义不同、WorkBuddy 写 streamablehttp（无连字符）。

一份能照抄的自查顺序

1. 先看 na 的 note。两种原文对应两种动作：没装 CLI 就去补安装，网络连不上就去查出网。这一步不做，后面全是空转。
2. 再看 limited 的 reason。三类分派：资源原语不支持 → 换宿主或改用工具返回承载；远程支持缺资料 → 标待验证，别记 pass；工具超限 → 减工具。
3. 数 tools/list。超过 40 就要怀疑截断。
4. 确认传输。本批 stdio 2,363 格、http 238 格；http 在只认 stdio 的宿主上必然失败，先对传输再谈兼容。

有效通过率可以手算，两个例子够用：

有效通过率 = pass / (总格数 − na)
codebuddy  = 0 / (153 − 153) → 分母为 0，判「未测」，不排名
gemini-cli = 34 / (153 − 3) = 22.7%

两个灰区不该混进分母

351 格 na 让两个宿主看起来是 0%，55 格 limited 让 45 个 server 看起来「能用」。两种误读都会把横向对比带偏：前者把环境问题记成宿主缺陷，后者把容量问题记成能力达标。表里四类结论并存不是啰嗦，是让这两种错法在学校对时就能被发现。

总结

看到 0% 先问是不是没测，看到「能用」先问有没有被截断，两个灰区各自单列之后再算 pass/(总−na)；想把同类插件的中文清单与安装形态一次对完，见 完整插件清单与汉化避坑指南。

适合与不适合

适合：手里有一张 MCP 兼容表要读；正在排查「工具找不到」；要向同事解释某宿主为什么是 0%；自己也在跑多宿主采集。
不适合：想要「哪个 server 最好用」的排行，这里只讲怎么读结论；需要认证类判断的读者，本批 authRequired 只有 1 个 server 且 17 格全是 na，给不出结论。

标签：MCP、DeepSeek Harness、兼容性测试、排错清单

本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。