风险等级高的 MCP 服务，真机通过率反而更高？

风险等级高的 MCP 服务，真机通过率反而更高？

先看一组数：riskLevel=3 的 13 个条目，真机三列实测 39 格可判、19 格通过，48.7%；riskLevel=0 的 140 个条目，411 格可判、150 格通过，36.5%。敏感度最高的一档，通过率反而高出 12 个百分点。

这个结论如果直接写进选型建议，会把人带偏。按宿主逐列拆开，三列的方向一致地反过来了。

按 2026-11-02T19:53:24Z 的全量快照重算：161 个 server 剔掉 8 个内部占位后是 153 个，其中 140 个是 riskLevel=0、13 个是 riskLevel=3，没有中间档。

认证这一栏其实只有一个样本

想回答「需要授权的服务能不能连上」，得先看有多少个这样的样本。153 个条目里 authRequired=true 的只有 1 个 —— sentry，一个 http 远程条目，工具数 0。它在 17 个宿主上实测 17 格全部为无数据，可判 0 格。

也就是说，认证要求这个变量在这份矩阵里没有产生任何一格判定。凡是从这张表推出「某宿主对需要鉴权的服务支持不好」，都没有数据支撑；反过来推「支持」同样没有。这一栏只能自己动手测。

同样落进「无数据」的还有另两个远程条目，在真机三列也是 na。它们不是失败，是没被测到 —— 采集机的网络到不了，与条目本身无关。

13 个高风险条目是什么样子

工具数跨度很大，从 appscreen__mcp 的 2 个到 signal8ai__mcp 的 108 个，全是本地进程，没有一个是远程。这一点决定了它们的表现更接近「普通 stdio 条目」，而不是「特殊的高危服务」。

逐宿主拆开，方向反了

把 13 个高风险条目与 90 个「riskLevel=0 且有工具」的条目按宿主对照，三列结果如下：

三列里高风险组都不高于对照组，claude-code 上两者几乎并列，另两列各差 11 个百分点。全表 103 个有工具的条目真机实测 169 格通过、140 格失败，可判 309 格，通过率 54.7% —— 高风险组 48.7% 比这个整体水平还低 6 个百分点。

所以前面那个「高 12 个百分点」不是风险属性带来的，是分母的构成带来的。

那 12 个百分点是怎么来的

riskLevel=0 的 140 个条目里，有 50 个工具数为 0。全表 50 个零工具条目，无一例外全部落在 riskLevel=0。它们在三列真机上共 150 格，其中 141 格失败、9 格无数据，通过 0 格。

把这 50 个剔除，riskLevel=0 剩 90 个条目：真机实测 150 格通过、120 格失败，可判 270 格，通过率 55.6%。分子分母一换，结论就从「高风险更顺」变成「高风险略低」。

零工具条目为什么全在低风险档，逻辑上说得通：一个连工具都没暴露出来的服务，自然也谈不上敏感能力。但它会把低风险档的分母拖低 50 格 × 3 列 = 150 格，足以翻转一个 12 个百分点的结论。

坑一 · 拿风险等级当兼容性指标

现象：看到某类服务 riskLevel 高，就预设它更难接。原因：风险等级衡量的是它能读什么、写什么、能不能执行命令，与「进程起不起得来」是两个独立维度。解决：选型时把两个问题分开问 —— 能跑通看真机格，能碰什么看风险等级与能力清单，不要互相替代。

坑二 · 分母里混进零工具条目

现象：按分类或按标签算通过率，某一组莫名偏低。原因：50 个零工具条目全部集中在低风险档，它们在任何宿主上都起不来，等于给这一组固定扣分。解决：算任何分组的通过率之前，先把 toolCount=0 的条目单独拎出来，它在真机上是 141 格失败、0 格通过，没有讨论价值。

坑三 · 以为认证失败在矩阵里有记录

现象：看到灰格就怀疑是 token 或凭据问题，开始翻环境变量。原因：全表 authRequired=true 只有 1 个样本、0 格可判，认证维度根本没有被测量过。解决：灰格先分两类 —— 可判但失败（真故障）、无数据（没测过）。需要鉴权的服务属于后者，只能自己配一次。

坑四 · 用一列的结果推全部

现象：在 claude-code 上 13 个高风险条目全过，就认为这批服务在哪都能用。原因：同一批条目在 gemini-cli 与 qoder 上各只过 3 个，通过率 23.1%。解决：多宿主场景按最差那一列做决策，或者明确只支持一列；单列结论不能外推。

两个问题要分开问

第一个问题：这个服务能碰到什么。看风险等级、工具数、是否要凭据、是否走本地进程。第二个问题：在你的宿主上它能不能跑起来。看真机格。两个问题都答完，才构成一次完整的评估；只答一个，选型依据就不完整。

具体的失败现象分类在 坑点清单 里按五组整理，需要鉴权的条目建议先照 排查方法 走一遍授权流程再谈兼容。宿主侧的能力边界（传输方式、工具数上限、是否支持远程）在 宿主能力表，属规则推导，不能与真机格并列引用。单个条目的逐格记录可以从 server-memory 这类已知可用条目进去对照，字段含义见 名词表。

数据口径

本文数字取自 2026-11-02T19:53:24Z 生成的全量快照，mode=full、finalChunk=true，采集机 node v22.23.2；真机三列对应 claude-code 2.1.311、gemini-cli 0.66.0、qoder 1.1.80。口径为剔除 8 个 isFixture 条目后的 153 个真实 server；riskLevel 与 authRequired 是条目属性，不随宿主变化，toolCount 与 startupMs 取自同一次探测结果。

两点限制须说明：真机只有一台采集机、每格判一次、不含重试，因此「偶发失败」在这份数据里不可见；风险等级是静态扫描的结论，反映的是能力面，不代表运行时行为是否安全，也不代表条目可信。若要判断一个服务能不能放心接入，还需要看它的授权范围与出网目标，那部分不在本文范围内。

总结

48.7% 与 36.5% 的反差是分母造成的：50 个零工具条目全部落在低风险档，剔掉后高风险组反而低 7 个百分点。风险等级回答「它能碰什么」，兼容矩阵回答「它能不能连上」，两件事不该串用；而认证这一维度在现有数据里只有 1 个样本、0 格可判。

适合与不适合

适合：要给一批 MCP 服务做准入评估的人；被「高风险所以更难接」这类说法绕住的人；在写方案、需要说明数据口径与样本量的人；想弄清风险字段到底量了什么的人。

不适合：想找一份「安全服务白名单」的人 —— 本文只谈兼容性口径，不评价任何条目是否安全；只打算用一个宿主、且已经跑通的人；希望用风险等级替代实测的人。

标签：MCP、风险等级、认证要求、分母口径、准入评估

本文由 DeepSeek Harness Hub 自动整理，数据来源于 MCP 兼容性采集快照（2026-11-02），口径见文末。