同一批 server，换宿主通过率只剩三分之一

同一批 server，换宿主通过率只剩三分之一

选客户端的常见做法是看谁功能多、谁界面顺手，然后默认「装得上」是共同前提。这个前提在站内数据里不成立。

同一批 161 个 server，在三个宿主上各跑一遍真机，结论差到不能用「略有出入」形容。下面全部来自 10-28 的三份单宿主全量采集，mode=full，落格方式是本机真实安装而非文档推断。

三份文件，同一批对象

| 宿主 | 采集时刻 | 实测格 | pass | fail | 未取得结论 | 通过率 |

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

| claude-code | 2026-10-28T05:38Z | 158 | 112 | 46 | 3 | 70.9% |

| gemini-cli | 2026-10-28T06:33Z | 158 | 35 | 123 | 3 | 22.2% |

| qoder | 2026-10-28T08:29Z | 158 | 36 | 122 | 3 | 22.8% |

三份文件里的 servers 是同一批 161 条，slug 逐条对得上，所以这三列可以直接横着读。每轮各 161 格，其中 3 格是 http 远程，本机网络连不上（free-agent-tools、huggingface、sentry），标 na 而不是 fail——拿不到结论就不当结论用，这三格三份文件完全一致。

最高与最低相差 3.2 倍。这不是「哪家更好用」的排序，是「同一份配置换个人接，成功率变成三分之一」的量化结果。

差距几乎全在 stdio 这一边

把 14 个 http 拆出来看，画面立刻变了：11 个 http server 在三个宿主上实测全通，剩下 3 个是那批 na。远程形态在这三家里没有分歧。

分歧全在 stdio：

| 形态 | server 数 | claude-code 通 | gemini-cli 通 | qoder 通 |

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

| stdio | 147 | 101 | 24 | 25 |

| http（可判定） | 11 | 11 | 11 | 11 |

147 个本地进程，在 claude-code 上通 101 个（68.7%），在另两家分别只有 24 与 25（16.3% 与 17.0%）。也就是说 22 个百分点的整体落差，基本由 stdio 一个形态贡献。

这条对选型有直接含义：如果你的 server 清单以远程为主，三家差别不大，按界面挑就行；如果以本地 stdio 为主（现实里 147 比 14，占九成），宿主选择本身就是一次筛选，选完才知道你有多少能装。

79 个只在 claude-code 通

按格对齐后，161 个 server 分成五组：

• 33 个三家全通（22 个 stdio + 11 个 http）
• 79 个只在 claude-code 通（74 个 stdio 全败于另两家，另有 3 个只在 qoder 通、2 个只在 gemini-cli 通）
• 46 个三家全败，且全部是 tools/list 返回空的 server
• 3 个 na，网络未取得结论

79 这个数字要小心解读。它不等于「这些 server 只能在 claude-code 上用」——真机装测的结论受采集时那台机器的运行时、路径、网络影响，hosts.json 里 qoder 的配置格式被记为「与 claude-code 完全兼容、可直接复用 .mcp.json」，而实测 147 个 stdio 里只有 25 个通。文档结论与真机结论在这里分叉，站内按真机记，档位标的是「实测」。

换句话说：79 是这一次的观测值，不是能力上限。但它足以否定一个常见假设——「配置格式兼容就等于能装」。格式兼容只管解析，装不装得上还取决于运行时。

33 个全通的，才适合写进团队基线

如果要在多人多宿主的环境里定一份「大家都该装」的清单，可用的集合只有 33 个：这 33 个在三个宿主上各有 1 格真机实测通过记录，合计 99 格全绿，换人换机重跑一次，成功率最高。

另外 79 个不是不能推，而是推之前必须指定宿主。把它们写成「推荐安装」而不写宿主，等于把 79 次踩坑平均分给团队。

五个反例：不能简单二分宽松与严格

如果结论是「claude-code 最宽松，另两家一样严」，那 5 个 server 会打破它：

• autenai__mcp、autonomous-ai__harness-mcp、brewpage-mcp：claude-code 与 qoder 通，gemini-cli 不通
• cyanheads__git-mcp-server、luw-ai__mcp：claude-code 与 gemini-cli 通，qoder 不通

也就是说 gemini-cli 与 qoder 这两家通过率几乎相同（22.2% 对 22.8%），但通过的不是同一批 server。通过率相同不等于结论相同，按通过率排序挑宿主会漏掉这件事。

真正稳的判据只有一个：把「这台 × 这个 server」跑一遍，看那一格。汇总数字只能用来判断「值不值得动手」。

46 个失败跟宿主无关

46 个在三个宿主上全败的 server，共同点是 tools/list 返回空数组。这一类的修法不在客户端一侧：要么配置里的路径与参数不对，要么这个 server 本身不提供工具。三家各 1 次真机实测，共 138 格，pass 为 0。

这条的价值在于缩小范围：当你的 server 落在这 46 个里，换宿主、改键名、点 Trust 全是无效动作。先绕开宿主单独验一次工具列表，方法见 数据是怎么来的，一次就能把它和宿主问题切开。

结论：先定宿主，再挑 server

顺序反过来做，成本高一个量级。先定宿主（或用团队已有的那家），再在被它通过的 server 里挑；而不是先挑一堆 server，再去找一个能全装的宿主——后者在 147 比 14 的现实里大概率找不到。

三家的完整能力差异在 按平台找 MCP，逐条标了证据档位；46 个零工具 server 与 5 个反例的判定细节在 装不上的原因。如果只想先确认某个 server 的形状，可以看 server-memory 详情：9 个工具、1 个资源项、启动 3 秒，正好是那种「工具能用但资源取不到」会被宿主能力卡住的样本。

最后一件事：这三份采集都是 10-28 的单日快照，宿主版本一动结论就会变。把「通过率」当趋势看，把「这一格通不通」当事实看，两者不要混用。