跨宿主可移植：远程 11/14，本地 27/147
把 MCP 兼容矩阵里真正做实机判定的三列逐格比对，161 个 server 只有 38 个三处都过，其中 6 个还是测试样本。差距几乎全在本地进程上：14 个远程 server 三列各过 11 个，147 个 stdio 只过 27 到 98 个。
跨宿主可移植：远程 11/14，本地 27/147
挑 MCP server 时最常见的误判，是把「在我的宿主里能用」当成「到哪都能用」。这两件事的差别有多大，只要把兼容矩阵里真正做过实机判定的那几列并排比一次就能看出来。
口径：采集时间 2026-11-02 19:53 UTC，mode=full，161 个 server × 17 个宿主 = 2,737 格，2026-11-07 重算。17 列里只有 3 列有完整的真机结论（Claude Code 2.1.311、Gemini CLI 0.66.0、Qoder 1.1.80），另 2 列（CodeBuddy、OpenCode）采集机上没装 CLI，161 格全是 na，其余 12 列是按各自官方规则推导的文档结论。所以「跨宿主」这件事，目前能实证的上限就是这三列。想看全表逐格结果见兼容矩阵。
三列先摊开
| 宿主 | usable pass | 分母 | 通过率 |
|---|---|---|---|
| claude-code | 109 | 158 | 69.0% |
| gemini-cli | 40 | 158 | 25.3% |
| qoder | 39 | 158 | 24.7% |
同样是 161 个条目、同一台采集机、同一天，三列的差距是 44 个百分点。这个差距不可能由 server 解释——它只能是宿主侧的差异。
38 个三处都过，其中 6 个是测试样本
把三列逐格取交集，三个宿主全部 pass 的只有 38 个。本轮实测这 38 个里有 6 个是 fixture-* 测试样本（专门用来测工具数上限与 resources 的合成条目），真实可用的名单是 32 个。
这 32 个里有代表性的几个：context7（2 个工具，启动 3,597ms）、chrome-devtools（32 个工具）、deepwiki、exa、firecrawl、playwright-mcp。它们的共同点不是工具多，而是工具少或传输方式统一——本轮实测 32 个里有 12 个的工具数在 1~3 个之间。
68 个只在 claude-code 过，全是本地进程
| 三列结果（cc / gemini / qoder） | 个数 | 说明 |
|---|---|---|
| 过 / 过 / 过 | 38 | 含 6 个测试样本 |
| 过 / 不过 / 不过 | 68 | 全部 stdio，全部 toolCount>0 |
| 不过 / 过 / 不过 | 2 | 两侧都过，仅 qoder 不过 |
| 不过 / 不过 / 过 | 1 | 仅 qoder 过 |
| 不过 / 不过 / 不过 | 52 | 51 个零工具 + 1 个慢启动 |
68 这个数值得单独看。它们不是零工具——每一个都有工具，平均下来也不是边缘条目。它们也不是启动慢：本轮实测其中 37 个启动耗时 ≤5,000ms，最短的在 3,000ms 以内。所以「Gemini CLI 和 Qoder 只是嫌弃慢 server」这个解释，在这 68 个样本上不成立。
真正的原因更可能是这两列自身的可用性：本轮实测 Gemini CLI 与 Qoder 的整体通过率只有 25.3% 与 24.7%，而 Claude Code 是 69.0%。当一列的大盘本身只有四分之一时，任何单条 server 落在这一列 fail 都不能直接推断它坏了。这也是为什么子站把结论按证据分档——文档推导、真机实测、协议实测三档不混用，na 一律不计入通过率分母。
唯一一个「有工具但三列全不过」的是 wavespeed__mcp（16 个工具，启动 10,460ms），属于启动超时这一类，与前面 51 个零工具不是同一个问题。
远程 11/14，本地 27/147
这是本轮最干净的一条线索。按传输方式拆开，同一批样本呈现出完全不同的形状：
| 传输方式 | 样本数 | claude-code | gemini-cli | qoder | 三列全过 |
|---|---|---|---|---|---|
| http（远程） | 14 | 11 | 11 | 11 | 11 |
| stdio（本地进程） | 147 | 98 | 29 | 28 | 27 |
14 个远程 server 在三个宿主上的通过数一模一样，都是 11——不是「都还不错」，是逐格相同。11 个 pass、3 个 na（需要 OAuth 或不可达）。换句话说，对这 14 个条目来说，换宿主这件事在实际结果上等于没发生。
147 个本地进程则是另一回事：Claude Code 98 个、Gemini CLI 29 个、Qoder 28 个，三列同时通过的只有 27 个。本地进程要为每个宿主各自起一次子进程、各自处理 PATH、各自撞超时，差异都堆在这一层。
所以选型的顺序应该调整：先看传输方式，再看工具数，最后才看单个宿主的评分。远程 server 的跨宿主风险远低于本地进程，这不是推测，是 11/14 与 27/147 的对比。单条 server 的传输方式与工具数，可在单条详情页查到；采集里那些被记为「没有结论」的格子，成因归档在坑点库。
怎么用这份短名单
三步，都按上面的数字走：
第一，先把候选按传输方式分堆。远程的 14 个里三列各过 11 个，可以先当「大概率可移植」；本地的 147 个要逐个核。
第二，本地条目先看工具数。剔掉 6 个测试样本后，三列全过的真实 stdio 是 21 个，其中工具数超过 40 的只有 2 个（139 个与 45 个），其余 19 个都在 40 以内——工具数越接近宿主上限，换宿主时被截断的概率越高。
第三，剩下来的再按目标宿主查单列结论。你在 Claude Code 上挑中的本地 server，本轮实测有 68 个只在它这一列通过，换到 Gemini CLI 或 Qoder 大概率要重来。
名单短，所以结论要收窄着说
三点边界必须一起读：
一，38 个里含 6 个测试样本，真实名单 32 个，占 161 个样本的 19.9%。这不是「只有 32 个 MCP server 可用」，而是「在这三个 CLI 宿主上同时拿到实机通过的只有 32 个」。
二，另外 12 列是文档推导，不是真机。它们能说明规则差异，不能说明实际可用性。跨宿主结论目前只能落在这三列上。
三，Gemini CLI 与 Qoder 两列的大盘偏低（25.3% / 24.7%），会系统性压低交集。等这两列换版本重采后，38 这个数字大概率会变。判断名单是否变化，看采集时间与 mode，不要跨版本直接比。
数据由子站采集器在 2026-11-02 19:53 UTC 以 mode=full 采集，2026-11-07 重算；三列真机结论为采集机实际安装后逐格判定，na 不计入分母。
结论采集于 2026 年 11 月 7 日，实测方法见 数据怎么来的。