远程 MCP 几乎不失败，是一条宿主规则替它挡住了

远程 MCP 几乎不失败，是一条宿主规则替它挡住了

先给结论：兼容矩阵里「远程服务的失败率只有本地进程的七分之一」这个说法，数字没错，但成因被读反了。远程那边之所以几乎不失败，不是因为它更稳定，而是因为它那点失败被一条宿主侧的文档规则一次性吃掉了——剔掉那一列，远程的失败数直接归零。

口径先交代。数据取自子站采集机的全量汇总文件，generatedAt 为 2026-11-02T19:53:24Z（北京时间 11 月 3 日凌晨），mode=full、finalChunk=true，161 个 server 乘 17 个宿主共 2737 格。剔掉 8 个 isFixture 测试样本后是 153 个 server、2601 格，下面所有数字都按这个口径现场重算，不是二手汇编。采集机实际装了命令行工具的宿主只有三个（claude-code 2.1.311、gemini-cli 0.66.0、qoder 1.1.80），codebuddy 与 opencode 两列整列未测。想先看每个宿主的配置键名与能力边界，打开宿主能力对照；想按现象对号找原因，见坑点清单。

一、2601 格先按传输方式分成两堆

任何一张兼容表，先把格子按传输方式切开，才知道自己在看什么：

实测 2601 格里本地进程占 2363 格、远程只占 238 格，比例约 10 比 1。也就是说这张表本身就是一张本地进程表，远程样本量小到任何「远程更好用」的结论都撑不住。

失败率 35.8% 对 4.6%，差 7.7 倍。这个倍数是真的，但它是两个完全不同性质的失败相除得来的结果。下一步要把这两堆各自拆开。

二、845 个失败全在本地进程这一堆

把 stdio 的 139 个 server 按启动耗时再切一刀。startupMs 为 0 表示进程根本没起来：

三档格数相加正好是 2363，失败数相加正好是 845：690 加 75 加 80。实测这 690 个失败全部来自 46 个启动耗时为 0 的 server，它们在 17 个宿主列上都没有一格通过——连「受限」都没有，只有失败和未测两种记法。

这说明 stdio 的高失败率不是「本地进程不如远程」，而是「46 个进程压根没起来」。把这 46 个剔掉，剩下 93 个能起来的本地进程在 1581 格里失败 155 格，失败率 9.8%，和远程的 4.6% 是同一量级。

所以「本地容易挂」这个印象，本质是「起不来」与「起来了但宿主不认」两件事被合并计数了。前者是 server 自己的问题，后者才是宿主配置的问题，处理动作完全不同。

三、远程那 11 个失败，全落在同一列

远程的 238 格拆开是这样：通过 141、失败 11、未测 73、受限 13。

关键在失败那 11 格——它们全部落在 claude-desktop 一列，一个不落。而且这 11 格的证据等级标的是「文档」，不是真机。对应的正是「Claude Desktop 的配置只认 stdio，远程 URL 写进去不生效」这条公开记录，属于规则推导，不是本机跑出来的结论。

把这一列剔掉之后，14 个远程 server 在其余 16 列上的失败数是 0。它们在这 16 列里得到的是 141 个通过、13 个受限、其余未测。

那 13 个受限也不是失败，是两种不同的「不判断」：lingma 占 11 格，原因是「这个平台是否支持远程 MCP 缺少可靠资料」；zed 占 2 格，原因是 server 提供 resource 项而该宿主不支持 resources 原语。两种情况都不该读成「装不上」。

这里有个容易踩的读法：看到远程失败率 4.6% 就觉得远程配置不用管。真实情况是远程的配置风险几乎全部集中在一个只支持 stdio 的桌面宿主上——如果你正好用它，远程的失败率是 100%，不是 4.6%。

四、73 格未测，不是「不支持」

远程未测的 73 格由三部分构成，成因完全不同：

那 3 个整列全空的远程 server 是 free-agent-tools、huggingface、sentry，各 17 格全空：15 格记「本机网络连不上这个服务，未取得结论」，2 格记「采集机没装这个平台的命令行工具」，工具数都是 0。它们是「没拿到结论」，不是「结论是不支持」。实测这 3 个 server 共 51 格全空，没有一格是失败，把它们算进失败率会凭空多出 2 个百分点。

实测 73 格未测里有 51 格属于这 3 个连不上的 server，其余 22 格是 codebuddy 与 opencode 两列的常态缺席。判断一个 server 行不行之前，先确认这一格是失败还是空白，两者的处置动作相反——空白要补测，失败要改配置。

五、按这个顺序查，三步就够

把上面的拆解压成动作，顺序是这样：

第一步看传输方式。是 stdio，先查依赖与启动；是远程，先看你的宿主是不是只支持 stdio 的桌面端。这一步决定后面查什么。

第二步看启动耗时。为 0 就是没起来，不必再动配置——去查 npx 能不能拉到包、node 版本对不对、依赖装没装齐。

第三步才看宿主列。到这一步还没解决的，才是配置写法问题：键名、传输类型、超时窗口、工具数上限。键名与超时这类逐宿主的约束，按宿主能力对照逐项核，不要跨宿主照抄。

三步的收益是可以估的：实测 2601 格里只有 155 格（6.0%）属于「进程起来了但宿主不认」，另有 1339 格本就通过、351 格未测，合计 65% 的格子走不到第三步。

取数口径与字段定义写在取数方法，不熟悉的词先查术语表。

六、局限

三条必须说清：一是这份快照是 11 月 2 日的，之后服务器端没有新的全量采集，数字会随时间失效；二是 17 列里有 12 列是文档推断而非真机，本文所有关于宿主的因果都只能标到「规则推导」；三是远程样本只有 14 个 server，任何按远程细分统计的结论都不可靠。

拿一个具体的远程 server 对照着看会更直观，比如 Context7 的兼容页，它在这批数据里 17 格里 13 通过、1 受限、1 失败、2 未测，失败的那一格正是上面说的那个桌面宿主。