摘要

  • Charleston Road Registry 提议用四种 MCP 参与关系，决定谁有资格注册 .mcp 域名。
  • .MCP Policy Council 将对规则修改拥有同意权，但公开申请没有说明委员会如何产生、如何问责或如何受申诉约束。

协议和域名属于不同的制度层。Model Context Protocol 是开放的技术项目；若 .mcp 最终获批，它则是由注册局按合同管理的域名空间。二者可以彼此服务，却不能互相替代：参与协议开发，不自然等于获得在某个后缀下注册名称的资格。

Charleston Road Registry Inc.（CRR）是 Google Registry 的申请实体。它提出四种准入路径：能证明曾为 MCP 官方代码库作出贡献；运营活跃且符合要求的 MCP 服务器；拥有或代表官方 MCP Registry 中的登记项；或者是 Agentic AI Foundation（AAIF）的有效成员。申请称，注册局将核验这些条件，并由 .MCP Policy Council 协助执行。对问题 151 的答复还写明，政策只能在该委员会同意后修改。

四种条件衡量的并非同一种关系。代码贡献是可查的历史记录，服务器运营是当前技术活动，Registry 登记涉及代表资格，AAIF 会籍则是机构关系。刚进入生态的开发者、长期维护者、服务运营商和组织成员，能够提供的证明和遭遇的争议各不相同。申请列出了类别，却没有公开每类的证明阈值、证据过期处理方式、误拒后的救济路径。

规则由谁维护，问题更大。.MCP Policy Council 不只会帮助注册局执行条件；申请还把规则修改的同意权交给它。公开答复没有说明委员由谁任命或罢免、任期多久、如何处理利益冲突、被拒申请者能否申诉，也没有交代它与 MCP 技术治理机构的正式关系。这些信息缺失并不能证明委员会会被俘获或存在不当动机，但它让一个可能长期影响域名准入的权力中心缺少可核验的边界。

MCP 项目自己的公开治理记录呈现的是另一套结构。官方页面列出 Steering Group，以及 Lead、Core、Maintainer 等角色；页面称技术治理由个人承担，不设公司席位。它没有提到 .MCP Policy Council。因此，不能把申请中的委员会直接说成 MCP 技术领导层，也不能推定协议项目的决定自动约束域名注册局。注册局可以按合同管理它所发行的名称，但这不等于它能决定谁可以贡献代码、哪些实现符合协议，或协议如何演进。

ICANN 的程序也要分层看。10 月 7 日的 Reveal Day 文件把五个申请列入 .mcp 初步争用组：CRR、OPENAI OPCO、Radix、ShortDot 和 Tidal Case。五份公开摘要都显示 Active / Pre-Evaluation Processing。只有 CRR 的公开 tldTypes 字段显示 Community；另外四份为空，不能据此断定对方没有社区申请理由。ICANN 表示，在字符串评估完成之前，APS 不会把争用组视为最终结果。

如果 CRR 保留社区申请身份并选择参加后续 Community Priority Evaluation（CPE），评估结果可能影响该组中的优先顺序。现行申请人指南把 CPE 定义为独立专家对社区申请进行的优先权评估；相关评估、异议和申诉步骤需先满足，拟议的 Registry Commitments 也要经过单独审查。通过的社区申请可以优先于非社区申请；若多个社区申请都通过，则进入拍卖。CPE 采用四项标准，总分 16 分，门槛为 12 分。指南还特别区分了两件事：社区由申请者自我界定，CPE 判断的是申请是否应获得争用优先权，而非 MCP 是否存在一个社区。CPE 不是对 MCP 技术机构合法性的公投。

Heng Lu 的第 72 条笔记可以帮助提出治理问题，却不能直接当作域名注册局的规则。笔记提醒读者：邮件列表、会议或政策共识本身不会自动产生所有权授权。它讨论的是区域互联网注册机构对号码资源的权限；通用顶级域名注册局受另一类合同约束，也确实需要管理注册。这里更准确的问题是：资格条件是否清晰有限、决定是否可解释和可申诉、参与者能否知道谁有权改规则。

.mcp 尚未获授权，申请提出的政策也还没有获得批准。但公开材料已经足以说明需要分别尽调的事项：协议参与不等同于域名资格；核验机制需要配套申诉；委员会修改规则的权力需要透明；域名注册决定不能被包装成 MCP 项目的技术背书。如果申请继续推进，委员会章程的重要性不会低于四类资格本身。

来源