装上了不能用：127 格落差的两种成因

装上了不能用：127 格落差的两种成因

很多人把 MCP 的兼容性看成一个开关：装上就是能用，装不上就是不能用。站内这张兼容性表恰恰证明开关这个比喻是错的——它有 127 格落在「装上了、但调不动」这个中间态里。

本文的口径先说清楚：数据取自子站一次 mode=full 的采集快照，生成时间 2026-10-29T09:48:50Z，样本是 161 个 MCP server × 17 个宿主，共 2737 格。本文所有数字都是 2026-10-31 在原始 JSON 上现场重算的，不引用任何二手汇编或产品文档里的结论。想要看逐宿主的能力对照，可以打开宿主能力对照页；想知道每类现象背后对应的坑，见坑点清单。

两个字段问的不是一件事

这张表每格有两个判定字段。install 回答「装得上吗」，usable 回答「装了能调吗」。

| 状态 | install 侧 | usable 侧 | 怎么读 |

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

| pass | 1710（62.48%） | 1583（57.84%） | 拿到了结论，结论是通过 |

| fail | 965（35.26%） | 1032（37.71%） | 拿到了结论，结论是没过 |

| limited | 11（0.40%） | 71（2.59%） | 只能用一部分，属有条件可用 |

| na | 51（1.86%） | 51（1.86%） | 没拿到结论，不是失败 |

两个字段的分母都是 2737，但它们的 pass 数差了 127。这 127 格就是本文的全部对象：install=pass，而 usable≠pass。

关键在判据不同。install 看的是「进程起没起、配置有没有被读进去、握手有没有完成」这类步骤级结果；usable 看的是「工具枚举拿到了多少、调用返回能不能被宿主接受」。前者通过而后者不通过，是完全可能的——中间少了一次「真的有东西可调」的检查。

127 格拆开，只有两块

把 127 格按两个方向切：一是这个 server 自己有没有工具，二是这个宿主的哪条边界被踩到了。

| 成因 | 格数 | 特征 | 你该先看哪个字段 |

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

| server 侧没工具 | 67 | usable=fail，全部落在 toolCount=0 的 server 上 | toolCount |

| 宿主侧能力边界 | 60 | usable=limited，落在 zed 38 / cursor 16 / windsurf 6 | 宿主的 resources 与 toolCap |

这两块加起来正好 127，没有第三块，也没有重叠。下面是各自的账。

67 格：49 个工具数为 0 的 server

先看 server 侧。161 个 server 里有 49 个的 toolCount 字段是 0，这 49 个一共占 833 格。

| 字段 | pass | fail | limited | na |

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

| install | 67 | 714 | 1 | 51 |

| usable | 0 | 781 | 1 | 51 |

usable 侧的 pass 实测是 0 格——833 格里没有一格能调通。install 侧却有 67 格 pass，这 67 格与上文 67 格完全重合。也就是说，「装上了但调用失败」这一档，成因只有一个：这个 server 本来就没有工具给你调。

采集端自己也留了原文。833 格里有 62 格的说明写着「它没有对外提供任何工具，装上也没东西可调」，其余 719 格用的是通用失败说明。这句原文是判断依据，不是我的推断。

这里必须补一句边界，否则会读错：这 49 个里 45 个是 stdio、4 个是 http（deepwiki、huggingface、free-agent-tools、sentry，其中 sentry 标了需要授权）。名单里 ghostpaw__*、wirecat__* 这类批量接入项占了相当比例。对这一个子集，「本来就没有工具」和「工具枚举没取到」在采集口径下是不可区分的——toolCount=0 只说明字段是 0，不说明原因。凡是要拿它下结论的场景，先人工跑一次该 server 的 tools/list 再判，别直接引用这张表。

一个可对照的例子是 deepwiki 的详情页：它被归到「搜索与文档检索」，从产品定位上看是问答型端点，工具面本来就窄。这类 server 装上了用不了，不是宿主的问题，换宿主也解决不了。

60 格：三家宿主各有一条硬边界

再看宿主侧。60 格全部是 usable=limited，分布是 zed 38、cursor 16、windsurf 6，一格不多一格不少。

这三家的共同点是：边界写在配置里，不是随机故障。

| 宿主 | 格数 | 与采集数据的对应 | 依据强度 |

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

| zed | 38 | 恰好等于 resourceCount>0 的 38 个 server | 官方文档（resources 为不支持） |

| cursor | 16 | 恰好等于 toolCount>40 的 16 个，最小值 41 | 第三方实测记录（约 40 个软上限） |

| windsurf | 6 | 恰好等于 toolCount>100 的 6 个，范围 108 到 628 | 第三方实测记录（100 个上限） |

三个「恰好相等」不是巧合。zed 的 38 格实测与「有资源项的 server 数」完全相等，而宿主能力表里 zed 的 resources 字段写的是不支持——所以它给不出资源类内容，只能给工具，usable 就只能记成 limited。cursor 的 16 格实测全部来自工具数超过 40 的 server，最小值 41，刚刚越过那条线。windsurf 的 6 格实测覆盖工具数 108 到 628 的 6 个 server，同样是越线即限。

采集端对这三家给的说明也各不相同，能直接对号：zed 那 38 格的原文是「它提供资源项，但这个平台不支持这类能力」，cursor 那 16 格的原文是「工具数 N 超过该宿主约 40 个上限，需精简后可用」。

还有一处必须分清。usable=limited 全表 71 格，比这 60 格多 11 格，那 11 格属于通义灵码，而且它的 install 也是 limited——所以它不进 127 格。更关键的是它的原文：「这个平台是否支持远程 MCP 缺少可靠资料，不做判断」。这是不知道，不是有限。同一个词在两个字段里语义不同，这是读这张表最容易翻车的地方；相关口径可参考术语表。

顺序反着走：先确认 usable

如果只能记住一条操作结论，那就是排查顺序应该反过来：先确认 usable，再回头看 install。

理由是一条可核验的恒等式：非零工具的 server 里，install=pass 而 usable=fail 的格子实测是 0 个。也就是说，只要 server 自己有工具、宿主也没踩边界，install 一旦通过，usable 基本不会掉到 fail。反过来则不成立——install 通过而 usable 只是 limited 的，有 60 格。

所以正确的动手顺序是：

1. 先在宿主里看一眼工具面板有没有东西。空的，直接跳到第 3 步，不要重装。
2. 有工具但一部分变灰或缺失，对照上文三条边界：是资源项问题就换承载方式，是工具数超限就做减法。
3. 空的且这个 server 的 toolCount 就是 0，那不是配置问题，是它没东西可调，换 server。
4. 只有前三步都排除了，才回头查 install 侧——形态、键名、生效条件，方法见判定方法。

这张表能信到什么程度

最后交代证据强度，因为 127 这个数字很容易被当成「客观事实」引用。2737 格里按证据来源分三档：真机实测 790 格、按官方文档判定 1392 格、协议层实测 555 格。三档的 install 通过率分别是 43.0%、98.4%、0%——同一张表里的两个通过率差 55 个百分点，因为它们不是同一种证据。协议实测那 555 格全部是 fail 或 na，本来就不该拿来算通过率。

所以引用 127 格时，正确写法是带上采集时间与 mode，并注明它是「判定结果」而不是「人工复现结果」。这也是本站坚持在每篇数据稿里标快照时间的原因。

一句话收口

「装上了不能用」不是一种故障，是两种：一种是这个 server 没有工具，一种是这个宿主吃不消它的形状。前者换 server，后者换宿主或做减法，两者的动作没有一处重叠。