17 个宿主列里 12 列没有一格真机实测

17 个宿主列里 12 列没有一格真机实测

MCP 兼容矩阵最容易犯的读法是横向扫一行，看哪个宿主绿灯多。这种读法默认 17 列是同一种东西，各列之间的差别只是「通过得多还是少」。

按 2026-11-02 的全量快照逐列拆开，这个默认不成立。161 个 server × 17 个宿主 = 2,737 格，但这 2,737 格不是均匀铺开的：有 12 列从头到尾没有一格是真机跑出来的，它们的绿灯全部来自文档推断。也就是说，同样一个绿色方块，在 claude-code 那一列表示「本机装过、连上了」，在 trae 那一列只表示「README 里写的配置格式匹配」。两者的可信度差着一个量级。

逐格的证据构成可以对照 MCP 兼容矩阵，每个宿主的能力边界另有一份规则表在 宿主能力表；条目本身在名录里的分布，可以先在 站内条目清单 过一遍再动手。

17 列的构成其实只有三种

把每列的格子按证据来源统计，17 列落成三组，组内成分一字不差。

483 加 322 加 1,932 正好 2,737，没有余数。这个分解说明一件事：想判断「某个宿主到底行不行」，只有 5 列能回答，而且其中 2 列连一格有效数据都没有；另外 12 列回答的是另一个问题。

全空的原因写在格子备注里——「本次没测到：采集机没装这个平台的命令行工具」。codebuddy 和 opencode 各自 161 格全是这句，一列到底。所以这两列在任何口径下都不该参与排名：它们不是 0 分，是没参加考试。把它们算进平均分会直接把整体拉低 11.8 个百分点。

12 个文档列只有 5 种写法

再看那 12 列。它们的 fail 全部是同一个数字 48，差异只在 pass 与 limited 之间如何分配。

12 列里 7 列数值完全相同，都是 110 过、48 不过、3 未测。这不是巧合，是这三组数字本来就不由宿主决定：48 个 fail 的条目在 12 列里是同一批 server，属于「服务本身起不来」这一类，换哪个宿主都一样。

唯一形态不同的是 claude-desktop：它的 fail 是 59 而不是 48，多出的 11 格是远程条目按「只支持本地进程」的规则被判不支持。这也是它 pass 只有 99 的原因——110 减 11 就是 99。这条属于规则推导，不是真机结论，引用时要标清楚。

一列的通过率上限是写死的

12 个文档列每列都是 161 格，其中 49 格是协议探测、3 格是未测，剩下 109 格才轮到文档推断。而协议探测那 46 格 fail 是结构性的——那 46 个服务启动耗时为零，探测在握手前就停了，任何宿主都过不了。

于是每列的理论上限是 112 格能过，实际最高 110 格，68.3%。这个数跟宿主做得好不好没关系，它衡量的只是「这批条目里有多少个的文档写得能照着做」。

实测 12 个文档列的 pass 合计 1,250 格，文档层总格数 1,344 格，93.0%。这个 93.0% 经常被读成「生态成熟」，但它的分母剔掉了 552 格协议 fail 和 36 格未测，只留下文档写清楚的那部分。真机侧另算：实测 474 格真机判定里通过 188 格，39.7%。93.0% 与 39.7% 之间那 53 个百分点，就是「文档写了」和「这台机器上真能跑」的落差。

真机三列的内部差距比组间差距更大

三列真机列各有 158 格实测判定，通过数分别是 claude-code 109 格、gemini-cli 40 格、qoder 39 格。同一批 161 个 server，同一台采集机，claude-code 67.7%，另两列都在 25% 上下。

拆到传输方式上看，14 个远程条目在三列里都过了 11 个，逐格相同；147 个本地进程条目在 claude-code 过 98 个，在 gemini-cli 和 qoder 各过 28 到 29 个。差距全部落在本地进程这一侧，不是协议理解不同，是进程能不能拉起来。

这条差异为什么值得单独说：它意味着「我在 claude-code 上试过能用」这句话，对 gemini-cli 用户的参考价值只有三成。跨宿主搬运结论时，本地进程类条目必须重新验一遍。

拿到矩阵之后的三步用法

第一步，先确认你要用的宿主落在哪一组。三列真机可以直接采信，十二列文档只能当候选，两列全空必须自己测。

第二步，看 fail 的性质。48 个 fail 是条目自身的问题（起不来），换宿主无效；claude-desktop 那多出来的 11 格是宿主限制，换条目有效。两者的处置方向相反。

第三步，别用列平均分做选型。三列真机的平均分是 39.7%，十二列文档的平均分是 68.3%，这个差距里有 46 格结构性 fail 和 322 格未测在起作用，不是宿主质量。真要横向比，只在真机列的 158 格里比，且只比同一批条目。

具体的失败类型与排查顺序在 坑点清单 里按现象分了组；如果你更关心「我这条命令为什么跑不起来」，那属于真机层的问题，从 排查方法 入手更快。像 context7 这类文档齐全的条目，通常能直接落到真机层排错，不必纠缠文档有没有写。

数据口径

本文件所有数字取自 2026-11-02T19:53:24Z 生成的全量快照，mode=full、finalChunk=true，161 个 server × 17 个宿主 = 2,737 格，采集机 node v22.23.2，三列真机对应的命令行版本为 claude-code 2.1.311、gemini-cli 0.66.0、qoder 1.1.80；codebuddy 与 opencode 两列的版本号为空，即未安装。

需要强调两件事。其一，这里的「真机」指采集机在本机实际安装并连接成功，只有一台机器、每格判一次，不含重试，连「偶尔失败」都体现不出来。其二，宿主能力表 里的约束来自官方文档与公开实测记录，属规则推导，最高只能标到「规则推导」——本文里凡涉及「某宿主不支持某传输方式」的判定，全部属于这一档，不要当成真机结论引用。

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