向智能体添加 MCP 服务器时，你是按名称选择的。名称是你读到的、同事推荐的、安全团队批准的。而智能体实际运行的代码，是这个名称今天所指向的东西。
我们把名称之下的内容发生变化的情况称为 Listing Swap（条目调包） ：官方 MCP 注册表中某个服务器的当前版本，与以同一名称发布的第一个版本相比，指向了不同的远程端点域名，或不同的软件包所有者。
官方 MCP 注册表中有 1,075 个服务器现在指向的域名或软件包所有者与首次发布时不同。其中 698 个的标题和描述完全没有变化。
我们测量了什么
2026年10月10日，我们下载了官方注册表中的全部条目（41,351 个服务器的 142,002 个版本），并将每个服务器的当前版本与以其名称发布的第一个版本进行比较。只有所有者发生变化时我们才计为调包；服务器仅迁移到新路径、新版本或新子域名的情况不计入。
| 指标 | 服务器数 |
|---|---|
| 注册表中的服务器 | 41,351 |
| 有多个版本的服务器 | 17,989 |
| 条目调包 | 1,075 （占有历史版本服务器的 6.0%） |
| 软件包现由其他所有者发布 | 652 |
| 远程端点迁移到其他域名 | 377 |
| 在本地软件包和远程端点之间切换 | 47 |
| 标题和描述不变的调包 | 698 (65%) |
为何重要
我们并不是说这些服务器是恶意的。大多数调包可能很平常：项目更名、迁移托管，或把软件包交给了新的维护者。问题在于，恶意接管看起来完全一样，而目前两种情况都没有人会察觉。
- 注册表检查的是名称，而不是目标。 在某个命名空间下发布，证明你控制该命名空间。但没有任何机制比较版本 2 指向的位置与版本 1 曾指向的位置。
- 客户端信任名称。 从注册表安装时，名称会解析为其最新版本。一次给出的批准，在端点或软件包所有者变更时不会再次征求。
- 条目看起来没有变化。 在三分之二的调包中，标题和描述都没有改变，因此审查条目的人看不到任何新内容。
这比 Invariant Labs 在 2025 年描述的工具定义“rug pull”高出一个层级：在 rug pull 中，服务器会在你批准后修改其工具描述。条目调包则不需要服务器对自身做任何改动：名称现在通向由他人运行的不同代码。
一个无害的示例
设想一个天气服务器 io.example/weather，它通过 @example npm 作用域下的软件包发布。你的团队批准了它。一个月后，版本 1.3 以相同的名称和相同的描述发布，但软件包现在来自另一个人运营的另一个作用域。你的智能体在下次安装时获取了 1.3。客户端不会告诉你代码的发布者已经变更；如果新软件包读取文件或把数据发送到新的地方，它使用的是你授予旧软件包的权限。
应对措施
如果你安装 MCP 服务器
- 固定版本；如果注册表支持，还应固定软件包哈希或镜像摘要。
- 将端点域名或软件包所有者的变更视为一个新服务器，并重新审查。
- 安装前先检查。在接入 Redthread 连接器的 ChatGPT 或 Claude 中询问“检查这个 MCP 服务器是否通过了 Redthread 的扫描”，或使用以下开源工具验证徽章：
atpp verify。 - 检查你已经安装的服务器：
python3 atpp.py check-config会在你的电脑上读取 Claude、Cursor 或 VS Code 配置，并标记任何发生条目调包的服务器（如何)。
如果你发布 MCP 服务器
- 如果你迁移托管或移交软件包，请在条目和代码仓库中说明，让用户有理由信任新的目标。
- 发布软件包哈希并按摘要固定镜像；签名的制品能让用户有据可比。
如果你运营注册表或客户端
- 在名称旁边显示目标，并显示版本之间发生了哪些变化。
- 当服务器的端点域名或软件包所有者发生变化时再次征求确认，就像应用请求新权限时手机会再次询问一样。
这项检查免费
从今天起，Redthread 对注册表的每日扫描新增了 target-stable 检查。每个服务器的签名扫描结果和徽章现在都会显示其条目自首次发布以来是否被调包，统计数字每天在 注册表扫描页面上更新。通过 Redthread 连接器，ChatGPT 和 Claude 中也可以使用同样的检查。
如果你的团队运行会安装第三方 MCP 服务器的智能体，并希望有一个在已批准服务器被调包时发出警报的允许列表， 联系我们。