0% 不是全军覆没：MCP 兼容表的两种灰格

0% 不是全军覆没：MCP 兼容表的两种灰格

兼容表上 codebuddy 与 opencode 两列整列是 0.0%，同一张表里 zed 是 48.7%、cline 是 68.7%。三个数字并排，很容易读成「cline 正常、zed 中等、codebuddy 完全不行」。

按 2026-11-02T19:53:24Z 生成的全量快照重算，153 个真实 server 铺到 17 个宿主上是 2,601 格：1,339 格通过、856 格失败、55 格部分可用、351 格无数据。后两类在二值读法里没有位置 —— 塞进 pass 会高估，塞进 fail 会低估，两种错法都让排名失真。

两种灰格，来源不在同一个层面

351 格无数据里 306 格只来自两个宿主：codebuddy 与 opencode 各 153 格，hostAvailability 里记的是 available:false、原因「未知原因」。也就是说 17 个宿主里只有 15 个真被量过，这两个的「0%」不是测出来的，是没测。

剩下 45 格是另一回事：三个远程条目（free-agent-tools、huggingface、sentry）在 15 个可用宿主上各拿 1 格，原因一律是本机网络连不上。逐格核对过，45 格全部落在 http 传输上，stdio 条目一格都没有。

部分可用的 55 格，没有一类是「宿主差」

zed 这列实测 30 格部分可用，原因只有一句：条目提供了 resources，而 Zed 不支持这个原语。这是能力面缺一块，不是连不上。

cursor 实测 10 格部分可用，工具数从 44 到 628 不等，全部越过约 40 的软上限；windsurf 那 4 格同理，越过的是约 100 的上限。这两类属于「能用，但得先减」。

lingma 实测 11 格部分可用，原因写的是「是否支持远程 MCP 缺少可靠资料，不做判断」—— 这是唯一一类诚实的「不知道」，11 格全是远程条目。

55 格散落在 45 个 server 上：37 个各占 1 格、6 个占 2 格、2 个占 3 格。同一个条目在不同宿主会被各判一次，所以「多少条受影响」与「多少格」是两个数。

一条能自己验的等式

把 12 个走文档规则的宿主列并排，把通过数与部分可用数相加，结果只有两个值：

前 11 列全部落在 103，换算 103/150 = 68.7%。zed 与 cline 差了 20 个百分点，差的正是那 30 格部分可用被记在了哪一边 —— 两列的「通过＋部分」完全相同。

claude-desktop 是唯一例外：92 格，比 103 少 11 格，同时失败多 11 格（58 对 47）。这 11 格不是灰格问题 —— 它的配置只认 stdio，11 个远程条目在文档层就被判死。

坑一 · 拿无数据当失败去排名

现象：codebuddy 与 opencode 通过率 0.0%，被写成「完全不支持 MCP」。原因：两列各 153 格全是无数据，分母本身就是 0。解决：先过滤无数据，分母为 0 的列判「未测」、不参与排名，剩下 15 个宿主才可比。

坑二 · 拿部分可用当失败，凭空造出四个劣质宿主

现象：zed 48.7%、lingma 61.3%、cursor 62.0%、windsurf 66.0%，看着明显弱于 68.7% 那一批。原因：这四个数都是把部分可用记成失败算出来的，而它的四类成因没有一类是宿主实现有问题。解决：部分可用单独成列，排名要么用「通过＋部分」，要么只用通过并注明分母口径。

坑三 · 反向踩坑：拿部分可用当通过

现象：格子不是失败，连接状态正常，于是归档成「能用」。原因：14 格容量型部分可用的工具是被截断的，界面不报错，模型拿到的是残缺工具集。解决：容量型必须减工具后重测，缺资料型标「待验证」，都不许直接记通过。

坑四 · 只算总通过率，不问宿主有没有被量过

现象：全表 1,339/2,601 = 51.5%，看着像一个整体水平。原因：351 格无数据把两个未测宿主与三个远程条目的空白一起摊进了分母。解决：分层报 —— 已测 15 个宿主、45 格网络无数据单列、两个整列未测单独声明。

一份处置顺序

第一步看无数据的原文。两种原文对应两个动作：没装 CLI 就去补装，网络不通就去查出网。这一步不做，后面全是空转。

第二步看部分可用的成因。缺原语就换宿主，容量超限就减工具，缺资料就标待验证。三类动作互不替代。

第三步同口径再比。要么统一用「通过＋部分」，要么统一只用通过并声明分母；两套混着用，谁高谁低都是算出来的，不是测出来的。

现象到动作的对照在 坑点清单 里按五组整理好了；宿主侧的能力边界（传输方式、工具数上限、是否支持 resources）在 宿主能力表，那部分属规则推导，不能与真机格混用。想自己复现这套算法，排查方法 有逐步口径；单个条目的逐格记录可以从 context7 或 server-memory 进去对照，全部已发文章在 文章列表。

数据口径

数字取自 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，codebuddy 与 opencode 版本号为空即未安装。统计剔除 8 个 isFixture 内部占位，153 个真实 server × 17 宿主 = 2,601 格；含占位为 161 × 17 = 2,737 格，差值恰好 136 格，跨文引用须注明口径。

「真机」指采集机在本机实际安装并连接成功，一台机器、每格判一次、不含重试，连「偶尔失败」都体现不出来。宿主能力表里的约束来自官方文档与公开记录，最高只能标到规则推导。

总结

0% 往往是没有测过，48.7% 往往是灰格记错了边。无数据与部分可用各自单列、分母为 0 的列判未测、部分可用按三类成因分派动作，这三步做完，12 个文档规则列会收敛到同一条 103 的线上，剩下唯一的真实差异是 claude-desktop 那 11 格 stdio-only。

适合与不适合

适合：手里有一张兼容表要读的人；正在向同事解释某个宿主为什么是 0% 的人；自己也在跑多宿主采集、需要一套可复核口径的人；正在为「工具少了一半」找原因的人。

不适合：想直接拿一份「哪个宿主最好」排行的人 —— 这里只讲怎么读，不给结论；只用一个宿主、从没换过客户端的人；以及期望把部分可用直接当「能用」处理的人。

标签：MCP、兼容矩阵、灰格处置、宿主通过率、数据口径

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