153 个 MCP 服务，我把工具数一个个数了一遍
我最开始只想弄明白一件事：一个「正常」的 MCP 服务，大概挂多少个工具。为了这个问题，我打开了那份 2,601 格的兼容矩阵，一行一行往下翻。翻完之后，答案和我预想的差得有点远。
一句话结论
报有工具数的服务是 103 个，中位 9、p90 40、最大 628；另外 50 个报的是 0，在 241 个真机格里一次没通过。通过率最高的那一档是 21–50（43.0%），不是工具数最多的 101 以上（30.0%）。
怎么算的
| 项 | 我的做法 |
|---|---|
| 数据源 | 站点 mcp-data.json，读 servers[].toolCount 和 servers[].checks[] |
| 快照时间 | 2026-11-02T19:53:24Z，北京时间 11-03 03:53，mode=full |
| 样本 | 161 条记录，删掉 8 条 isFixture，剩 153 条 |
| 分档 | 按 toolCount 切六段，外加一段零工具 |
| 判定 | 只认 usable=pass 且 evidence=真机 的格子 |
口径边界
下面几条是我一开始搞错、后来改过来的，先写在这里。
- 中位 9 的分母是 103，不是 153。我第一遍拿 153 去除，算出来是另一个数，白忙了半小时。
toolCount是服务自己报的，不是我一格格数出来的条目。真要逐条核，得给 153 个服务各跑一遍tools/list，这次没做。- 那 50 个零工具的服务不是都坏了。整份数据里 692 格写的是「这个平台用不了它」，只有 13 格写「它没有对外提供任何工具」。
- 2,601 格里只有 756 格是真机，1,248 格是文档推断，597 格是协议实测。这三类不能混着算。
- 快照是 11-02 的，我写这篇是 11-11，中间隔了 9 天。
主体数据
| 指标 | 值 |
|---|---|
| 报数服务 | 103 |
| 零工具服务 | 50 |
| 最小 / 中位 / p90 / 最大 | 1 / 9 / 40 / 628 |
| ≥50 / ≥100 个工具 | 7 / 4 |
| 工具数区间 | 服务 | 真机格 | 通过 | 通过率 |
|---|---|---|---|---|
| 1–5 | 37 | 185 | 69 | 37.3% |
| 6–10 | 21 | 105 | 28 | 26.7% |
| 11–20 | 18 | 90 | 20 | 22.2% |
| 21–50 | 20 | 100 | 43 | 43.0% |
| 51–100 | 3 | 15 | 3 | 20.0% |
| 101 以上 | 4 | 20 | 6 | 30.0% |
| 0（零工具） | 50 | 241 | 0 | 0% |
数据说明：数完之后最意外的四件事
一、中位只有 9，我原以为会是三十几
我平时的印象里，一个 MCP 服务怎么也得有十几个工具才像样。结果一半的报数服务不超过 9 个，1–5 档就占了 37 个，是六个非零档里最大的一档。
再看分位：p90 是 40，意思是九成服务在 40 个以内。这条分布不是「大家都有几十个」，而是「大多数只有个位数，少数几个特别长」。
二、628 那个数字，我盯着看了很久
adbutler__mcp-server 报的是 628 个工具。第二名的 debugbundle__mcp 是 139，第三、第四是 116 和 108。628 是第二名的约 4.5 倍，而第二名到第四名只差 31。
同样是「一个服务」，一个报 1 个，一个报 628 个。我一开始以为数据出错了，回去看了字段才明白：协议只规定每个工具要长什么样（名字、描述、输入 schema），没规定一个服务应该放几个。贴着接口逐个映射的，条目自然多；把多步封成一个入口的，两三个也够。
三、最意外的是通过率不跟着工具数走
这是我最没预料到的一段。我原本的假设是「工具少的好通过，工具多的容易在某个宿主上翻车」，曲线应该是往下走的。
实际是 37.3% → 26.7% → 22.2% → 43.0% → 20.0% → 30.0%，先降、再升、再降、再升。最高点落在 21–50 档，比 1–5 档还高。说实话我试着找了几种解释，比如「中等规模的服务维护得更细」，但数据里没有任何一列能支撑这个说法，所以这句只是我的猜测，不能当结论。
能确定的只有最后一行：工具数为 0 的 50 个服务，241 个真机格，0 通过。
四、17 个宿主报回来的数字，一模一样
我本来以为宿主会按自己的能力裁剪工具数，比如「这个平台只认前 40 个」。于是我把每个服务在 17 个宿主上的 toolCount 摊开对比，结果 0 个服务出现差异——一个都没有。
这说明宿主根本不改这个数字。它能改的是「能不能调」，也就是 usable。整份数据里，因为工具数被判不可用的只有 3 格，note 写着「工具数超过该宿主约 40 / 约 100 个上限，需精简后可用」，对应 628 的两格和 108 的一格。
我踩过的一个坑就在这：一开始我把「17 个宿主数字一致」读成了「宿主对工具数没有限制」，这两件事不是一回事。前者说的是字段来源单一，后者要看那 3 格 note，而那 3 格恰好是反例。
这份复盘本身的局限
第一，我只核了统计过程，没核每一条自报数据。628 是不是真有 628 个可调工具，这份快照回答不了。
第二，真机格只有 756 个，分到六档后最少的一档只剩 15 格。15 格里 3 个通过就是 20%，一个格子的进出就能改写结论。
第三，我只有一天的数据，看不出谁在加工具、谁在删。趋势这件事，这次没法谈。
第四，档边界是我自己切的。换成三档，43.0% 那个峰值大概率会消失。
数据复核
想自己核一遍的话，路径很短：先按 isFixture 删 8 条，得到 153；再看 toolCount > 0 的 103 个；最后只留 evidence=真机 的格子算 usable。
三个数记住就行：153、103、756。站内 MCP 兼容矩阵页可以按 toolCount 字段逐条对照，页面上同一格的结果与本文用的是同一份快照。
适合与不适合
适合：和我一样好奇「一个服务该有多少工具」的人；要引用中位数、p90 这类分位数写材料的人；想验证「工具多是不是更容易通过」的人。
不适合：想找某个服务能不能用的人，这里只有聚合分布；需要最新数据的人，这是 9 天前的快照；想拿 628 当标杆的人，它是个例，不是水位线。
标签：MCP、DeepSeek Harness、第一人称复盘、工具数分布
本文数字由我逐格核对，数据来源于站点 MCP 兼容矩阵快照（2026-11-02）。
