认领 MCP server 页面：我们核验的是地址，不是记录

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

被认领的页面带着签名证明，并且代表一位真实的维护者说话。这让「谁有权认领这个页面？」成了整个产品里后果最重的设计决定。这篇文章讲我们的答案，以及一路上否掉的几个错误答案。

认领锚定在什么上

MCP Checkup 上的一个页面描述的是一个 endpoint URL。认领它，就是声明你控制着这个 endpoint。所以证明必须是只有这台主机的运营者才拿得出来的东西。我们接受两种：

• well-known 文件。 我们给你一个 token；你把它放在 endpoint 自己的主机上的一个固定路径下。我们通过 HTTPS 从这台主机取回它，再做比对。
• DNS TXT 记录。 你把同一个 token 发布在一条 TXT 记录里，记录名是用 endpoint 的主机名拼出来的固定名字。我们解析它，再做比对。

两种证明核对的都是取自我们所探测的 endpoint URL 的主机，从不取自你在认领表单里填的任何内容。如果页面说这台 server 在 mcp.example.com，文件就必须在 mcp.example.com 上，TXT 记录的名字就必须是 _mcp-checkup-claim.mcp.example.com。没有任何一个字段能让你把我们指到别处去。

我们否掉的错误答案

还有第三种证明很容易想到：把 token 放在 server 源码仓库的根目录。这读起来很自然，好几个软件包登记处也是这么做的，但对我们来说是错的。

仓库里的 token 证明的是「我控制着一个仓库」，证明不了「我控制着这个页面讲的那个 endpoint」。任何人都可以把我们的表单指向任意一台 server，填上一个自己的仓库，把 token 放进去，然后就拥有了一个讲别人 endpoint 的页面。证明和被认领的东西脱了钩。我们不接受它；我们只接受上面那两种证明，因为不掌控那台主机，两种都做不出来。

为什么认领不能在记录之间转移

有时维护者还没出现，我们就已经有了那个 endpoint 的页面。有时维护者带来一个我们从没见过的地址。/zh/claim/new 上的认领流程两种情况都能处理，但有一条规则：认领只针对你证明过其地址的那一条记录，别的都不行。

• 如果我们已经收录了这个 endpoint，你会被带到那个现有页面，去证明你控制它的主机。你不能换个好听的名字另建一个重复的。
• 如果我们没有收录，由你给它命名，我们创建一条临时记录，证明成功之前只有你看得到。如果你一直没完成，这条记录会在 30 天后删除，自始至终没有公开过任何东西。
• 一个地址的证明不能拿去用在另一个地址上。不同的主机，不同的 token，不同的记录。

这也解决了「改名」问题。已认领页面的名字和 provider slug 是别人会链接的 URL 的一部分，所以维护者没办法靠编辑记录，把一个被大量链接的页面悄悄改指到另一台 server 上。地址就是身份，其余都只是标签。

认领不会要什么

不要任何与你 server 凭据有关的东西。我们从不索要 API key、bearer token 或管理员登录，因为探测器从不使用任何凭据。核验是一次单向的确认：我们生成的一个值，出现在了只有你才能放进去的地方。在那之后，探测器继续发送完全一样的请求：匿名的只读方法，按你在页面上能看到的周期发送。

认领改变什么

页面被认领后，检查周期会按你所在的档位变密，告警邮件也会发给你。观测本身不变，签名也不变：无论页面有没有被认领，run 都会签名。改变的是，有人为这个 endpoint 承担了责任，页面也不再把它称为未认领。