MCP 兼容矩阵里的通过率不能横着读

MCP 兼容矩阵里的通过率不能横着读

68.7% 和 68.0% 挨在一起，看上去是同一件事的两种说法。实际不是。

前者是 trae 这一列的可判定通过率，150 格里通过 103 格；后者是 claude-code 这一列，150 格里通过 102 格。数字几乎一样，含义差一整层：trae 那 150 格里，真机跑过的格数是 0；claude-code 那 150 格，每一格都是在本机装完、连上、拿到工具返回才记的。

按 2026-11-02T19:53:24Z 生成的全量快照重算：161 个 server 铺到 17 个宿主上共 2,737 格，剔掉 8 个内部占位后是 153 个真实 server、2,601 格 —— 1,339 通过、856 失败、55 部分可用、351 无数据。这个总表本身没问题，问题出在把它当二维表格横着读。

68.7% 是一道加法题，不是一次测试

很多人以为一行就是一个宿主的一次完整测试，所以横着扫一行就能排出宿主优劣。拆开看，一行其实是三段拼的：

分子 103 全部来自第一段，分母 150 却把第二段那 46 格失败也算了进去。也就是说 68.7% 不是一个测量结果，而是一个加权平均：99.0% 的文档层，掺进 30.7% 的协议层。

那 46 格为什么全失败，与宿主无关 —— 逐格核对过，46 个都是零启动的 server（startupMs=0），共 46 个条目，在 12 个文档层宿主里是同一批、逐格相同。它们在任何宿主上都起不来，等于给每个宿主平均扣掉 46 格。

每一层自己的通过率

把 2,601 格按 evidence 字段拆成三层，各层自己算，结果如下：

真机层实测 169 格通过、281 格失败、306 格无数据，可判 450 格，通过率 37.6%。文档层实测 1,170 格通过、55 格部分可用、23 格失败，可判 1,248 格，通过率 93.8%。两层相差 56.2 个百分点，这个差距不是宿主质量的差距，是量的东西不一样：文档核的是「配置格式对不对」，真机核的是「进程起没起来、工具返不返回」。

协议实测层 597 格里实测 552 格可判、全部失败，剩下 45 格无数据。这一层只覆盖零启动条目，所以它恒为 0，没有任何区分能力，不能拿来评价宿主。

三列真机彼此也不在一条线上

真正跑满整列的是三列，数字反而最不整齐：

三列实测合计 450 格可判、169 格通过，整体 37.6%；但列内极差 46 个百分点，从 68.0% 到 22.0%。这才是「宿主实现完成度」这个变量唯一被单独量到的地方 —— 同一批 150 个条目、同一台采集机、同一套判据，只剩宿主不同。

坑一 · 拿加权平均去比单一层

现象：看到某宿主 68.7%、另一宿主 22.0%，判定前者兼容性好三倍。原因：前者是文档层与协议层的混合值，后者是纯真机值，分子分母的含义都不同。解决：比之前先确认两列的可判定格由哪些层构成，层不同就不比；要横比只在真机三列之间比。

坑二 · 把 46 格协议失败记在宿主账上

现象：某宿主失败格数恒为 47，看着像这个宿主能力差。原因：47 = 46 格零启动条目 + 1 格文档层失败，前者换任何宿主都是失败。解决：把零启动条目整批剔除后再算宿主差异，剩下的 1 格才与宿主有关。

坑三 · 只数通过数，不看可判格

现象：两个宿主通过数差不多，就认为水平相当。原因：codebuddy 与 opencode 两列各 153 格全是无数据，通过数 0、失败数也是 0，它们不是「差」，是没有被测量。解决：先看可判格是否为 0，为 0 的整列删掉，不要参与排序。

坑四 · 把文档层的 99% 当成「装得上」

现象：按文档层绿灯选型，上线当天就卡住。原因：文档层 1,248 格里 1,170 格通过，但它只核配置格式与字段名，不启动进程。解决：把「格式匹配」和「跑得起来」分两栏看，只有后者能作为选型依据；需要授权的条目连真机格都没有，更不能用文档绿灯替代。

三步判定顺序

第一步，看这一列有没有可判格。可判 0 格的两列（codebuddy、opencode）直接整行删掉，它们不进比较，也不代表不支持。

第二步，看可判格由哪几层拼成。17 列里只有 3 列是真机铺满，1 列（claude-desktop）在文档层明显偏离（92 通过、12 失败，该层 88.5%），4 列带部分可用，其余 7 列逐格相同、都是同一份文档口径。

第三步，同层内再比。真机列与真机列比，文档列与文档列比，跨层只做「格式是否匹配」这一件事的判断。

失败现象的分类与对应动作在 坑点清单 里按五组整理好了；如果你已经确定卡在真机层，从 排查方法 入手比继续读文档快。宿主自身的能力边界（传输方式、工具数上限、是否支持远程）在 宿主能力表，那部分属规则推导，不是实测结论，引用时要分开标注。想直接看单个条目的逐格记录，从 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 格，跨文引用时须注明是否剔 fixture。

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

术语与字段定义在 名词表 有逐条说明。

总结

68.7% 与 22.0% 之间差的不是宿主好坏，是每列被量了几层：文档层 93.8%、真机层 37.6%、协议层恒 0%，混在一起算出来的数字不具备横向可比性。先确认可判格、再确认证据层、最后才在同层内比，这个顺序能省掉大部分无效排查。

适合与不适合

适合：要给团队选统一宿主的人；手里有一批服务想知道哪些能跨端复用的人；正在核对「文档说支持、实际跑不起来」的人；需要引用兼容数据写方案、得说清口径的人。

不适合：只用一个宿主、从没换过客户端的人 —— 你不需要矩阵，直接测那一条就够；想在这里找到一份万能配置模板的人，这东西不存在；不愿区分证据层、只想看一个总分挑第一的人。

标签：MCP、兼容矩阵、通过率、证据分层、排错顺序

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