MCP Registry 发布:面向所有人的开放服务器目录
2025 年 9 月 8 日,MCP 团队以预览(preview)形式推出官方注册中心——一个用于发现「公开可用 MCP 服务器」的开放目录与 API,目标是让服务器更易被发现、被接入。
发布预览:这是什么
今天,MCP 团队正式发布 Model Context Protocol (MCP) Registry——一个面向「公开可用的 MCP 服务器」的开放目录(catalog)与 API,用来改善发现性(discoverability)与接入实现(implementation)。
它的核心逻辑是:通过标准化「服务器如何被分发、如何被发现」,在扩大服务器触达范围的同时,让客户端(client)更容易完成连接。这个注册中心目前以预览(preview)形式提供。
🧩 先补个底:MCP / 服务器 / 客户端 是什么关系
(此卡为帮助理解的背景增补,非原文内容;原文默认读者已了解 MCP 基本概念。)
是什么MCP(模型上下文协议)是一套让 AI 应用与外部工具、数据源连接的开放协议。其中服务器(server)是「提供能力的一方」(比如能查数据库、调 API、读文件的那个程序);客户端(client)是「使用这些能力的一方」(比如某个 AI 助手应用)。
为什么需要一个注册中心在此之前,客户端要接入一个服务器,往往得各自去找、各自记录服务器在哪、怎么连。服务器作者也缺一个统一的地方对外公布自己。注册中心就是来解决这个「找不到、对不上」的问题——做一个公开的「电话簿」。
例子类比应用商店之于 App:开发者把 App 上架到一个中心目录,用户在一个地方就能搜索、发现并安装,而不必满世界找安装包。注册中心想为 MCP 服务器扮演类似的「集中登记 + 可被发现」的角色。
开始使用的两条入口,在原文里出现了两次(开头与「如何开始」一节),对应两类不同的人:
- 面向服务器维护者
- 按官方指南《Adding Servers to the MCP Registry》操作
- 面向客户端维护者
- 按官方指南《Accessing MCP Registry Data》操作
单一可信源:为整个生态打地基
这一节交代了项目的来龙去脉与定位。原文给出两个明确的时间点与事实:
2025 年 3 月:公开了设想
团队表示,希望为 MCP 生态构建一个中心化的注册中心(central registry)。
今天:正式上线
宣布 https://registry.modelcontextprotocol.io 作为官方 MCP Registry 上线。
一个关键设计:它是开源的。作为 MCP 项目的一部分,MCP Registry 本身,以及一份父级 OpenAPI 规范(parent OpenAPI specification),都是开源的——这样任何人都可以基于它构建一个兼容的「子注册中心(sub-registry)」。
🗂️ 核心概念:Single source of truth(单一可信源)
是什么原文明确目标:标准化服务器如何被分发与发现,提供一个「主要的可信源(primary source of truth)」,让各个子注册中心可以在其之上构建。
为什么这样设计有了一个公认的「源头数据」,下游各方就不必各自维护一份可能互相矛盾的服务器清单。原文指出,这样做的回报是:扩大服务器的触达范围,并帮助客户端在整个 MCP 生态里更容易地找到服务器。
例子就像一个权威的「行业总名录」:各家做的细分黄页都从这本总名录抄录基础信息,再各自加工。源头只有一处,改一次,下游都能跟着同步。
公有与私有子注册中心
在构建一个中心注册中心时,团队强调了一个重要立场:不要削弱社区和公司们已经建好的现有注册中心。MCP Registry 作为「公开可用 MCP 服务器」的主要可信源,而各组织可以基于自定义标准创建子注册中心。原文给了两类例子:
- 比如与各个 MCP 客户端绑定的、有自己取向的「MCP 市场(marketplaces)」。
- 它们可以自由地增补、增强从上游 MCP Registry 摄取(ingest)来的数据。
- 原文判断:每一类 MCP 终端用户的需求都不同,由各 MCP 客户端市场以「有取向的方式」恰当地服务自己的终端用户。
- 存在于有严格隐私与安全要求的企业内部。
- MCP Registry 为这些企业提供一个统一的上游数据源可供构建。
- 原文给的最低目标:至少共享 API schema,以便相关 SDK 与工具能在整个生态中复用。
可以把官方 Registry 想成一个总批发市场:所有货(服务器信息)先在这里登记上架。公有子注册中心像开在各处、风格各异的精品零售店——它们从批发市场进货,再按自己客群的口味重新陈列、加上推荐与点评。私有子注册中心则像企业自建的内部仓库:同样从这个批发市场拿货源,但只在公司围墙内流通,满足严格的隐私与安全要求。货的源头是同一个,加工与交付各不相同。
💬 没看懂「自报信息 / 下游去 massage」?点这里换种说法
社区驱动的审核机制
原文用一段说明了治理与审核方式。先交代身份与许可:MCP Registry 是一个官方 MCP 项目,由「注册中心工作组(registry working group)」维护,并采用宽松许可(permissively licensed)。
审核流程是社区驱动的,可以拆成清晰的几步:
社区成员提交 issue 标记
任何社区成员都可以提交 issue,来标记(flag)那些违反 MCP 审核指南(moderation guidelines)的服务器。
哪些算违规
原文举的例子:含有垃圾信息(spam)、恶意代码(malicious code),或冒充合法服务(impersonating legitimate services)的条目。
维护者拉黑并回溯移除
注册中心维护者随后可以将这些条目加入拒绝名单(denylist),并追溯性地(retroactively)把它们从公开访问中移除。
如何开始使用
「如何开始」这一节给出与开头相同的两条入口,按角色区分:
原文还邀请大家参与:在 MCP 持续开发注册中心的过程中,鼓励在 modelcontextprotocol/registry GitHub 仓库 上提供反馈与贡献——讨论(Discussion)、问题(Issues)、合并请求(Pull Requests)都欢迎。
预览阶段的重要提醒
这一段是容易被读者略过、但很关键的限定条件,原文说得很明确:
🔍 为什么这段提醒很重要
(以下为帮助理解的解释性增补,基于「预览版软件」的公认常识。)
是什么预览版意味着功能已可试用,但接口和行为尚未定型。「不保证数据持久性」指你今天放进去的数据,不承诺一直稳妥保留;「破坏性变更」指未来某次更新可能让你之前依赖的用法失效。
为什么要事先说清这是负责任地划定预期:让早期使用者知道这是「可以玩、可以反馈,但先别压上关键生产依赖」的阶段,避免日后接口一变就措手不及。
致谢:社区的共同成果
原文最后用整整一节,详尽地回顾了这个项目「从零到一」的协作历程,并逐一点名致谢。这部分信息密度很高,逐项保留如下。
总基调:MCP Registry 从一开始就是一项协作努力,团队对来自更广泛开发者社区的热情与支持深表感激。
🌱 起源:2025 年 2 月的草根项目
怎么开始的2025 年 2 月,它作为一个草根(grassroots)项目起步:MCP 的创造者 David Soria Parra 与 Justin Spahr-Summers 邀请 PulseMCP 和 Goose 团队,帮忙构建一个中心化的社区注册中心。
最初的推动者来自 PulseMCP 的注册中心维护者 Tadas Antanavicius 牵头了最初的工作,并与来自 Block 的 Alex Hancock 协作。
随后陆续有人加入这条主线:
Toby Padilla 加入
注册中心维护者 Toby Padilla,GitHub 的 Head of MCP,加入团队。
Adam Jones 加入,推动发布
更近期,来自 Anthropic 的 Adam Jones 作为注册中心维护者加入,推动项目走向今天的发布。
原文还专门点名了「许多为让项目落地做出关键贡献」的其他人,逐一保留如下:
此外,原文还感谢了许多提供代码审查与开发支持的 Anthropic 与 GitHub 员工,以及注册中心贡献者日志(contributors log)上的每一位,和所有参与讨论与 issues 的人。
🏁 结尾原话所传递的态度
团队表示:深深感激每一位投入这项基础性开源基础设施(foundational open source infrastructure)的人。原文写道——共同努力,正在帮助全世界的开发者与组织构建更可靠、更具上下文感知能力的 AI 应用。
并以社区的名义致谢:「On behalf of the MCP community, thank you.」