Anthropic 官方发布了 MCP Registry 注册中心服务（Github 地址：https://github.com/modelcontextprotocol/registry），已有 4.1K Stars。在 AI 智能体应用快速发展的今天，模型上下文协议（MCP）服务器的生态建设变得愈发重要。MCP Registry 作为连接 MCP 服务器创建者与消费者的关键枢纽，其技术架构设计直接影响着整个生态的高效运转。本文将深入剖析 MCP Registry 的技术架构，从核心组件到部署策略，从数据流转到生态定位，全面解读这一 "元注册中心" 的设计智慧。

下文我们从架构总览、核心组件、部署架构、数据流转、生态定位、未来展望等6个方面详细剖析之。

—1—

架构总览：轻量设计承载生态连接

MCP Registry 的核心定位是作为轻量级元数据服务，搭建起 MCP 服务器创建者与消费者（客户端和聚合器）之间的桥梁。与传统的包注册中心不同，MCP Registry 并不托管实际的代码或二进制文件，而是存储指向这些资源的元数据，堪称 "注册中心的注册中心"。

这种设计遵循了几个关键原则：

• 最小化运营负担

  ：通过复用现有服务（比如：GitHub 用于认证）降低维护成本，允许合理的 downtime（24 小时内可接受）；

• 符合行业安全标准

  ：利用 DNS 验证、OAuth 等机制构建基础信任层；

• 可复用的扩展接口

  ：API 设计注重通用性，支持私有 / 内部注册中心的实现；

• 渐进式增强

  ：以 MVP 为起点，构建支持未来功能的基础架构。

—2—

核心组件：各司其职的协作体系

MCP Registry 的架构由四个核心组件构成，它们协同工作支撑起整个服务的功能实现：

1. REST API（Go 实现）

作为主要的应用服务器，提供了完整的接口能力：

• 公开的读取端点，支持服务器发现

• 需认证的写入端点，用于服务器发布

• GitHub OAuth 集成（可扩展至其他认证提供商）

• 可选的 DNS 验证系统，用于自定义命名空间

2. 数据库（PostgreSQL）

作为主要数据存储，负责维护：

• 带版本的服务器元数据（server.json 内容）

• 用户认证状态

• DNS 验证记录

3. CLI 工具

为开发者提供便捷的操作界面：

• 服务器发布工作流

• GitHub OAuth 流程处理

• DNS 验证功能

4. CDN 层

对系统可扩展性至关重要：

• 缓存所有公开读取端点的内容

• 减轻源服务器负载

• 支持全球分发

• 针对每日消费者轮询模式优化

—3—

部署架构：基于 Kubernetes 的可靠运行环境

MCP Registry 采用 Kubernetes 部署架构，通过 Helm 图表实现容器化管理，确保服务的可靠性和可扩展性。其部署架构包含以下关键部分：

• 负载均衡器

  ：处理外部流量，监听 80 端口

• 注册服务

  ：运行在 8080 端口，管理多个注册 Pod

• 数据库服务

  ：基于 StatefulSet 部署的 PostgreSQL，使用持久卷存储数据

• 密钥管理

  ：存储 GitHub OAuth 等敏感信息

整个部署流程通过 Pulumi 实现自动化，支持 GCP 和本地环境，包含证书管理、 ingress 控制器、监控和备份等基础设施组件，确保服务的稳定运行。

—4—

数据流转：四大核心业务流程

MCP Registry 的核心业务通过四个主要数据流程实现，覆盖了从服务器发布到客户端发现的全生命周期：

第一、服务器发布流程

1. 开发者使用 mcp publish server.json 命令触发发布

2. CLI 工具验证 server.json 的有效性

3. 完成 GitHub OAuth 流程获取访问令牌

4. CLI 向 API 发送 POST 请求

5. API 验证令牌并进行 DNS 验证（如适用）

6. 元数据存储到数据库

7. 返回发布成功确认

第二、消费者发现流程

1. 中间服务商（市场 / 聚合器）每日执行 ETL 流程

2. 向 CDN 请求 /servers 端点数据

3. 若缓存命中，直接返回缓存响应

4. 若缓存未命中，CDN 向 API 请求，API 查询数据库后返回结果并设置缓存头

5. 中间服务商处理和增强数据，存储在本地缓存

6. 客户端请求服务器列表时，中间服务商返回经过整理和增强的数据

5. DNS 验证流程

1. 用户执行 mcp verify-domain example.com 命令

2. CLI 向 API 发送验证请求

3. API 生成验证令牌并存储待验证状态

4. 返回需添加的 TXT 记录（mcp-verify=abc123）

5. 用户配置 DNS TXT 记录并确认

6. CLI 通知 API 检查验证状态

7. API 查询 DNS 记录并验证令牌

8. 存储验证结果并返回成功信息

6.管理员 OIDC 认证流程

1. 管理员请求获取管理员令牌

2. CLI 通过 gcloud 获取 Google Cloud Identity 令牌

3. 向 API 发送令牌交换请求

4. API 验证令牌签名和声明

5. 生成并返回注册 JWT 令牌

6. 管理员使用该令牌执行管理操作

—5—

生态定位：官方注册中心与子注册中心的协同

MCP Registry 生态包含两个关键部分：

• MCP 注册中心规范

  ：定义 API 标准，允许任何人实现注册中心

• 官方 MCP 注册中心

  ：遵循规范的托管服务，位于 registry.modelcontextprotocol.io

官方注册中心作为公共可用服务器的权威元数据来源，由社区维护，注重可发现性和基本元数据。而子注册中心（比如：Smithery、PulseMCP 等）则通过 ETL 从官方注册中心获取数据并添加注解，为特定社区或用例提供增值服务。

这种分层设计让整个生态既保持了核心元数据的一致性，又能通过子注册中心实现多样化的增值服务，形成了灵活而强大的生态系统。

—6—

未来展望：持续演进的轻量架构

根据 Roadmap，MCP Registry 目前聚焦于 MVP 版本的发布，未来可能添加 UI 实现、扩展存储数据类型（比如：客户端、资源）、下载计数跟踪和国际化等功能。但始终坚持不做的包括源代码托管、质量排名、内容审核、统一运行时、服务器托管、搜索引擎和主观排名等，以保持其轻量级元数据服务的核心定位。

通过这种精心设计的技术架构，MCP Registry 成功地在保持简单性和可靠性的同时，为 MCP 生态系统提供了关键的连接能力，成为 AI 应用与各类服务集成的重要基础设施。