MCP Registry 來了：官方 MCP 注冊中心架構設計剖析 原創
上周 Anthropic 官方發布了 MCP Registry 注冊中心服務（Github 地址：https://github.com/modelcontextprotocol/registry），已有 4.1K Stars。在 AI 智能體應用快速發展的今天，模型上下文協議（MCP）服務器的生態建設變得愈發重要。MCP Registry 作為連接 MCP 服務器創建者與消費者的關鍵樞紐，其技術架構設計直接影響著整個生態的高效運轉。本文將深入剖析 MCP Registry 的技術架構，從核心組件到部署策略，從數據流轉到生態定位，全面解讀這一 "元注冊中心" 的設計智慧。
下文我們從架構總覽、核心組件、部署架構、數據流轉、生態定位、未來展望等6個方面詳細剖析之。
一、架構總覽：輕量設計承載生態連接
MCP Registry 的核心定位是作為輕量級元數據服務，搭建起 MCP 服務器創建者與消費者（客戶端和聚合器）之間的橋梁。與傳統的包注冊中心不同，MCP Registry 并不托管實際的代碼或二進制文件，而是存儲指向這些資源的元數據，堪稱 "注冊中心的注冊中心"。
這種設計遵循了幾個關鍵原則：
- 最小化運營負擔：通過復用現有服務（比如：GitHub 用于認證）降低維護成本，允許合理的 downtime（24 小時內可接受）；
- 符合行業安全標準：利用 DNS 驗證、OAuth 等機制構建基礎信任層；
- 可復用的擴展接口：API 設計注重通用性，支持私有 / 內部注冊中心的實現；
- 漸進式增強：以 MVP 為起點，構建支持未來功能的基礎架構。
二、核心組件：各司其職的協作體系
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 控制器、監控和備份等基礎設施組件，確保服務的穩定運行。
四、數據流轉：四大核心業務流程
MCP Registry 的核心業務通過四個主要數據流程實現，覆蓋了從服務器發布到客戶端發現的全生命周期：
第一、服務器發布流程
- 開發者使用?
?mcp publish server.json ??命令觸發發布 - CLI 工具驗證 server.json 的有效性
- 完成 GitHub OAuth 流程獲取訪問令牌
- CLI 向 API 發送 POST 請求
- API 驗證令牌并進行 DNS 驗證（如適用）
- 元數據存儲到數據庫
- 返回發布成功確認
第二、消費者發現流程
- 中間服務商（市場 / 聚合器）每日執行 ETL 流程
- 向 CDN 請求 /servers 端點數據
- 若緩存命中，直接返回緩存響應
- 若緩存未命中，CDN 向 API 請求，API 查詢數據庫后返回結果并設置緩存頭
- 中間服務商處理和增強數據，存儲在本地緩存
- 客戶端請求服務器列表時，中間服務商返回經過整理和增強的數據
第三、DNS 驗證流程
- 用戶執行?
?mcp verify-domain example.com ??命令 - CLI 向 API 發送驗證請求
- API 生成驗證令牌并存儲待驗證狀態
- 返回需添加的 TXT 記錄（mcp-verify=abc123）
- 用戶配置 DNS TXT 記錄并確認
- CLI 通知 API 檢查驗證狀態
- API 查詢 DNS 記錄并驗證令牌
- 存儲驗證結果并返回成功信息
第四、管理員 OIDC 認證流程
- 管理員請求獲取管理員令牌
- CLI 通過 gcloud 獲取 Google Cloud Identity 令牌
- 向 API 發送令牌交換請求
- API 驗證令牌簽名和聲明
- 生成并返回注冊 JWT 令牌
- 管理員使用該令牌執行管理操作
五、生態定位：官方注冊中心與子注冊中心的協同
MCP Registry 生態包含兩個關鍵部分：
- MCP 注冊中心規范：定義 API 標準，允許任何人實現注冊中心
- 官方 MCP 注冊中心：遵循規范的托管服務，位于 registry.modelcontextprotocol.io
官方注冊中心作為公共可用服務器的權威元數據來源，由社區維護，注重可發現性和基本元數據。而子注冊中心（比如：Smithery、PulseMCP 等）則通過 ETL 從官方注冊中心獲取數據并添加注解，為特定社區或用例提供增值服務。
這種分層設計讓整個生態既保持了核心元數據的一致性，又能通過子注冊中心實現多樣化的增值服務，形成了靈活而強大的生態系統。
六、未來展望：持續演進的輕量架構
根據 Roadmap，MCP Registry 目前聚焦于 MVP 版本的發布，未來可能添加 UI 實現、擴展存儲數據類型（比如：客戶端、資源）、下載計數跟蹤和國際化等功能。但始終堅持不做的包括源代碼托管、質量排名、內容審核、統一運行時、服務器托管、搜索引擎和主觀排名等，以保持其輕量級元數據服務的核心定位。
通過這種精心設計的技術架構，MCP Registry 成功地在保持簡單性和可靠性的同時，為 MCP 生態系統提供了關鍵的連接能力，成為 AI 應用與各類服務集成的重要基礎設施。
好了，這就是我今天想分享的內容。
本文轉載自???玄姐聊AGI?? 作者：玄姐
