MCP 注册中心简介

模型上下文协议（MCP）生态系统正在为服务器发现建立一个公共的注册中心。本月早些时候，MCP 团队推出了官方 MCP 注册中心（MCP Registry）的预览版。Linux 基金会接受了Solo.io的Agentgateway项目，并将其纳入其产品组合。他们共同的目标是使工程团队更容易地找到、管理和运行 Agent 工具。

MCP 为 IDE 和 Agent 提供了一种与工具和数据进行通信的标准方式。正如文档中所说，我们可以“将 MCP 想象成 AI 应用的 USB-C 端口”，这捕捉了统一连接器的目标，同时能够最小化客户端的粘合逻辑。注册中心位于该协议之上，它会发布一个机器可读的服务器目录，客户端可以查询和安装。维护者在预览公告中说。“我们正在推出……MCP 注册中心——一个公开可用的 MCP 服务器的开放目录和 API”。

这是我们一直在推进的一项计划，旨在为 MCP 服务器作者提供权威的事实来源和一站式的发布平台。我们的目标是建立多个下游注册中心（敬请期待后续进展），使该平台成为核心事实的来源，取代当前众多临时性注册中心。——Toby Padilla，GitHub MCP负责人

该预览版强调联合发现机制，而非封闭式的列表。团队将官方服务描述为“核心事实源”，公共市场和私有企业子注册库可基于共享的OpenAPI进行镜像和扩展。系统设有审核流程（包括拒绝收录机制），并明确提示预览期内可能存在破坏性变更且不保证数据的持久性。代码与 API 接口均开放共享，参考实现及架构已在 GitHub 发布，并提供托管 API 供客户端集成。

与此同时，Linux基金会的 Agentgateway 项目将自己定位为 Agent 系统的数据处理平面。它是一个 AI 原生的代理，旨在管理 Agent 到 Agent（agent-to-agent）、Agent 到工具和 Agent 到 LLM 的交互，它支持新兴协议，如A2A和 MCP。用基金会的话来说，该项目“为 AI Agent 交互提供了一个集中和安全的管理层”，在通用 API 网关能力受限的领域引入策略管控与可观测性。

我们常低估基础设施中“发现机制”的重要性。API、服务器、扩展程序——它们的存在本身并不足以推动发展，唯有具备可定位性与可信性才能获得推动力。这让我想起 90 年代末互联网早期的网络结构。 ——Taylor Black，微软

对开发者而言，近期实施路径是清晰明了的。MCP 客户端可查询注册中心 API，这可以通过能力或策略筛选，无需手动复制清单即可安装服务器。偏好容器化部署的团队也可采用 Docker 的 MCP 打包与注册方案，降低工作站之间差异性。同时，Agentgateway 提供了统一入口，平台团队可在此实施跨异构 Agent 框架的身份验证/授权、速率限制及请求检测，并通过 OpenTelemetry 输出遥测数据。

注册中心存在显著的权衡取舍。集中式发现机制引发了关于公共与私有子注册中心之间内容管理、治理机制及模式漂移的质疑。在预览阶段，MCP 注册中心明确不提供持久性保证且可能包含破坏性变更，因此客户端代码应采取防御性编程策略。MCP路线图将该注册中心定位为第三方市场可将其作为基础的 API 基座，这意味着需要更严格的版本保证、更丰富的元数据以及用于溯源和策略的标准化钩子。

Agentgateway 同样处于基金会生命周期的早期阶段；运维人员需要在实际环境中验证其性能、协议覆盖率以及基于角色的访问控制（RBAC）和审计功能的成熟度，方可将其用于广泛环境的策略执行。在网关层面，基金会强调与社区规范（A2A、MCP）的兼容性，并致力于构建中立且供应商无关治理机制；随着更多贡献者加入，集成与生产环境强化进程将加速推进。

基金会宣称：“Agentgateway 是首个专为 AI Agent 从零构建的数据平面”；结合 MCP 的“开放目录与 API”，两个项目共同勾勒出安全扩展的蓝图。开发者可通过MCP注册中心与agentgateway的代码库进行深入了解。

原文链接：

Introducing the MCP Registry