我们为什么不给 MCP server 打分

本文译自 2026-09-23 的英文原文。

常有人要一个数字：“直接告诉我这个 MCP server 行不行。”我们理解这个需求，但不会满足它。这篇文章把原因讲完整。

一项检查到底是什么

我们跑的每一项检查，只回答一个很窄的问题，结果是四种之一：

• 已通过（Verified）。 我们要找的性质存在，并附有证据。
• 未通过（Failed）。 这个性质不存在或不对，并附有证据。
• 观察到风险（Observed risk）。 有值得人看一眼的情况，但它不能让我们对这个 server 整体下任何结论。
• 未检查（Not checked）。 这一项我们没能测试，那一行会写明原因：比如覆盖不到、没有授权、探测用完了预算，或者测试它需要运行我们不会运行的代码。

上面没有一项是百分比。一个 server 有十二行已通过、一行未通过，并不等于“92%”。未通过的那一行可能是握手坏了；标为观察到风险的那一行，可能是一条工具描述在指示模型忽略它的系统提示词。这两件事分量不同，而我们能公布的任何固定权重，都不可能同时适用于一个业余的天气 server 和一个支付 API。

数字会变成产品本身

一旦有了一个汇总数字，就会发生三件事，都不好。

它会成为人们优化的对象。 维护者会去调这个指标，而不是指标背后的性质。SEO 分数后来没法衡量内容好坏，是同一个机制。

它会变成我们可以被付钱去挪动的东西。 我们向维护者收费的项目是：更频繁的检查、实时徽章、更快的告警，以及能认领更多 server 的额度。如果存在一个分数，每一次谈价格都会暗含一个问题：付钱会不会影响它？我们宁愿让这个问题根本问不出来。我们这边的规则很简单：结论不卖。最干净的执行办法，就是根本没有结论可卖。

它会被当成一个我们并没有做出的决定。 一个绿色的等级等于在说“放心用吧”。我们没有看过你的数据怎么处理、你的后端怎么样，也没有看过你的工具被调用时会做什么。我们只是从外面看了协议这一层。给出判决，就是说了证据撑不起的话。

我们怎么做

我们展示每一行，以及它背后是哪一类证据；在已签名的运行上，还展示它的状态；页面会写明那次运行发生在什么时候。视觉语言刻意做得很平：四种状态，每种有一个形状、一个词和一种颜色，所以截图转成灰度也一样能读。未签名的运行用同样的版式，但没有颜色，任何一行都不显示状态：每一行写明这项检查测什么，以及我们记录到的原因（如果有），但不给判定，因为背后没有签名。我们绝不会为了推人付费，把页面做得更难看。

每一次符合我们发布规则的运行，不论是否被认领，都会得到一份签名证明：一份声明，说在这一天，我们的探测器观测到的正是这些内容；任何人都可以用我们公布的公钥自行验证，不用来问我们。注意签名覆盖什么、不覆盖什么。它覆盖的是：这些观测是我们做的，并且没有被改动。它并不是说这个 server 好。未签名的运行之所以不着色、并标为未签名，也是同一个原因：我们绝不让一条观测打扮成经过验证的结论。

README 徽章遵循同一条规则。免费档上它只写“claimed”（已认领），别的什么都不写。付费档上，只有当最近一次运行已签名时，它才显示那次运行里实际跑过的检查中最严重的结论；未签名的运行不显示任何结果。

“可我还是得做决定”

是的。这个页面是为了帮你做决定，而不是替你做决定。先读未通过的那些行：每一行都写了我们观测到什么，你可以用 curl 复现。再读观察到风险的那些行，对照你的 agent 实际会允许这个 server 做什么来判断。把“未检查”就当成字面意思：是缺少信息，不是悄悄算作通过。

如果这听起来比读一个数字费事：确实如此。但这也是唯一诚实的工作量，而且正是我们为了给你一个数字、本来得藏进那个数字里的同一份工作。