「有限」不是一种状态，是四种

「有限」不是一种状态，是四种

一份兼容性统计里，最难处理的不是失败，是「不确定」。

站内 2026-10-29 那次采集（2026-10-29T09:48:50Z，mode=full，161 个 server × 17 个宿主 = 2737 格）有四种取值：通过 1583、失败 1032、有限 71、无法判定 51。后两者合计 122 格，占 4.5%。

这 122 格如果算进失败，通过率会被压低；算进通过，结论会被夸大。所以它们只能单列。但「单列」不等于「同类」——把 71 格按宿主拆开，会发现它们根本不是一件事。

四套机制，两种数字

| 宿主 | 格数 | 实际机制 | 判据 | 证据档位 |

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

| Zed | 38 | 不支持 resources 原语 | server 的 resources > 0 | 官方文档（Supported Features 只列 Tools 与 Prompts） |

| Cursor | 16 | 工具数超约 40 上限 | server 的 toolCount > 40 | 第三方记录，未回官方文档交叉验证 |

| Windsurf | 6 | 工具数超约 100 上限 | server 的 toolCount > 100 | 第三方记录 |

| 通义灵码 | 11 | 远程支持性查不到 | transport 为 http 且无可靠资料 | 官方三处文档结论互相冲突 |

前两列是「宿主能力缺失」，第三列是「宿主容量上限」，第四列根本不是能力问题——是资料问题。四种混在一个 limited 标签下，读表的人会得出同一个结论「这家支持得不完整」，而实际要做的动作分别是：换宿主、精简工具集、精简工具集、自己去验一次。

一 · Zed 的 38 格，与 38 个有资源项的 server 完全相等

这批数字可以对账，而且对得很干净。

161 个 server 里 resources 大于 0 的有 38 个。Zed 上标「有限」的也是 38 个。把两个集合取差集，结果是空集——一个不多，一个不少。

这不是巧合，是规则推导的必然结果：Zed 官方文档的 Supported Features 只列了 Tools 与 Prompts，没有 Resources。所以凡是提供资源项的 server，在 Zed 上都会掉进同一格。触发条件与出处见 装不上的原因 的 B 组。

后果很具体：工具本身可用，但资源类内容完全取不到，且界面没有提示。如果你依赖 resources 传递上下文，症状会表现为「模型装不知道」——它确实不知道，因为那条通道不存在。

二 · Cursor 的 16 格，等于工具数超 40 的 16 个

同一套对账方法用在 Cursor 上，结果一样精确。

工具数超过 40 的 server 有 16 个，Cursor 的「有限」格也是 16 个，集合相等。名单里最极端的是 adbutler__mcp-server，628 个工具；接着是 aiquila-mcp 316 个、softeria__ms-365-mcp-server 202 个、portkey-admin-mcp 150 个。

Windsurf 同理，门槛抬到约 100：工具数超过 100 的有 6 个，它的「有限」格也是 6 个。628、316、202、150、114、108 —— 这六个数字同时出现在两张名单里。

这里有一个必须写清楚的口径问题：这两档的证据是第三方记录，不是官方文档。Cursor 的 40 与 Windsurf 的 100 都来自外部实测文章，站内没有找到厂商原文，所以结论最高只能标到「规则推导」。因此表格里的措辞是「约 40」「约 100」，不是「40」。

对账能对上，不代表阈值是厂商承诺的。它只说明站内的规则集内部自洽——这一点在读任何兼容性表时都要分清。

三 · 通义灵码的 11 格，是查不到不是不支持

这一类最容易被误读，因为它长得和前两类一模一样。

通义灵码的 11 个「有限」格全部落在远程（http）server 上。161 个 server 里 http 形态有 14 个，其中 3 个因为本机网络连不上没取得结论（记为「无法判定」），剩下 11 个就是这 11 格。

原因写在宿主的资料里：阿里云 Flink 文档把通义灵码归为「仅支持 STDIO，需桥接」，而高德 MCP 用例与第三方文档都写「类型选择 SSE 或 Streamable HTTP」。三处结论互相冲突，没有版本对应说明，站内于是保持「未知」而不做判断。

这是四种里唯一一种不该动手改的：换宿主没必要，精简工具集更没关系，正确动作是自己拿一个 http server 试一次。把「查不到」当成「不支持」，代价是白换一套工具链。

还有 51 格是「无法判定」，别和「有限」混为一谈

「有限」与「无法判定」在表里只差一个词，机制差得最远。

51 格来自 3 个 server × 17 个宿主，三个 server 是 free-agent-tools、huggingface、sentry。这三格记录的原因逐条一致：本机网络连不上这个服务，未取得结论。档位是协议实测，不是文档推导。

也就是说，这 51 格问的是「我们没测成」，不是「它不能用」。混进失败会让通过率凭空掉一截，混进通过则是编造结论。

顺带说一个结构事实：本次实测里，真机实测的 790 格中一格「有限」都没有，71 格全部来自文档推导档。原因是真机只覆盖了 5 个宿主，而这 5 个宿主恰好没有上面四类约束。这不代表真机更可靠、文档更差——两档回答的是不同问题：真机说「这台机器上跑通了没有」，文档说「按厂商写的规则，理论上能不能」。

为什么值得为 122 格单独记账

因为它们决定你读任何一张兼容性表时该信到什么程度。

口径差多少，可以算。把 122 格算进分母、当成失败，整体通过率是 1583/2737 = 57.8%；只算能判定的 2615 格，是 1583/2615 = 60.5%。差 2.7 个百分点，单看不大——但统计口径一旦换成「按宿主」而不是「按格数」，这 122 格会整体压低 12 个非真机宿主的排位，因为它们的 161 格由文档 116 格加协议实测 45 格组成，没有一格是真机。

一个具体的读表例子：signal8ai__mcp 有 108 个工具、112 个资源项，它同时出现在 Zed、Cursor、Windsurf 三张名单上——三处「有限」，三套不同的原因，修法只有两套。而 server-memory 有 9 个工具、1 个资源项，只在 Zed 那一张名单里，server-memory 详情 页的工具数可以直接核对。两个 server 摆在一起看，就能明白为什么「有限」这个标签单独用没有信息量。

想看完整的四列取值如何按宿主分布，按平台找 MCP 逐格给了证据档位；想自己复算一遍判定逻辑，数据是怎么来的 写了每个格子是怎么算出来的；这四类约束的触发条件与出处集中在 装不上的原因 的 A、B、C 三组。

最后提醒一句：本文对账的是 10-29 那一轮，finalChunk=true 说明那轮采集是完整的，但完整的只是那一轮。厂商改了规则、宿主发了新版，38、16、6、11 这四个数都会变，唯一不变的是「有限」这个词本身没有信息量——它必须被拆到机制那一层才有用。