方法论
四种断言状态
- VERIFIED（已通过）
- 在这一轮探测中，我们独立观测到这项检查通过，针对的正是这个 endpoint。
- FAILED（未通过）
- 我们独立观测到这项检查未通过。我们如实展示——未通过的检查不会被隐藏或改写措辞。
- OBSERVED_RISK（观察到风险）
- 我们观测到一个值得标注的情况，但它本身不是通过/不通过的结论——例如工具描述中包含面向 AI 读者而非人类读者的内容。这是一个信号，不是判决。
- UNVERIFIED（未检查）
- 这一轮探测中我们没能对这项检查得出结论，并且会说明原因（见每条 UNVERIFIED 断言附带的理由）。UNVERIFIED 绝不会被当作通过处理。
执行状态（完成 / 出错 / 跳过 / 阻塞）与上面四种状态分开记录，绝不会被合并成一个通过/不通过的计数。
两个数字的口径
已观测日可达率：过去 90 个 UTC 日中，endpoint 有应答的天数占「能判定的天数」的比例。当天每一次可达性检查都得到 endpoint 应答，算可达；当天任何一次没有得到应答——域名无法解析、（自 2026-09-27 起）连接失败、或探测时间预算内没有收到完整响应——或（自 2026-09-23 起）握手被 5xx 应答，算未应答。若当天只有我们自己造成的未判定——被限速、或我们的策略拒绝连接——这一天不计入任何一边。计入的天数标在百分比旁边。
协议修订：从我们的握手中记录下的修订。探测器先发出 2026-07-28 修订的 server/discover 请求；服务器以 HTTP 2xx 和 discover 结果回应时，我们记录它所列支持修订中的第一项。服务器以 429 以外的 HTTP 2xx 或 4xx 回应、且内容既不是 discover 结果、也不是 2026-07-28 修订定义的协议错误时，探测器回退到 legacy 的 initialize 握手、提出它所知最新的 legacy 修订 2025-11-25，并记录服务器答复的修订。两种情况都不表示服务器支持的最新修订。每次运行还会记录探测器提出的修订；只有在提出相同修订的两次运行之间记录下的修订变了，或者服务器在 legacy 的 initialize 握手和较新的 server/discover 握手之间切换了，才算服务器那边的变化。在我们开始记录提出的修订之前的运行，按提出 2025-06-18 处理，除非存下的结果表明探测器用的是较新的发现握手。
「已观测，未签名」
部分 target 页面只展示原始观测结果，不以上述四态给出判定，也没有密码学签名。这发生在该次运行的证明因某个已注明原因（页面上会显示）被取消发布资格、或该次运行没有任何证明时。它与 target 是否被认领无关：无论有没有人认领这个 target，签名的方式都一样。这些页面如实报告我们看到的内容——检查结果绝不以通过/不通过的结论、分数或状态徽章呈现，因为这次观测没有附带任何签名。
需要认证时的签名
服务器对我们不带凭据的请求返回 401 和认证质询时，这次运行仍可以签名，但签名只为认证墙之外能观察到的事实作保：可达性、重定向策略、传输方式和认证元数据。载荷还记录认证质询本身，只留名称、至多一个 URL 和至多一个摘要。签名载荷里其余各项都是 UNVERIFIED，并附原因；报告页对这些项不给结论。探测器从不发送凭据。没有可用认证质询的 401、连接失败或 5xx，都不会得到这种签名。
关于证据格式的说明
在这条说明之前签发的签名证明，理由与细节文本以自由文本形式直接写在签名载荷内。此后签发的证明改为携带一个理由 key 与结构化参数——由本网站在请求时渲染成读者所用语言。两种形式都是同等有效、可验证的证据，变化的只是说明文字的编码方式。
是什么标识了跑这些检查的代码
每一份签名证明都写明了产出它的检查套件代码。从 payload 0.3 起，它同时携带 suite_commit（仓库的一个 commit）与 suite_digest——后者取自该 commit 下 packages/checks 的 git 树清单。精确配方这里刻意不复述：它最显然的那种改述指向的是另一个值，所以权威表述是每个证据页上印出的那一条命令。0.3 之前签发的证明只带 suite_digest，用的是更早的定义——指向一个从未发布过的 npm 包；这些值按原样展示，无法复现。suite_commit 位于 github.com/mcpcheckup/checks 的证明，任何人都能在那里的克隆里复算；带 suite_commit 但签发于检查套件公开之前的证明，指向的 commit 所在仓库未公开，项目之外的人核不了它们的摘要。如果某个 envelope 声明的 payload 版本本站没有对应的 schema，页面就照实这么说，而不去猜。这一整节都不涉及检查得出了什么结论——它只标识是哪份代码得出的这些结论。
工具指纹与 schema 指纹如何计算
报告里的 toolset_fingerprint 与 schema_fingerprint，是探测器从服务器 tools/list 应答中读到的工具列表经投影后取的 SHA-256 摘要，记录在 toolset_projection_version "v1" 之下。两者都写作 sha256: 加 64 个小写十六进制字符。每个工具只读取下面点名的字段；工具上新增的其他字段不会改变任何一个指纹。
toolset_fingerprint：只取每个工具的 name。在做任何规范化之前，按 UTF-16 码元把这些名字当作普通字符串排序，重名保留。把排好序的数组写成下面的规范形式，对其 UTF-8 字节取 SHA-256。
schema_fingerprint：只取每个工具的 name 和服务器原样发来的 inputSchema。这些对按 name 以同样方式排序；name 相同的工具，再按各自 inputSchema 的规范文本以同样方式比较。把排好序的 {"inputSchema": …, "name": …} 对象数组写成规范形式，对其 UTF-8 字节取 SHA-256。只要有一个工具没有 inputSchema，schema_fingerprint 就算不出来，记为 FAILED。
规范形式叫 nfc-jcs/v1：先多做一步，再套用 RFC 8785（JSON 规范化方案）。这一步是把每个字符串和每个对象键转成 Unicode 规范化形式 C；规范化后同一对象里有两个键变得相同，或字符串里有未配对的代理码元，都会被拒绝。之后每一层的对象键按 UTF-16 码元排序，数组保持原顺序，不写多余的空格和换行，字符串用最短的 JSON 转义，数字取 JSON.parse 读出的 IEEE 754 双精度值，并按 ECMAScript 的写法输出。它不叫 RFC 8785，因为该标准禁止那一步规范化。
覆盖哪些工具：自套件 0.15.0 起，探测器会顺着 nextCursor 读完 tools/list 的每一页，最多 10 页、5,000 个工具，两个指纹都对它们合在一起的整个列表计算；页和工具的先后不影响结果。如果列表没能读到最后——到了上限，或后面某一页超时、超出大小限制、读不出有效的 tools/list 结果——这次运行就不计算任何指纹：两项指纹检查都是 UNVERIFIED，原因为 tools_list_incomplete，这次运行不存工具列表，也不签名。后面某次请求若以其他方式失败，这次运行就以那个失败自己的原因结束，或以表示运行中止的通用原因结束，结果相同：没有指纹、不存工具列表、不签名。两种情况下，get_mcp_report 对这次运行返回的 schema_fingerprint 都是 null，返回的 toolset_fingerprint 则是最近一次存下的工具列表的（如果有的话），由 snapshot_run_id 和 snapshot_observed_at 标明是哪次运行、什么时候。套件 0.14.0 及更早的运行只读第一页，它们记录的指纹只覆盖那一页。
想自己复算：取得服务器 tools/list 的应答（每一页），然后在 github.com/mcpcheckup/checks 的 packages/canonicalizer/scripts 里对它运行 recompute-fingerprints.mjs。这个脚本用纯 Node、不依赖任何包，按上面的步骤实现，并打印两个指纹；同一个包里的 PROJECTION-v1.md 给出完整规则，以及取得本站自己工具列表的 curl 命令。指纹描述的是那次运行读到列表时的样子。只有它的投影所覆盖的字段变了，指纹才会变：toolset_fingerprint 看工具名（增加、删除或改名一个工具），schema_fingerprint 看工具名或 inputSchema；description 或其他字段变了，两个指纹都不变。
这个产品不做什么
我们只检查能够从外部独立观测到的内容，按固定周期，针对一个存活的 endpoint。我们不审计源代码，不保证 endpoint 在两次探测之间的行为，一份干净的报告也不是保证——它只是当时检查了什么、看到了什么的记录。每个报告页自己的覆盖率摘要会准确说明那一轮到底跑了什么、没跑什么。
各项检查
可达性与性能
这个 endpoint 现在还活着吗、响应多快。**只观测，不判定**——我们不定义多少毫秒算慢，那取决于你的用户。
reachability
endpoint 在预算内响应
- 检查什么:
- endpoint 在给定预算内是否返回响应，并记录延迟分布。
- 如何判定:
- 我们的握手交换以 endpoint 的 HTTP 回应结束时（任何状态码都算），记 VERIFIED。如果探测在交换结束前停下——例如 endpoint 要求我们稍后再来（429，或带 Retry-After 的 503）、某个回应超出大小上限、连接出错、或探测的某项预算用尽——本项记 UNVERIFIED 并附上原因，即使 endpoint 已经答复过之前的请求。整次探测（含握手）都在硬上限内进行：总共 8 个请求、10 s，每个回应 2 MB。读取较长工具列表的后续页，最多在 8 个请求之外再加 9 个，同样受 10 s 和每个回应 2 MB 的限制。
- 它不能说明什么:
- 超时不等于你挂了——也可能是我们这边的网络。所以超预算记 UNVERIFIED 而不是 FAILED。目录里的在线率口径更严：当天任何一次探测在预算内没有收到完整应答，这一天算未应答。
latency_profile
从我们探测节点测得的请求响应时间 p50 / p95
- 检查什么:
- 单次 run 内，我们发往该 endpoint 的请求从发出到收到响应头的耗时：中位数（p50）、第 95 百分位（p95），以及计时的请求数 n。
- 如何判定:
- **不做判定。** VERIFIED 只表示测到了，不表示快：我们不设阈值，也不按速度给 server 排名。本轮中发往该 endpoint、收到 HTTP 回应的每个请求都计时，不论状态码；没收到回应的不计。计时从请求发出前开始，到收到响应头为止，不含我们自己的 DNS 校验，也不含响应体的下载。p50、p95 按最近秩取自 n 个计时请求；少于 20 个请求时，p95 就是其中最慢的一个。握手阶段就停在认证质询的运行不记录时间。一个计时请求都没有时，本项记 UNVERIFIED。
- 它不能说明什么:
- 这是我们探测节点看到的值，不代表你的用户看到的值。其中包含我们节点到你 endpoint 之间的网络、建立连接的时间，以及在我们自己 Worker 里的等待。
协议契约正确性
你的 server 是否真的按它声称的那版 MCP 协议说话。这是本产品的主体：绝大多数「agent 突然用不了」的故障出在这一层，而不是安全层。
transport_type
端点经所用传输回应了握手请求
- 检查什么:
- 本次探测所用的传输类型，以及端点是否经该传输作出回应。
- 如何判定:
- 我们经该传输的握手交换以端点的 HTTP 回应结束时，记 VERIFIED，无论握手本身是否成功（那由 discovery_handshake 判定）。如果探测在交换结束前停下——例如端点要求我们稍后再来、某个回应超出探测的大小上限、或探测的某项预算用尽——本项不记 VERIFIED，并同时记下原因。不会与 server 声明的传输做比对。
- 它不能说明什么:
- 不能说明传输实现有没有 bug。
protocol_revision
协议 revision 可识别
- 检查什么:
- server 实际遵循的 MCP 协议 revision。
- 如何判定:
- 能识别到矩阵内任一版本即通过。
- 它不能说明什么:
- 不能说明该版本实现得完整。当握手被凭据门控（见 discovery_handshake），本检查级联记 UNVERIFIED（原因 credential_required）：握手没有完成，不会拿任何声明的版本号去比对支持矩阵。
discovery_handshake
现代 server/discover 或 legacy initialize 行为符合该 revision 规范
- 检查什么:
- 现代 `server/discover` 或 legacy initialize 的行为是否符合该 revision。
- 如何判定:
- 按识别到的 revision 选择对应规范比对。
- 它不能说明什么:
- 不能说明 discovery 返回的内容是准确的。若决定握手结果的那次响应是 401 且带有格式合法的 WWW-Authenticate 质询，本检查记 UNVERIFIED（原因 credential_required）而非 FAILED——我们从不发送凭据，无法看到有意设置的访问控制门之后的情况。无合法质询的 401、403、或首个请求上已识别的 MCP 协议错误码，都不视为凭据门控。
tools_list
tools/list 可用并返回合法结构
- 检查什么:
- `tools/list` 是否可用并返回结构合法的工具列表。
- 如何判定:
- 结构不合法即 FAILED，因为下游 agent 会直接解析失败。服务器把列表分页时，我们沿 nextCursor 读取每一页，一次 run 最多读 10 页或 5,000 个工具。第一页之后的页不计入 8 个请求的上限；10 s 的时间上限和每个回应 2 MB 的上限照样适用。列表超出这个范围，或后面某一页超时、请求或回应超过 2 MB、或读不出工具列表时，我们就停在那里不再翻页：本项仍按第一页判定，依赖完整列表的结论都不记为 VERIFIED（见各项检查）。后面某一页遇到其他失败（例如服务器要求我们稍后再来，或连接失败）时，和其他请求一样，本次 run 就此结束。
- 它不能说明什么:
- 不能说明这些工具真的能用——我们不调用业务工具。若握手已完成但 tools/list 返回 401 且带有格式合法的 WWW-Authenticate 质询，本检查记 UNVERIFIED（原因 credential_required）而非 FAILED；若握手本身被凭据门控，本检查级联为同一结果。
error_taxonomy
错误响应符合协议定义的形状
- 检查什么:
- 触发一个安全的错误场景，看错误响应的形状是否符合协议。
- 如何判定:
- 偏离记 OBSERVED_RISK——错误形状不规范会让 agent 无法正确重试。没能读完整份工具列表时（见 tools_list），我们不发这次调用，因为要调用的名字可能属于一个没读到的工具；本项记 UNVERIFIED，原因 probe_tool_name_unverifiable；若已读到的某一页列出了这个名字，原因则是 probe_tool_name_collision。
- 它不能说明什么:
- 不能说明所有错误路径都规范，我们只探了非破坏性的那几条。
安全卫生
公开可观察的基础安全属性。**这不是安全扫描**——我们不测 prompt injection、数据外泄、权限滥用，因为那需要执行业务工具，而我们默认禁止这么做。
tls_certificate
证书有效、未过期、SAN 匹配、链完整
- 检查什么:
- 证书有效期、SAN 是否匹配、证书链是否完整。
- 如何判定:
- 过期 / 不匹配 / 链断裂均为 FAILED。确定性判定。
- 它不能说明什么:
- 这是最基础的传输层卫生，**和「这个 server 安全」是两回事**。
redirect_policy
重定向不跨越到非预期主机
- 检查什么:
- 重定向是否跨越到非预期主机。
- 如何判定:
- 跨主机重定向记 OBSERVED_RISK。只有读取授权元数据的 GET 会跟随重定向，最多 3 跳；协议 POST 收到重定向时只记录，不跟随。即使 run 在这之后停止（例如超过跳数上限、遇到我们不连接的另一个主机，或服务器要求我们稍后再来），已观察到的跨主机重定向也照样记录。
- 它不能说明什么:
- 不能说明目标主机可信，只说明有没有发生跳转。
auth_metadata
公开可观察的认证 metadata / challenge 结构合法
- 检查什么:
- 无凭据时公开可观察到的认证 metadata / challenge 结构是否合法。
- 如何判定:
- 结构不合法记 OBSERVED_RISK；完全无法观察时记 UNVERIFIED。
- 它不能说明什么:
- **不能说明认证强度。** 我们没有凭据，看不到认证真正的执行路径。
tool_description_hygiene
tool name / description 不含针对 agent 的注入模式或隐藏字符
- 检查什么:
- tool name / description 中是否含隐藏字符或针对 agent 的注入模式。
- 如何判定:
- 零宽字符、Unicode Tag 区、双向覆盖符、指向助手的祈使句式、未经逐次确认的花费或身份信息发送、不等用户再次提出就继续工作；命中记 OBSERVED_RISK。超过 2,048 个字符的描述仍会列为异常长度，但仅凭长度不再算作风险。夹在同一种文字的两个字符之间（跳过组合附加符号）、属于正常拼写的 ZWNJ / ZWJ（适用于阿拉伯文、天城文等我们列出的文字）不算命中；直接夹在两个图形符号（emoji）字符之间的 ZWJ 也不算，但跟在肤色修饰符后面的 ZWJ 仍算。「do not tell the user」（以及 inform、mention、reveal、show；the 可省略，user 也可以是 human）在后面紧跟 about、that you、what you、how you、anything、any of、. , ; : ! ) 之一或文本结尾时算；后面紧跟 's 或 ’s、前有空格或制表符的连字符、en 或 em 破折号、换行，或 that、what、why、where、how、this、any 之一时也算，除非在它之后（如果是换行，就是下一行）到下一个 . , ; ! ?、换行或，。！？；之前出现 until、unless、yet、before、after、otherwise、once、while、if、when 之一。「system prompt」「developer prompt」在前面是 your 或 your new 时算；前面是 reveal、print、output、repeat、disclose、leak、ignore、override、disregard、forget、show、return、display、replace、dump、echo、act as 之一时算，其后可依次隔 out，the、any、all 或 your，previous、prior、above、earlier、original 或 contents of，以及 the 或 your；位于行首（前面只有空格、制表符、#、*、>、[ 或 -）且后面（可隔空白）是冒号或 override 时也算。「never」「do not」或「don't」（两种撇号均可）后接 say、mention、tell、disclose、reveal 或 state，并且同一从句里它后面出现 missing、not verified、unverified、failed 或 absent 时也算，除非两者之间出现 because、when、if、unless、since、as 或 so。「未经逐次确认的花费或身份信息发送」指出现以下短语之一：pay 后面同一句内（句子在 . ! ?、换行或。！？处结束）40 个字符以内接 by default；no approval 或 no confirmation 后接 needed 或 required（中间可有 is）；need not ask；zero questions；without asking，但同一句内（句子在 . ! ?、换行或。！？处结束）它前面 30 个字符以内有 never、not 或以 n't（ASCII 撇号）结尾的词，或者它后面接 for 或 us 时不算；does not 或 doesn't require per-change、per-action、per-call、per-purchase 或 per-payment approval（per 后面也可以是空格）；the grant、allowance 或 delegation is the 或 your permission、approval 或 consent；accept 或 approve 后接 all、every 或 any，再隔至多两个词接 prompt、confirmation、dialog 或 request（单复数均可）；continues、repeats 或 recurs automatically；the、your 或 this agent loop；git config 后接 user.email（中间可以有 --get 之类的选项）；never ask（中间可以有 the user）before 后接 charging、paying、buying、purchasing、spending、billing、renewing 或 subscribing；无需确认或无需另行确认；视为同意或视为用户同意；sell、sells、selling、sellable、resell、resells、reselling 或 resellable，同一句内 80 个字符以内再接 entrusted 或 lent、可选的 to 和 you；raise、increase、disable 或 turn off，可隔 the 或 your，再接 spendControls（其后可带一个点和名称）、maxAmountPerPayment、spend 或 spending 加 limit、limits、cap 或 caps，或 payment 加 cap 或 caps；set，可隔 the 或 your，再接上述之一，可再接 :、= 或 to，再接 false 或 0（后面不能紧跟点、字母、数字或下划线）；pays、charges 或 spends 后面同一句内 40 个字符以内接 from，再接 your owner's、the user's、your human's 或 the human's（两种撇号均可），再接 credit、credits、balance、wallet 或 funds，但这一句或下一句里出现 confirm、confirms、confirmed、confirming、confirmation、confirmations、approve、approves、approved、approving、approval 或 approvals，或 ask、asks、asked 或 asking 后面同一句内 40 个字符以内接 permission 时不算（这一种里，句子在后面跟空白或位于文本结尾的 . ! ?、换行或。！？处结束，两句合计从短语起点向前最多 400 个字符、向后最多 800 个字符）。只有当它前后 200 个字符以内出现花费或身份类的词（pay、pays、paid、paying、payer、payment、payments、charge、charges、charged、charging、credit、credits、wallet、wallets、USDC、invoice、invoices、purchase、purchases、purchased、purchasing、buy、buys、buying、subscribe、subscribes、subscribed、subscribing、subscription、subscriptions、renew、renews、renewed、renewal、renewals、bill、bills、billed、billing、cost、costs、fee、fees、refund、refunds、refunded、refundable、spend、spends、spending、money、identity、email、emails、e-mail、e-mails、$ 加金额，或扣费、续费、费用、支付、付款、购买、订阅、钱包、邮箱、身份），并且它前面 120 个字符以内没有 cap、caps、capped、limit、limits、ceiling、ceilings、max、maximum、policy、policies、mandate、mandates、allowlist、allowlisted、whitelist、whitelisted（也可带连字符：allow-list、white-list）、threshold、thresholds、quota、quotas 或上限、额度、限额、策略、白名单时才算（提高或关闭上限的那一种不受这一条限制）。花费或身份类的词所在的从句如果同时写明不花钱或不发送，这个词就不算：cost 或 costs 后接 nothing（中间至多两个词），free，no charge、no cost 或 no fee（含复数），does not、doesn't、do not、don't、never、will not 或 won't（ASCII 撇号）后接 send、collect、store 或 share（含加 s 的形式），或者免费、不收费；紧跟在 feel 后面的 free 不算。从句在后面跟空白或位于文本结尾的 . ! ?、在 , ; 或换行、以及在，。！？；处结束，并且从这个词的第一个字符起向两侧各最多延伸 200 个字符；同样的词出现在别的从句里不起作用。短语所在的从句如果出现 no purchase（或 no purchases）、read-only（或 read only）、does not 或 doesn't 后接 buy、purchase、register 或 charge、what it costs 或 how much，这个短语就不算；这些词出现在某个花费或身份类的词自己的从句里时，那个词不算；出现在其他从句里不起作用。「不等用户再次提出就继续工作」指 without 后面（可隔 waiting for）接 another、a further、any further、further、a new、a second、an additional 或 additional，再接 user 或 human，再接 prompt、message、request、turn 或 reply（单复数均可）。我们读取工具列表的全部页。没能读完整份列表时，已读到的工具里有命中仍记 OBSERVED_RISK；没有命中则记 UNVERIFIED 而不是 VERIFIED，因为没读到的工具没有检查过。
- 它不能说明什么:
- **不能推断意图。** 这些模式在合法工具里也可能出现（例如一个专门处理 Unicode 的工具）。我们只报告信号。
契约变更与供应链
工具集与 Schema 有没有在你不知情的情况下变过。**只有在你批准过一个基线之后**，变化才会被判为「未通过」；否则它只是一条已记录的变化事实。
toolset_fingerprint
工具集的 canonical fingerprint 可计算并已记录
- 检查什么:
- 把工具集做 JCS 规范化后计算 SHA-256 指纹并归档。
- 如何判定:
- **算得出就是 VERIFIED**——只判断「可计算」，不判断「变没变」。指纹按工具列表的全部页计算；没能读完整份列表时（见 tools_list）不计算指纹，本项记 UNVERIFIED。
- 它不能说明什么:
- 指纹本身不代表好坏，它只是一个可被第三方复算的事实。
schema_fingerprint
各 tool inputSchema 的 canonical fingerprint 可计算并已记录
- 检查什么:
- 把每个 tool 的 inputSchema 规范化后计算指纹并归档。
- 如何判定:
- 同上：只判断可计算性。按工具列表的全部页计算；没能读完整份列表时记 UNVERIFIED。
- 它不能说明什么:
- 同上。
toolset_unchanged_vs_approved
工具集相对已批准发布未变化
- 检查什么:
- 当前工具集与**你批准过的那次发布**是否一致。
- 如何判定:
- 有已批准基线时才执行；新增 / 删除工具即 FAILED。没能读完整份工具列表时没有可比对的内容，记 UNVERIFIED。
- 它不能说明什么:
- 没有基线时永远是 UNVERIFIED——没人告诉过我们正确的样子是什么。
schema_unchanged_vs_approved
canonical schema 相对已批准发布未变化
- 检查什么:
- 每个 tool 的 canonical schema 与已批准基线是否一致。
- 如何判定:
- 有基线时才执行。**这是拦 rug pull 最直接的一项。**没能读完整份工具列表时记 UNVERIFIED。
- 它不能说明什么:
- 同上：未认领的 server 上它只能是 UNVERIFIED。
怎么读报告页的在线记录
一天里每次检查都得到应答，这天才记为「有应答」；只要有一次没有应答，或握手收到 5xx，这天就记为「无应答」。有检查探测器无法判断、但没有一次无应答的日子，不计入。
报告页的在线记录里，小圆点表示我们第一次检查这台 server 之前的日子。这些日子不计入，也不补填、不猜测。
怎么核实一份已签名的报告页
完整签名的报告页上，每一条结论都经过签名 —— 完整签名载荷见该 server 的证据页。独立核实用的是我们已发布的公钥，列表见 /zh/keys。
检测频率
未认领的服务器每 12 小时探测一次；认领后，Free 档每 8 小时一次，Indie 档每 15 分钟一次。每个目标当前所处的检测周期，见其报告页。
「观测已 X 小时未更新」
当页面（报告页、/servers 卡片或首页「最新」列表）展示的观测，早于该 server 自己的检测周期（尚未被站长认领的 12 小时、Free 档 8 小时、Indie 档 15 分钟）再加一个固定余量 4 小时 40 分钟时，就会标为「观测已 X 小时未更新」。余量按最多 6,250 台 server 在我们探测队列里排队的最坏等待，加上我们平台自身的单轮与在途限制来定。徽章以「observation X h old」显示同一个事实。MCP 工具响应以机器可读字段给出同一个事实（定义见各工具描述），不使用本页这句文案。这个余量对所有档位相同，只有周期不同；付费只会改变周期，绝不改变这条规则。X 向下取整到整小时；因为缓存，页面最多可能比底层数据滞后约 6 分钟，被其他网站缓存的徽章可能滞后更久。这里说的只是我们自己的观测节奏；探测器本身是否在运行，见 /status（连续 20 分钟没有任何探测记录，或有探测任务超过 8 分钟仍未完成时，它的状态会改变）。如果全站都显示「观测已 X 小时未更新」，说明是我们自己的观测停了，不代表被观测的 server 发生了变化。
未变化的天数
报告页上的「工具列表上次变化：…（此后至少 N 天未变）」给出的是：已存的工具列表中，与其前一份不同的最新一份所在的 UTC 日期。N 是下界：只统计该日期之后、至少有一轮我们的探测成功列出了该服务器工具的 UTC 日历日。没有成功列出工具的日子，以及我们已不再保留逐次探测记录的日子，都不计入。
我们探测哪个端点
从 Registry 添加 server 时，我们取它最新 active 版本所列的一个 Streamable HTTP 地址：按地址字母顺序，取第一个主机未被我们追踪的其他 server 使用的地址。如果这个版本没有列出 streamable-http remote，我们就不添加这个服务器，因为我们的探测器只支持 Streamable HTTP。每 6 小时，我们把从 Registry 添加的 server 与它们最新 active 版本所列的地址对照一次。只要我们正在探测的地址仍在其中，就继续使用它；如果它不再被列出，我们可能把探测地址换成该版本所列的第一个 Streamable HTTP 地址（按地址字母顺序，且其主机未被我们追踪的其他 server 使用），前提是一轮不带凭据的测试显示该地址有响应。站长通过认领添加的服务器，按站长提供的端点探测。报告页和 MCP 工具响应会写明所显示的那次 run 探测的端点（已知时），并说明这个 URL 取自签名 payload，还是取自我们自己未签名的记录。
检索排序
检索结果按词法文本相关度排序——即查询中每个词与服务器实际观测到的工具名和描述的匹配程度——相同相关度时按最近观测时间排列。付费层级永不影响排序。每个查询词按原形或英文词干形匹配；以「-」开头的词会排除当前工具集命中该词（任一形态）的服务器。不支持引号短语邻接与 OR 操作符。
在 /servers 上，「相关度」先列服务商名或服务器名与查询完全相同的服务器，再列服务商名、服务器名或地址包含查询中每个词的服务器，最后是只靠工具名和描述命中的服务器（规则同上）；相同时按最近观测时间排列。按名字或地址命中的结果，也包括需要凭据的服务器，以及最近一次检查没有拿到工具列表的服务器。付费层级同样永不影响这一排序。
在 /servers 上，服务商名、服务器名或地址与查询只是拼写相近的服务器，不论按哪种排序，都列在其他所有结果之后，放在单独的标题之下；它们出现在哪一页，那一页就显示这个标题。
更正
在 0.12.0 套件之前，有三项检查可能在并未观察到其所指内容的情况下被记为已通过。自我们第一次记录运行（2026-08-20）起：只要握手请求得到了应答，latency_profile 就被记为已通过，但并没有测量延迟；auth_metadata 只要探测器工具调用得到的回应不是 401 就记为已通过，此时并没有可检查的认证质询；error_taxonomy 只要该回应是 401 或 403 就记为已通过，此时并没有返回可供分类的协议层错误。0.12.0 套件（更正于 2026-10-17）把这些情形记为未检查，并附原因。更早的已签名结果保持不变，仍可按签名验证；在报告页上，更早套件的 latency_profile 显示为未记录。自 0.16.0 套件起，latency_profile 开始测量：从我们探测节点测得的到响应头的时间，不做判定。自 0.17.0 套件起，tool_description_hygiene 不再把一部分属于正常拼写或 emoji 的零宽连接符和非连接符算作命中；「do not tell the user」和对 system prompt、developer prompt 的提及只在特定形式下才算，确切条件见该检查的页面。更早的已签名结果保持不变。自 0.18.0 套件起，tool_description_hygiene 还会标出一部分「未经逐次确认的花费或身份信息发送」的写法，并重新计入 0.17.0 套件不再计入的一部分「do not tell the user」以及 system prompt、developer prompt 提及形式。自 0.19.0 套件起，tool_description_hygiene 不再把仅凭长度算作风险（超过 2,048 个字符的描述仍会列出），并且还会标出一部分要求助手不等用户再次提出就继续工作的写法、一部分要求助手不说出检查缺失或失败的写法，以及另一部分花费写法。