换一个客户端，MCP 的通过率从 68.7% 掉到 22%

同一批 MCP 服务，同一套 JSON 字段，在 A 里十个有七个能调通，换到 B 只剩两个出头。多数人第一反应是回头改配置——缩进、引号、路径、环境变量，改到凌晨也没用，因为问题不在那份文件里。

2026-11-02 的一次全量采集把这件事摊开量化了：161 个 server 铺到 17 个宿主上共 2,737 格，去掉 8 个内部占位后是 153 个真实 server、2,601 格。结果是 1,339 通过、856 失败、55 部分可用、351 无数据。落在可判定范围内的格子里，宿主之间的落差能到三倍。

这篇不列命令，只给判断顺序。对号入座，比盲目重装省时间。

症状对号：先确定你卡在哪一类

你看到的现象	先看哪个维度	常见结论
同一个服务，两个客户端一通一不通	宿主维度的通过 / 失败数	宿主差异，配置本身没错
工具能列出来，调用却报错	部分可用计数	工具数超限或能力项不支持
某个客户端里一条都跑不起来	该宿主是否整列无数据	采集机没装这个 CLI
官方文档说支持，实际连不上	证据档位	文档只核了配置格式
需要授权的服务全无结论	需要授权的格子数	这类服务没有真机数据

现象落在第一行，可以直接跳到第二步；落在第三行，那根本不是兼容性问题，是分母问题。

第一步：这个宿主有没有被真正采到

宿主的可判定格子是 150 格。cline、codex-cli、continue、roo-code、trae、vscode-copilot、workbuddy 这七个并列，103 通过、47 失败、0 部分可用，可判定通过率 68.7%，这是最高的一档。claude-code 稍低，102 / 48，68.0%；windsurf 99 / 47 / 4，66.0%；cursor 93 / 47 / 10，62.0%；claude-desktop 92 / 58，61.3%；lingma 92 / 47 / 11，61.3%；zed 73 / 47 / 30，48.7%。

最下面两行才刺眼：gemini-cli 34 / 116，22.7%；qoder 33 / 117，22.0%。两者都是真机把 150 格跑满，不是推算。

再往下是 codebuddy 和 opencode，两个的 153 格全是无数据，版本号一栏是空的。换句话说，采集机上没有这两个可执行文件，它们的「通过率」不是 0，是不存在。

第二步：确认它走的是文档还是真机

17 个宿主里，13 个的 150 格由「文档 104 + 协议实测 49」拼成；只有 claude-code、gemini-cli、qoder 三个是真机测满 150 格。这个区别决定了数字的含义完全不同——文档核的是配置格式能不能对上，协议实测看的是握手成不成立，真机跑的是从进程启动到工具返回的整条链路。

所以 68.7% 说的是「格式层面有六成八的条目能对上」，22.0% 说的是「真机上只有两成能跑通」。两句话都对，但你不能拿前者当后者用。

第三步：把「部分可用」拆开看

55 个部分可用只落在 4 个宿主上，原因互不相同。

zed 的 30 格是能力项问题：服务提供了资源类条目，这个平台不接这类能力。lingma 的 11 格是资料缺失：远程 MCP 支持与否没有可靠依据，采集方选择不下判断。cursor 的 10 格和 windsurf 的 4 格是工具数上限：命中的服务工具数分别是 628、139、108、79、56、48、44，超过了该宿主大约 40 个和大约 100 个的容量，精简之后才能用。

三件事被塞进同一个字段，是很多人误判的根源。

坑一 · 同一个服务在两个客户端上一个通一个不通

现象：server A 在 workbuddy 里正常，在 qoder 里连不上，两边报错还不一样。原因：两个宿主的实现路径不同，qoder 这一档整体只有 33 格通过，属于实现完成度的问题，不是你在配置层能调和的。解决：先查该宿主在 150 格上的通过数，低于 50 就别在配置上耗时间，换宿主或换服务，二选一。

坑二 · 把「部分可用」当成失败

现象：看到部分可用就判定不支持，直接放弃。原因：这个状态有三种语义，只有一种是真不支持。cursor 和 windsurf 那 14 格是工具太多，删掉几个就能跑。解决：先数服务的工具数，超过 100 的裁到 40 以内再试一次；仍然部分可用，才判定为能力缺口。

坑三 · 采集机没装 CLI 的宿主被当成不可用

现象：看到某宿主整列无数据，得出「它不支持 MCP」的结论。原因：无数据是「没有跑过」，不是「跑不通」。codebuddy 和 opencode 的 153 格全空，只说明采集环境里没有这两个 CLI。解决：整列空的宿主不要读，读它旁边的通过与失败；这种列从你的对比表里整行删掉。

坑四 · 文档说「装上即可用」当成实测结论

现象：照官方说明配完，真机第一步就失败。原因：文档层的 1,344 格只看配置格式，真机层的 796 格才看端到端，两者不是同一个量。解决：把服务分成「格式匹配」和「跑得起来」两栏，只有后者能作为选型依据。

可以照着走的自检顺序

一、列出你实际在用的宿主，逐个对照 150 格里的通过数，把整列为空的划掉。二、剩下的宿主里区分文档档与真机档，真机档优先。三、遇到部分可用，先数工具数再判性质。四、只剩最后一个变量时再动配置，否则你永远不知道是哪一步修好的。

想直接看每格结果，逐格兼容结果 里有按宿主与服务交叉的原始记录；按类别整理的榜单在 MCP 服务榜。

总结

68.7% 与 22.0% 之间差的是宿主实现，不是那份 JSON；先分清无数据、部分可用、失败三种状态，再决定要不要改配置。同类横向对照见 MCP 服务榜。

适合与不适合

适合：配好了却只在部分客户端生效的人；要给团队选统一客户端的人；手里有一批服务想知道哪些能跨端复用的人；正在排查「文档说支持但跑不起来」的人。

不适合：只用一个客户端、从没换过宿主的人；指望这里给出一份万能配置模板的人——不存在这种东西；不愿意按状态分类、只想找一个开关打开就全通的人。

标签：MCP、客户端兼容、通过率、排错

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