十七格全绿的兼容性表，证明不了你能装

十七格全绿的兼容性表，证明不了你能装

有人贴过一张 MCP 兼容性表：十七个宿主，横竖全绿。他照着挑了三个客户端，配完一个都连不上，于是怀疑表是刷的。

表没刷。它只是回答了一个比你以为的小得多的问题。

这张表到底测了什么

我把采集文件拉下来重算了一遍（/opt/mcp-collect/data/mcp-data.json，采集时间 2026-10-25T14:16:09Z，mode=partial，collectorVersion=dev）。里面的 servers 数组只有一个元素：server-time，官方那个时间服务器，transport=stdio，用 uvx mcp-server-time 拉起来，toolCount=2、resourceCount=0、authRequired=false。checks 一共 17 格，install 与 usable 全部 pass。

也就是说，那张全绿的表，十七格测的是同一件事：一个本地 Python 小程序装不装得上。

它能证明的范围到此为止。远程端点、带鉴权的服务、挂着几十个工具的聚合 server，一格都没测。

三种证据被压成了同一个绿

绿是同一个颜色，底下的证据不是一回事。17 格里标注为实测的只有 5 格，另外 12 格的备注统一是「配置格式匹配，装上即可用」——格式对得上，没有人真装过。

| 证据档 | 格数 | 备注里写什么 | 能推出什么 |

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

| 真机 | 5 | 已在本机实际安装，连接成功 | 这个宿主加这个 server 跑通过 |

| 文档 | 12 | 配置格式匹配，装上即可用 | 字段名对得上，没被真装过 |

5 格真机分别落在 codebuddy、qoder、claude-code、gemini-cli、opencode 上。你如果用的是 Cursor、Windsurf、Zed、Trae、Continue，那你看的那一格，从头到尾没有被人跑过。

这不是数据造假，是口径问题：12 格的 pass 意思是「按文档这个配置应该能装上」，不是「装上了」。

那 12 格为什么只能是文档

因为剩下这批宿主大多没有可被脚本驱动的安装面。采集侧能真跑的，是那几个带 CLI 的：codebuddy、qoder、claude-code、gemini-cli、opencode 都有命令行入口，装、连、列工具可以全自动完成。而 Cursor、Windsurf、Zed、Trae、Continue 这类以图形界面为主的宿主，配置写进去之后要靠人去点一次、看一眼，脚本拿不到那个「看一眼」的结果。

于是采集侧只能退一步：比对配置字段的形状，形状对就记 pass。这个退让是合理的——它至少能抓住字段名写错那一类——但它产出的绿，和你真装一次得到的绿，不是同一种绿。

这也解释了为什么坑点库里 A 组（配置写法）有 6 条、E 组（生效条件）有 4 条：这两组恰好是「文档能推、真机难跑」的地带。越是没有真机覆盖的地方，坑越多。

第一条外推错误：把单样本当成品类结论

一个 2 工具、0 资源、不鉴权的 stdio server，是 MCP 里最简单的一类。它恰好绕开了三个最容易出事的地方：

• 传输：stdio 是本地进程，不经过网络。远程 server 要处理 URL 键名、鉴权、首字节超时，它一样都不碰。
• 工具数量：2 个工具离任何宿主的上限都很远。hosts.json 里 Cursor 的软上限记 40、Windsurf 记 100，这两个数字在 2 面前没有意义。
• 原语：0 个资源项，所以「Zed 不支持 resources」这件事在这格里完全看不出来。

所以「全绿」这两个字，在你准备装一个 30 工具、走 HTTPS、需要 OAuth 的 server 时，几乎没有信息量。

判定顺序：四步，从便宜到贵

与其重读那张表，不如按这四步走。

① 先确认你的宿主在不在那 5 格里。 不在，就把自己当成「文档档」，心理预期降一档，别把 pass 当承诺。

② 查宿主能力三项：remoteNative、resources、toolCap。17 个宿主里只有 claude-desktop 的 remoteNative 是 false（只认 stdio，配 url 不生效也不报错），只有 zed 的 resources 是 false。这两条是官方文档写死的，证据等级最高也只能标到「规则推导」——它们是文档结论，不是真机复现。完整表在 平台能力对照。

③ 核配置字段。 坑点库 A 组（配置写法）有 6 条，全是照抄别家配置抄错的：Windsurf 的远程键是 serverUrl 不是 url；Roo Code 用 url 必须配 type，缺了直接保存失败；WorkBuddy 的 type 写 streamablehttp，中间没有连字符；OpenCode 顶层键是 mcp 且 command 是数组；Zed 用 context_servers；Gemini CLI 的 httpUrl 与 url 语义不同（前者 Streamable HTTP，后者旧 SSE）。这 6 条里绝大多数不报错，只是静默失效。

④ 核生效条件。 E 组 4 条，配置写对了但没被加载：Trae 的项目级开关默认关；WorkBuddy 新条目要手动 Trust；Claude Code 项目级 server 要批准；Gemini CLI 要先 trust 工作区。

四步的成本是递增的，所以顺序不能倒。多数人是第一步就跳过，直接在第四步反复改配置——那是最贵的一段。

一个自带矛盾的格子

server-time 的 startupMs 记的是 7889。OpenCode 官方文档写它的工具拉取超时默认 5000ms。按这条算，OpenCode 那格应该超时。

但采集里 opencode 那格是真机 pass，toolCount=2。

两个数字放一起只能得出一个推断：7889ms 是首次冷启动（uvx 要下依赖），缓存预热后落在 5 秒内。这一条是规则推导，不是记录里的字段——采集文件没有「第几次启动」这一列，要定论只能自己跑两遍。

这条矛盾本身比结论有用：同一份数据里，一条实测、一条文档，7889 与 5000 这两个数字打架的时候，不要挑好看的那条。

全绿的表该怎么用

把它当下限，不当承诺。它说「这个 server 在这家装上过」，不等于「你的 server 在这家能装上」。

坑点库 17 条记录里，实测 3 条、官方文档 11 条、第三方记录 3 条，实测只占 17.6%。这 3 条实测覆盖的面却很不一样：一条是合成样本 fixture-zero-tools，0 个工具，17 个宿主实测全部判不可用——一次就把「工具列表为空」这个症状和宿主彻底解耦了；另外两条分别落在无凭据的远程 OAuth 和未受信任的工作区上，都只覆盖个别宿主。这个分布决定了一条使用纪律：表越绿，越要自己验一格。

最小的验证动作在 数据是怎么来的 里——绕开所有客户端，直接用命令行连一次，确认工具数量和名字。17 条坑点的完整分组和证据出处见 装不上的原因。如果你想知道那张表里唯一的被测对象长什么样，server-time 详情 就是答案：2 个工具、0 个资源、启动近 8 秒。

验证完再回头看那张表，你会发现自己需要的其实不是「哪家全绿」，而是「哪家在我要装的这类 server 上被真跑过」。后者目前只有 5 行。