45 个 server 从未启动，留下 765 格空白

45 个 server 从未启动，留下 765 格空白

兼容表上有四分之一的格子，到现在还没有结论。它们不是灰色地带，是压根没测到东西。

口径照例交代：子站一次 mode=full 的采集快照，生成时间 2026-10-29T09:48:50Z，161 个 MCP server × 17 个宿主 = 2737 格。下面每个数字都是 2026-11-01 在现场重算的。按现象对号找坑可以看坑点清单，判定顺序的完整版在判定方法。

765 格从哪来

全表 2737 格，有 765 格落在「没有拿到任何有效结论」这一类，占 27.9%。

这 765 格不是随机分布的。它们全部来自 45 个 server，每个 server 贡献 17 格，17 × 45 = 765，整齐得不像巧合。而这 45 个的共同点是：startupMs 字段是 0。

| startupMs | toolCount | server 数 | 对应格数 |

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

| 0 | 0 | 45 | 765 |

| 大于 0 | 0 | 4 | 68 |

| 大于 0 | 大于 0 | 112 | 1904 |

三行加起来 161 个 server、2737 格，没有第四种组合。这条恒等式本身就是最有用的判据：只要 startupMs 是 0，toolCount 必然是 0，resourceCount 也必然是 0——45 个 server 里，三个字段同时为零的是 45 个，一个例外都没有。

三个零同时出现，说明它不是慢

startupMs 这个名字容易误导。看到 0，第一反应是「启动很快」。但同一个 server 的另外两个字段也全是 0，说明进程根本没被拉起来，startupMs 记 0 是「没取到耗时」，不是「耗时为零」。

实测那 116 个起来了的 server，就能看出量级：startupMs 最小 210 毫秒，中位数 3888.5 毫秒，最大 59028 毫秒；超过 5000 毫秒的有 34 个，超过 10000 毫秒的有 15 个。真实的启动耗时从来不会落在 0 上。

所以这三个字段要一起读：

| 字段 | 为 0 时的含义 | 不要读成 |

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

| startupMs | 没起来，没取到耗时 | 启动极快 |

| toolCount | 没有工具可枚举 | 工具枚举失败 |

| resourceCount | 没有资源项 | 资源读取失败 |

上表第二行要补一句边界：toolCount 为 0 有两种成因，45 个是没起来，另外 4 个是起来了但确实不提供工具。这两批混在一起看会得出错误结论，因为处置动作完全相反——前者换 server，后者确认它是不是问答型端点。

45 拆成 42 加 3

这 45 个按传输方式切开，是 42 个 stdio 加 3 个远程。

42 个 stdio 是本地进程起不来：gdharness、polydoc-mcp、orangepro__mcp-server、zereight__mcp-gitlab 这一类都在里面。它们的 714 格由三部分组成——504 格协议实测 fail、205 格真机 fail、再加 5 格真机 pass（这 5 格自相矛盾，下一节单独说）。

3 个远程是另一回事：free-agent-tools、huggingface、sentry。这三个 startupMs 为 0 是正常的，远程 server 本来就不在本地起进程。它们真正的问题是网络，17 个宿主每个都记了 3 格 na，合计 51 格，采集端原文是「本机网络连不上这个服务，未取得结论」。

这两批必须分开写。把 45 个一律说成「起不来」，会把 3 个远程的判定错误地归到进程问题上；反过来把 45 个都说成「网络问题」，又会掩盖 42 个本地进程从没起来过这件事。

同一个空白，被记成了两种结论

接下来是这篇最该被记住的一点。

同样是没有拿到结论：42 个 stdio 那批在 12 个文档宿主上，实测全部被记成了 install=fail，共 504 格；3 个远程那批被记成了 na，共 51 格。

| 批次 | server 数 | 格数 | 实际记录 | 说明文案 |

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

| 42 个 stdio | 42 | 504 | fail | 通用失败文案 |

| 3 个远程 | 3 | 51 | na | 本机网络连不上，未取得结论 |

na 的定义是「没拿到结论，不是失败」，这一点站内术语表里写得很明确。那么问题来了：504 格 fail 里，有多少是真的「测了不通」？

从这个快照能确证的只有一层：这 504 格所属的 42 个 server，在任何真机宿主上也没有起来过（205 格真机 fail 加 5 格存疑，见下节）。它们的字段组合是 startupMs=0、toolCount=0、resourceCount=0。当一个 server 连进程都没起来，「协议实测判为失败」和「没测到」在数据上就分不开了。

我只写到这里，不再往外推。采集端没有记录这批 fail 的具体判据，任何「它们其实是被误判」的说法都超出了数据能支撑的范围。可核验的部分是那句恒等式：504 加 51 等于 555，正好是「协议实测」这一档的全部格数。

5 格自相矛盾，直接剔除

765 格里还有一处必须点出来的问题：5 格的结论和说明文案相反。

gdharness 在 claude-code、aidemd-mcp__server 在 claude-code、nexus-windows-codex 在 claude-code / gemini-cli / opencode，这 5 格的 install 是 pass，但说明写的是「这个平台用不了它，原因见上方说明」。全表范围内「判 pass 却配失败文案」的组合只有这 5 格，而且全部落在 startupMs=0 的 server 上。

这三条 server 的 startupMs 都是 0，说明进程从没起来。在这个前提下记成 pass，与同一行的其他 205 格 fail 直接冲突。处置很简单：这 5 格不作为任何结论的依据，引用 765 时按「760 格有明确结论方向、5 格自相矛盾」来写更稳。

四步体检，从字段到动作

下次遇到一个装不上的 server，按这个顺序过，每步都有明确的下一步：

1. 看 startupMs。是 0 且 transport 是 stdio，就不用往下查配置了——进程没起来，configuration 层面怎么改都不会有反应。先去它的仓库确认启动命令，本地跑一次。
2. 看 transport。是 http 的，startupMs=0 属正常，改查网络与鉴权；sentry 这类需要 OAuth 的，方向直接转到凭据，不是配置。
3. 看 toolCount。起来了但为 0 的 4 个——deepwiki、fixture-zero-tools、getmarrow__mcp、structured-world__gitlab-mcp——不是宿主不认，是它没有工具可给。deepwiki 的详情页标的是搜索与文档检索类，工具面本来就窄。
4. 最后才看宿主列。宿主能力字段在宿主能力对照页按 key 名列了，远程键名、resources 支持与否都在那里。

这四步的顺序不能反。先查宿主会让人反复重装同一个起不来的 server，这是最常见的一种空转。

一句话收口

765 格空白不是表没画满，是 45 个 server 本身没给出任何可判的东西：42 个本地进程从未启动，3 个远程连不上。看到空白先分这两类，再决定是换 server、查网络、还是干脆把这一格当作不存在——三种动作没有一处重叠。