17 个宿主只有 10 种判定：MCP 排查先确认这一格测过没有

17 个宿主只有 10 种判定：MCP 排查先确认这一格测过没有

先说结论：MCP 装不上时，第一件该做的事不是改 JSON，也不是盯着表格里的红绿，而是确认「我看到的那一格，到底有没有被测过」。这个顺序颠倒过来，后面所有判断都建在空白上。

口径交代。数据取自子站采集机的全量汇总文件，generatedAt 为 2026-11-02T19:53:24Z（北京时间 11 月 3 日凌晨），mode 为 full、finalChunk 为 true，161 个 server 乘 17 个宿主共 2737 格。剔掉 8 个 isFixture 测试样本后是 153 个 server、2601 格，下面所有数字都按这个口径现场重算，不是二手汇编。想先查逐宿主的配置键名与能力边界，打开宿主能力对照；想按现象对号找原因，见坑点清单。

一、2601 格先拆成四块

任何一张兼容表，格子的总数都是固定的，先把它们拆开，才知道自己在看什么：

这张表里最容易读错的是最后一行。na 不是「不支持」，是「没测到」或者「测不出来」。它占 13.5%，意味着每七格里就有一格是没有答案的空白。

二、351 格空白里，306 格来自两个整列

把 351 格按 note 字段拆开，只有两种来源：

• 306 格 = codebuddy 与 opencode 两列的全集（各 153 格）。这两列的 hostAvailability 写的是 available: false、reason 为「未知原因」，采集机没装它们的命令行工具，所以整列一格都没测。
• 45 格 = 远程 server 网络不通。note 原文是「本机网络连不上这个服务，未取得结论」，属于采集侧的网络问题，不是 server 或宿主的问题。

这个拆分改变了一个常见判断。如果你在 codebuddy 那一列看到某个 server 是红的，或者看到整列都是灰的，那都不是「codebuddy 不支持它」—— 那是这台采集机上压根没有 codebuddy。实测这两列各 153 格全是 na，没有一格 pass 也没有一格 fail，任何基于这两列的横向比较都不成立。

三、17 个宿主，实际只有 10 种判定结果

第二个改变判断顺序的事实：把每个宿主对 161 个 server 的判定结果整体当成一串指纹来比对，17 列只归并出 10 种形态。

七个宿主判定完全相同这件事，说明「换宿主」这个动作在很多组合之间根本不产生新信息 —— 从 trae 换到 workbuddy，你换的其实是同一套判定逻辑。实测这 7 列各 110 格通过、48 格失败、3 格空白，逐格比对零差异。

真正有区分度的只有 claude-code、windsurf、lingma、claude-desktop、cursor、zed、gemini-cli、qoder 这 8 列，通过数从 109 一路降到 39。所以你手上如果是「换个宿主再试试」，先确认换的两个是不是同一族；同族之间换，结果不会变。

四、四类症状，各自落在哪一层

症状是用户看到的，层是真正要动手的地方。这四类对不上的时候，改配置基本是白改：

症状一 · 连上了，但工具是空的

153 个有效 server 里有 50 个的工具数是 0，它们的 850 格里 pass 是 0 个、fail 705 格、na 145 格。这 50 个不仅工具数为 0，resourceCount 也全是 0 —— 不是「工具少」，是完全空的。其中一个的启动耗时还高达 22675 毫秒，进程起来了却什么也没注册。

判据很简单：先看 toolCount，等于 0 就别在配置上耗时间。可以拿server-memory这类正常样本做对照，它有 9 个工具，配好就能列出来。

症状二 · 换个宿主就装不上

上面那张 10 种形态的表就是判据。同一份配置从 trae 搬到 workbuddy 一定还是通，搬到 qoder 大概率不通 —— 实测 trae 与 qoder 在 161 格上相差 71 个通过格。这不是配置写得对不对的问题，是宿主这一层本来就不一样。

症状三 · 文档说能装，真机装不上

161 个 server 里有 72 个同时满足「文档层至少有一格 pass」和「真机层至少有一格 fail」。两个证据层给出的结论在这 72 个身上互相矛盾。文档层共 1344 格、pass 1250 格；真机层共 796 格、pass 只有 188 格。真机 796 格里还有 322 格是 na，扣掉之后真正可测的 474 格里通过 188 格，通过率 39.7%。

所以看到绿勾先问一句：这一格的 evidence 是「文档」还是「真机」。两者的通过率相差 53 个百分点以上，不是同一件事。

症状四 · 一直在转圈

112 个 server 有启动耗时数据。中位数 3866 毫秒，第 90 百分位 12236 毫秒，最长 55285 毫秒（b1-mcp-server），最短 212 毫秒（dpharness-mcp）。超过 20 秒的有 6 个。

把宿主超时设到中位数的两倍（约 8 秒）能覆盖大部分情况；超过 20 秒的那 6 个建议单独隔离，不要和正常 server 放进同一份配置，否则每次启动都要陪它们等。

五、按这个顺序排查

1. 先确认测过没有：这一格是 na 就到此为止，你手上的不是结论。codebuddy 与 opencode 两列直接跳过。
2. 再看装没装：install 为 fail，问题在安装与配置格式；为 pass 就往下走。
3. 再看有没有工具：toolCount 为 0，问题在 server 自己，配置层解决不了。
4. 最后才比宿主：确认两个宿主不属于同一形态族，再谈「是不是宿主不支持」。逐宿主的约束记在宿主能力对照，那部分结论的证据等级最高只到「规则推导」。
5. 耗时单独处理：超过 5 秒的先解决稳定性，再谈功能。

前四步里，只有第二步和第四步会指向配置。这也是为什么很多人改了半天 JSON 没有任何变化 —— 他们的问题落在第一、三步。

六、三个容易踩的误判

误判一 · 把空白读成不支持

na 占 13.5%，其中 306 格来自两个整列。把这种空白读成「这个宿主不行」，会让整个选型结论偏移。

误判二 · 把 limited 当成 fail

55 格 limited 里，30 格是「server 只提供资源、宿主不支持这类能力」（zed 独有 31 格里的大头），11 格是「这个平台是否支持远程 MCP 缺少可靠资料」（全部落在 lingma），14 格是工具数超过宿主上限（cursor 上限约 40 个、windsurf 约 100 个）。三种成因，三种修法，没有一种是「换个 server」。

误判三 · 拿 17 列横向排宿主

七列同族、两列全空，真正能比的只有 8 列。横着排出来的「兼容性排行榜」，一半是同一份答案数了好几遍。

收尾

一句话记住这个顺序：先确认这一格有没有被测过，再看装没装，再看有没有工具，最后才轮到宿主和配置。字段含义在术语表，判定口径的完整推导在方法说明，按现象反查原因在坑点清单。

数据会变，顺序不变。下一次采集如果补齐了 codebuddy 与 opencode，那张形态表会少一行，但「先确认测过没有」这条判据不会变。