首页上的检查不会在目录里留下痕迹

2026-10-11MCP Checkup

methodology trial

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

（原文写于 2026-09-14；之后有一处变化：自 2026-10-03 起，被检查的地址如果带查询参数，已改为不随检查结果保存这个地址，结果本身和主机名照常保存，同样 30 天后删除。）

我们首页上的那个输入框接收一个 MCP endpoint URL，然后当场对它运行探测器，你稍等就能看到结果。这是了解我们做什么的最快方式。它也是整个产品里「不许做的事」清单最严的一部分，这篇文章就是那份清单。

按下按钮之后发生什么

探测器跑的是和定时检查相同的只读流程：握手、tools/list，以及协议层面的各项观测。你会得到一个私密链接上的结果页。这个页面展示原始观测，并且会过期；确切的过期时间印在页面上，这里不用文字另作承诺。

功能就这么多。本文其余部分讲的是它周围的留白，也就是它不做的那些事。

它不许做什么

它从不创建目录页。 一次试用不会把这个 endpoint 加进公开目录，不会创建 target 记录，也不会往任何目录页赖以生成的历史里写入 run。如果你检查的是我们已经收录的 server，你的试用也不会碰那个 server 的页面。目录页只由定时 run 生成，新的 server 只能经由我们自己的发现流程或维护者的认领进入目录。

它从不签名。 签名证明属于生成目录页的那些定时 run。试用是一次性的观测，不在任何页面的历史里；给它签名，就等于把我们的密钥挂在一个没有任何页面为之负责的观测上。结果页上写着「未签名」，说的就是字面意思。

它完全尊重 opt-out。 如果 endpoint 所在的主机已经发邮件要求我们停止探测（opt-out），对它发起的试用向这台主机发出的请求是零，也不写入任何东西。你看到的是和其他被拒绝的检查一样的「没有可显示的结果」页面，仅此而已。（robots.txt 只在我们自行发现 server 时读取；访客主动要求的检查不受它约束。）

它不携带凭据。 和每一次探测一样。表单上没有填 API key 的地方，因为探测器根本没有地方放它。

它确实会记录什么

说实话，就得把另一半也说出来。结果页上有一句话：这次检查会被记录为追踪请求，而记录下来并不保证这个 server 会被收录。具体来说：我们会保存这次请求、你问的那个 endpoint 和检查结果，存放在与目录分开的表里，由数据库自己按计划定期清除。这些表里的任何东西，没有人的决定，都不可能变成目录页。

为什么要保存？两个原因。一是限流，免得有人把首页变成一项免费服务，拿来探测别人的 server。二是需求：如果很多人问同一个 endpoint，这就说明了目录应该覆盖哪些 server。这个信号我们会看，但它不会自动让谁进入目录。

为什么试用和目录之间的那堵墙是承重墙

如果任何人贴个 URL 就能往目录里加东西，目录很快会塞满拼写错误、预发布环境的 server，以及运营者从没打算公开的 endpoint。更糟的是，一次试用结果，也就是某个时刻的一次未签名观测，会被伪装成一个有历史、有维护者负责的页面。

所以这堵墙是结构性的，不是一条政策：试用这条路径上没有任何写目录表的代码，我们的测试也断言这一点始终成立。除了起步时那份手选的短名单，进入目录只有两条路，每一条都有人为之负责：一是我们自己从公开登记册做的、有边界的发现，在发出第一个请求之前先遵守 robots.txt；二是维护者认领一个他能证明归自己控制的地址。