什么是 MCP 注册表（MCP Registry）？

MCP 注册表（MCP Registry）是 Model Context Protocol 官方规范中定义的、面向可公开访问的 MCP 服务器的集中式元数据仓库（centralized metadata repository）。它让服务器作者在一个统一的地方发布服务器元数据，让 MCP 客户端与聚合器通过 REST API 发现可用服务器，并以标准化的 server.json 格式描述服务器的名称、位置、执行方式与能力。它解决的是「服务器散落在各处、客户端无从发现与正确安装」的问题：注册表本身不存放代码或二进制，只存放指向包仓库或远程地址的元数据。

为什么重要

在注册表出现之前，一个 MCP 服务器要被使用，通常需要使用者自行获知它的存在、找到它的代码位置、弄清启动命令与环境变量。这些信息往往分散在项目 README、聊天消息或第三方目录中，格式各异，客户端难以自动处理。与此同时，包仓库（如 npm、PyPI、Docker Hub）只负责托管代码与二进制，并不描述「这个包是一个 MCP 服务器、应当如何被 MCP 主机启动」。

官方文档把这种分工讲得很清楚：包仓库托管包，MCP 注册表托管指向这些包的元数据。例如一个 weather-mcp 包可以托管在 npm 上，而注册表中的元数据把「weather v1.2.0」这个服务器映射到 npm:weather-mcp。这样，客户端与聚合器不必逐个解析各项目的文档，就能获得统一的发现入口与安装配置信息。

此外，注册表通过 DNS 验证进行命名空间管理（namespace management），使服务器名称（如 io.github.user/server-name）具备可核验的归属，降低名称冒用与混淆的风险。官方文档称该注册表由 MCP 生态中主要的可信贡献者支持，包括 Anthropic、GitHub、PulseMCP 和 Microsoft。

工作机制

按官方规范，注册表的核心做法可以拆成以下几个要点：

元数据集中登记：服务器作者把服务器的元数据发布到注册表这一处，而不是分散维护多个目录条目。
标准化描述格式：元数据以 server.json 格式存储，包含服务器的唯一名称（例如 io.github.user/server-name）、服务器所在位置（例如 npm 包名、远程服务器 URL）、执行说明（例如命令行参数、环境变量），以及其他用于发现的数据（例如描述、服务器能力）。
命名空间管理：通过 DNS 验证确认名称归属，使命名空间与域名控制权挂钩。
REST API 供发现：MCP 客户端与聚合器通过 REST API 获取可用服务器列表与元数据。
OpenAPI 规范复用：除公共 REST API 外，注册表还定义了 OpenAPI 规范，其他 MCP 注册表可以实现该规范，从而为 MCP 主机应用提供标准化接口；私有 MCP 注册表同样可以实现它，以复用已有的主机应用支持。

在生态位置上，注册表被设计为主要由下游聚合器（downstream aggregators）消费，例如 MCP 服务器市场。官方文档强调注册表托管的元数据刻意保持「不做评判」（unopinionated），策展、社区评分等附加信息由下游聚合器自行提供。文档还预期下游聚合器会以规律但不频繁的频率（例如每小时一次）通过 API 拉取新元数据。

典型例子

官方文档给出的具体例子包括：

名称与位置的映射：一个 weather-mcp 包托管在 npm 上，注册表中的元数据把「weather v1.2.0」服务器映射到 npm:weather-mcp。
名称格式：服务器唯一名称采用类似 io.github.user/server-name 的命名空间形式。
私有服务器的反例：仅对少数用户可访问的服务器不被支持，例如发布在私有网络上的服务器（如 mcp.acme-corp.internal），或发布在私有包仓库上的服务器（如通过 npx -y @acme/mcp --registry 指向企业内部 Artifactory 的用法）。官方建议这类场景自行搭建私有 MCP 注册表。
生态参与者：Anthropic、GitHub、PulseMCP、Microsoft 被列为该注册表的可信贡献者。

需要说明的是，官方文档同时标注该注册表当前处于预览（preview）阶段，在正式可用（general availability）之前可能发生破坏性变更或数据重置。

边界与常见误解

它不是包仓库。 注册表不托管代码与二进制，只托管指向 npm、PyPI、Docker Hub 等包仓库的元数据。把注册表当成「MCP 服务器的下载站」是一种常见误解。

它不支持私有服务器。 官方文档明确说明注册表不支持私有服务器，即仅对少数用户可访问的服务器。若需要发布内部服务器，官方建议自建私有 MCP 注册表并把条目加在那里。

它不做策展与评级。 元数据被刻意保持中立，社区评分、人工筛选等由下游聚合器提供。因此「注册表里有的服务器」不等于「经过质量审核的服务器」。

官方代码库并非为自托管设计。 文档指出官方 MCP 注册表的代码库不面向自托管场景，维护者无法为该用途提供支持；如果选择 fork，需要自行维护与运营。

预览阶段的稳定性代价。 在正式可用之前可能出现破坏性变更或数据重置，依赖它的下游系统需要为此留出容错空间。

发布条件有门槛。 服务器开发者可以发布开源或闭源服务器的元数据，但前提是安装方式公开可用（例如公共仓库上的 npm 包或 Docker 镜像），或服务器本身可公开访问（例如不限于私有网络的远程服务器）。

参考资料

Model Context Protocol 官方规范