MCP 装不上？先分清是本地进程还是远程服务，失败率差 7 倍

排查 MCP 连接问题时，大家习惯从「配置对不对」入手：命令写错没有、参数少没少、环境变量传没传。这些当然要看，但先看一个更基础的分层可以省掉一半时间——

你装的是本地 stdio 进程，还是远程 HTTP 服务？ 这两类的失败率差了一个数量级。

一、先看数据，判断该往哪个方向查

以下是 2026-11-02 的一次全量采集结果（153 个 server，已剔除 8 个 fixture，17 个宿主 × 每个 server 逐格判定，共 2,601 格）：

传输方式	server 数	判定格数	通过	失败	通过率	失败率
stdio（本地进程）	139	2,363	1,198	845	50.7%	35.8%
http（远程服务）	14	238	141	11	59.2%	4.6%

失败率 35.8% 对 4.6%，相差 7.7 倍。

这个结果和直觉相反。多数人认为「本地跑的东西更可控，远程服务才容易受网络影响」，但实测是反过来的。原因不难推：

• stdio 类要真的在本机拉起一个进程：npx 要先下载包、node 版本要对、依赖要装齐、进程要能在宿主的超时窗口内完成握手。任何一环慢或失败，判定就是 fail。
• http 类只是发一个 HTTP 请求，剩下的都在服务端，客户端侧的变量少得多。

所以如果你的 MCP 装不上，先看传输方式：是 stdio，先查依赖与启动；是 http，先查连通性。

进一步拆证据来源会更清楚（同一批数据）：

证据类型	判定格数	通过	失败	说明
文档推断	1,248	1,170	23	按 README 声明推断，不是真跑
真机实测	756	169	281	实际拉起进程，通过率只有 22.4%
协议实测	597	0	552	协议层校验，无一条通过

注意第三行：协议实测 597 格、通过 0 条。这一项不是「这个 server 不能用」，而是「协议层的严格校验没有一条完全满足」——它的意义是提醒你，很多 server 能用，但不完全合规范。

二、按症状对号入座

下面按最常见的四种表现分类，每类的排查方向不同。

症状一：宿主里显示连接成功，但工具列表是空的

先查 toolCount。这批数据里 50 个 server 的工具数为 0，占 153 的 32.7%。

零工具通常有两种情况：

• 服务本身只提供 resource / prompt，不提供 tool（这是合法的，但你要的功能不在那儿）
• 启动失败了，宿主连上了空壳

怎么区分：看启动耗时。正常 server 的 startupMs 有值，零工具且 startupMs 为 0 的，基本是没起来。

工具数分布可以作为参照：

工具数	server 数
0	50
1–9	55
10–29	31
30 以上	17

中位数是 4，最大 628。超过 100 个工具的 server 要留意：宿主对工具数量通常有上限，超出的部分会被静默截断，表现是「明明有 200 个工具，只看到 60 个」。

症状二：命令跑完没反应，或者超时

这是 stdio 类的典型症状。按顺序查：

1. npx 能不能直接跑通（脱离宿主，手工执行一次）
2. node 版本对不对（不少 server 要求 18+，个别要 20+）
3. 首次运行要下载包，宿主超时窗口可能等不到

第 3 条在实际使用里占比不低：第一次 npx -y 要下几百 KB 到几十 MB，慢网络下很容易超过宿主默认超时。先在终端手动跑一次把包下好，再回宿主里连，成功率会明显上升。

症状三：文档说支持，你的宿主却连不上

看 checks 里的宿主维度。这批数据里，不同宿主的可用性并不一致——文档宣称支持，只代表作者测过。

判断方法：查同一个 server 在其他宿主上的判定。如果同一 server 在 5 个以上宿主是 pass、只有你用的那个 fail，问题多半在宿主侧的实现差异，不在 server。

症状四：远程服务连不上，且只有它一个失败

这批数据里 14 个 http 类，11 个失败格集中在 3 个 server 上，而且这 3 个都是零工具（free-agent-tools、huggingface、sentry）。

其中 sentry 是唯一一个标注需要鉴权（authRequired: true）的 server，17 个宿主全部 0 通过。也就是说：需要鉴权的远程 server，在缺凭据的情况下不会有任何降级表现，直接全部失败。

如果你在配远程 MCP 且它要求 token，先把凭据补齐再判断「能不能用」。单插件的安装形态与汉化情况可以在 插件清单与安装形态 按分类查。

三、四个实际会踩到的坑

坑一：把「文档支持」当成「实测可用」。
现象：README 写着支持某宿主，装上不通。
原因：数据里「文档推断」1,248 格中通过 1,170，而「真机实测」756 格中只有 169 通过。文档阶段的通过率是 93.8%，真机是 22.4%。
解决：以真机结果为准。查不到真机结论时，先在本机手工跑一次最小调用。

坑二：零工具当成「装失败了」重装。
现象：连接显示绿色，工具列表空，重装多次无效。
原因：50 个零工具 server 里，有一部分本来就不提供 tool。
解决：先看 startupMs 是否有值，再看它是否只提供 resource。重装解决不了设计问题。

坑三：协议不完全合规就判定「不能用」。
现象：协议实测 597 格零通过，看起来全军覆没。
原因：协议校验是严格模式，要求实现完整规范；而宿主侧通常更宽容。
解决：区分「不合规」和「不能用」。前者影响互通性，后者才是当下能不能干活。

坑四：在共享环境里跑 stdio，把别人的环境改了。
现象：本地能跑，换台机器就失败。
原因：stdio 类依赖本机的 node、包缓存、环境变量。
解决：要么固定 node 版本与依赖，要么改用容器隔离。这也是为什么同类 server 在「本机自测」和「CI 环境」下的结论经常不一致。

四、一张排查决策表

现象	先查	再看
工具列表空	toolCount 是否为 0	startupMs 是否有值
命令无响应	手工跑一次 npx	node 版本、包是否已下载
只有我的宿主失败	同 server 在其他宿主的判定	宿主实现差异
远程服务全失败	authRequired	凭据是否补齐
换机器就失败	本机依赖是否可复现	是否要容器化

这套判定逻辑来自一份 17 宿主 × 153 server 的逐格采集，共 2,601 格。完整的判定数据、每个 server 的传输方式与工具数可以在 MCP 兼容矩阵实测数据 按宿主与传输方式筛选查看。

总结

MCP 连接问题的第一刀应该切在传输方式上：stdio 的失败率 35.8%、http 是 4.6%，方向不同排查路径完全不同；第二刀切在证据类型上，文档推断的通过率 93.8% 与真机 22.4% 不是一个量级，以真机为准，别拿 README 当结论。更多逐格判定结果见 MCP 兼容矩阵，插件侧的分类与验证档位见 插件清单。

适合与不适合

适合：正在给宿主接 MCP、连不上又不知道从哪查的人；需要判断「是我配错了还是它本来就不行」的人；要给团队定 MCP 准入标准、需要分组失败率数据的人；维护多个 server、想批量定位共性原因的人。

不适合：想找「哪个 MCP 最好用」的人，这里只有连接与协议层的数据，没有任务效果评估；只用官方维护的那几个 server 的人，它们的可用性本来就高，分层排查意义不大；期待「装上就一定通」的人，真机通过率本身只有 22.4%。

标签：MCP、DeepSeek Harness、stdio、传输方式、排错

本文由 DeepSeek Harness Hub 自动整理，数据来源于站点 MCP 兼容矩阵快照。