12 个宿主全绿，95 个在真机不通

12 个宿主全绿，95 个在真机不通

先给结论：兼容表里那 12 个「按文档判定」的宿主列，实际上不量宿主。它们给出同一个答案，因为它们吃的是同一份规则。

口径先交代。数据取自子站一次 mode=full 的采集快照，生成时间 2026-10-29T09:48:50Z，样本是 161 个 MCP server × 17 个宿主，共 2737 格。下文每个数字都是 2026-11-01 在原始 JSON 上现场重算的，没有引用任何二手汇编。想先看逐宿主的能力字段，打开宿主能力对照页；想按现象对号找坑，见坑点清单。

三个通过率，三套判据

同一张表，按证据来源切开，通过率能差 55 个百分点。

| 证据档 | 格数 | 占比 | install 通过率 | usable 通过率 |

|---|---|---|---|---|

| 文档 | 1392 | 50.9% | 98.4% | 90.8% |

| 真机 | 790 | 28.9% | 43.0% | 40.4% |

| 协议实测 | 555 | 20.3% | 0% | 0% |

| 合计 | 2737 | 100% | 62.5% | 57.8% |

按 install 口径实测，真机档 790 格里只有 340 格通过，文档档 1392 格里 1370 格通过。这两个数字不能放一起求平均，它们的分母是两批不同的 server：文档档只覆盖能起来的 116 个，剩下 45 个在文档宿主上一格文档结论都没有。

「协议实测」那一档 555 格没有一条 pass，也不能读成「实测全挂」。它的构成是 504 格 fail 加 51 格 na，全部落在从没起来过的 server 上——这一批单独在另一篇里拆，这里只用一句话定性：它不是更严的测试，是没东西可测时的一种记法。

12 个文档宿主，只有 4 种形态

这是全文最关键的一张表。17 个宿主里，有 12 个（trae、lingma、claude-desktop、cursor、vscode-copilot、codex-cli、windsurf、zed、cline、roo-code、continue、workbuddy）的结论全部来自文档判定，没有任何真机格。

把这 12 列按 server 逐行排开，实测只出现 4 种形态，一种不多：

| 形态 | server 数 | 这 4 种形态是什么 |

|---|---|---|

| 12 列全 pass | 105 | 116 个能起来的 server 里的绝大多数 |

| 11 列 pass，仅 lingma limited | 11 | 全部是远程（http）server |

| 12 列全 fail | 42 | 与「stdio 且从未起来」的 42 个完全重合 |

| 12 列全 na | 3 | free-agent-tools、huggingface、sentry，本机网络不通 |

105 + 11 + 42 + 3 = 161，一格不差。

这张表说明一件事：文档档区分不了宿主，只区分 server 的死活。42 个全 fail 的那批，恰好等于 startupMs 为 0 且传输方式是 stdio 的 42 个 server——一次集合相等，不是巧合。也就是说，文档档的 fail 不是「这个宿主的规则判它不行」，而是「这个 server 根本没起来，怎么判都不行」。

唯一的真宿主差异出现在那个 11 格里。11 个 server 全是远程接入，而 lingma 的能力字段里 remoteNative 记的是 unknown——采集端写下的原文是「这个平台是否支持远程 MCP 缺少可靠资料，不做判断」。这是不知道，被记成了 limited，不是不支持。同一个词在两处的语义差别，见术语表。

全绿的 105 个，真机里剩 10 个

再往下切一刀：这 105 个全绿的 server，放到 5 个能真跑的宿主（claude-code、opencode、codebuddy、qoder、gemini-cli）上去看。

实测结论是 95 个在至少一个真机宿主上 fail。也就是说，一张 12 列全绿的表，命中率不到 10%。

剩下 10 个真机也全通的，名单更值得看：fixture-big-schema、fixture-boundary41、fixture-huge-tools、fixture-many-resources、fixture-many-tools、fixture-prompts、fixture-zero-tools 这 7 个是站内自建的测试样本，本来就是为了踩边界做的；真实 server 只有 3 个——luw-ai__mcp、playwright-mcp、textile-designer-ai__mcp。

所以「12 个宿主全绿」这句话的正确读法是：这个 server 的配置写法在文档层面没有歧义，仅此而已。它不含任何关于「能不能跑起来」的信息。

真机 5 列才看得见宿主差异

对照组放这里就清楚了。同样 161 个 server，按 5 个真机宿主的 install 结果排开，实测有 11 种形态。

| 形态（claude-code / opencode / codebuddy / qoder / gemini-cli） | server 数 |

|---|---|

| pass, pass, fail, fail, fail | 56 |

| fail, fail, fail, fail, fail | 42 |

| pass, pass, pass, pass, pass | 20 |

| pass, pass, pass, fail, fail | 13 |

| pass, pass, fail, pass, pass | 13 |

| 其余 6 种 | 17 |

最能说明问题的是第一行那 56 个 server：前两家能装，后三家全军覆没。这类落差在文档档里完全看不见——文档档对它们给的是 12 列一致的 pass。

按 usable 口径，5 个真机宿主各自通过 108、107、36、31、37 格（分母均为 158）。前两家过六成，后三家二成上下，这个差距不是随机噪声，但也不能推定成「后三家能力弱」：同一批 server 换到前两家就能装，说明卡点在安装链路而不在协议能力。快照里 codebuddy 那 122 格 fail 中有 120 格的说明是同一句模板文案（「这个平台用不了它，原因见上方说明」），采集端没有记录机器可读的原因码，所以任何关于「为什么」的断言都超出数据能支撑的范围。

三步把一格钉死

读到这儿，方法应该已经能自己走了。遇到一格绿色，按这三步过：

1. 看 evidence 字段。是文档，就把它降级成「写法无误」；是真机，才把它当「在这台机器上通过了」。
2. 看同行的真机列。这一行的 5 个真机宿主里只要有一处 fail，那一格绿就不该作为安装依据。
3. 看 server 侧 startupMs。为 0 的，文档列再绿也没有意义，处置方法在判定方法里。

引用规范只有一条：写数字时必须同时带上快照时间、mode、以及它是哪一档证据。少任何一项，98.4% 就会被读成「基本都能装」。

顺带提醒一个容易踩的地方：fixture-* 这类测试样本在文档列里全是绿的，它们本来就是为验证客户端边界而造，不该进选型短名单。表上有 8 个 isFixture 为 true 的条目，剔除之后再看比例。

一句话收口

文档档的绿是「一份规则抄 12 遍」，它回答的是写法对不对；真机档的绿是「一次真的握手」，它回答的是这台机器上能不能跑。前者 98.4%、后者 43.0%，差的不是质量，是问题本身不同。要判断一个 server 能不能用，看真机列；要判断配置写没写对，才看文档列。两条判断不能互相顶替。