MCP Registry 指南：查找、验证与发布服务器

什么是 MCP Registry？

MCP Registry 是面向公开 Model Context Protocol 服务器的官方集中式元数据仓库。它统一名称、版本、软件包、远程端点、安装说明和配置数据，并通过 REST API 提供这些元数据。

Registry 解决的是分发问题：客户端需要一种可预测的方式定位 MCP 服务器、判断它是软件包还是远程端点，并了解所需配置。它不能取代 MCP 协议握手、服务器运行时工具列表或你自己的安全审查。

不要把 Registry 当成 MCP 代码的 npm。npm、PyPI、NuGet、Docker Hub 等软件包仓库托管制品；MCP Registry 托管指向这些制品的元数据。远程服务器也可以在同一元数据契约中发布公开的 Streamable HTTP 端点。

官方 Registry 主要作为客户端和下游聚合器的上游来源。下游目录可以增加搜索、排名、使用信号、组织策略或安全扫描。QVeris 可以提供面向任务的能力发现，但仍需检查所选服务器的当前契约和权限。

MCP 服务器目录如何工作

MCP Registry 通过三类契约运行：版本化 server.json 元数据、命名空间与软件包所有权检查，以及供客户端和下游注册表使用的 REST API。发布元数据并不等于批准服务器用于生产环境。

Registry 的角色与生态边界

官方 Registry 是 Model Context Protocol 生态中的开放集中式元数据服务，由多家主要生态贡献者支持，官方说明位于 MCP Registry 官方网站。它的职责有意保持狭窄：认证命名空间、托管标准化元数据并提供 API。制品托管、安装安全与生产批准仍是独立问题。

server.json结构

每个发布版本都使用 server.json 清单标识服务器、版本、软件包或远程端点、传输方式和必要配置。它是分发契约；运行时工具、资源和提示词需要在连接 MCP 服务器后发现。

// server.json - package-backed MCP server
{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "io.github.example/market-data",
  "title": "Market Data",
  "description": "Historical and real-time market data",
  "repository": {
    "url": "https://github.com/example/mcp-market-data",
    "source": "github"
  },
  "version": "1.0.0",
  "packages": [{
    "registryType": "npm",
    "identifier": "@example/mcp-market-data",
    "version": "1.0.0",
    "transport": {
      "type": "stdio"
    },
    "environmentVariables": [{
      "name": "MARKET_DATA_API_KEY",
      "description": "Provider API key",
      "isRequired": true,
      "isSecret": true
    }]
  }],
  "_meta": { "category": "finance" }
}

该清单回答部署问题： 位置 软件包或远程服务器位于哪里， 方式 客户端如何启动或连接，以及 配置 需要哪些环境变量或 URL 变量。工具输入 Schema 不属于发布清单；客户端会从运行中的 MCP 服务器发现它们。

验证、所有权与内容治理

发布流程会验证清单，并检查发布者是否控制声明的命名空间和底层软件包元数据。这并不是人工安全审计。官方治理政策说明，Registry 在更深入的审核方面主要依赖上游软件包仓库和下游注册表。

官方 Registry 可能移除恶意软件、垃圾内容、违法内容或无法运行的服务器，但通常不会仅因质量低、存在缺陷、功能重复或已知漏洞而移除。使用者仍需检查来源、固定版本、审查密钥与权限，并隔离不可信的本地服务器。

如何使用 MCP Registry：发现与发布

Registry 支持两类不同工作流：使用者查询版本化安装元数据，发布者登记公开软件包或远程端点。应把发现、安装、运行时检查和可信评估作为独立步骤。

发现 MCP 服务器

根据你需要源元数据、增强发现还是生产批准，从以下三条路径中选择：

路径一：官方 Registry API

访问 registry.modelcontextprotocol.io 搜索官方来源或调用其 REST API。结果包含名称、版本、软件包或远程位置、代码仓库元数据、传输方式和必要配置，但不能代替实时 MCP 连接来发现当前工具、资源和提示词。

路径 2：社区目录

类似社区目录如 Smithery.ai 和 Glama.ai 可以摄取官方元数据，并增加筛选、排名、评论、策略、安全信号或其他来源。应把每个目录的增强内容视为独立声明，验证新鲜度、来源和治理规则，而不是认为覆盖更广就更安全。

路径三：面向任务的能力发现

当 Agent 从任务而不是服务器名称出发时，可使用 QVeris 等能力发现层识别候选项。调用前检查所选能力的当前契约、提供商、成本信号、密钥和权限。官方 Registry 仍是 MCP 发布元数据的来源：

# Search the official Registry API
curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=market%20data"

# Inspect one server version before installation
curl "https://registry.modelcontextprotocol.io/v0.1/servers/io.github.example%2Fmarket-data/versions/1.0.0"

# Publisher workflow from the server project
mcp-publisher init
# Authenticate the matching namespace
mcp-publisher login github
# Publish the current server.json version
mcp-publisher publish

# Verify the published metadata through the API
curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.example%2Fmarket-data"
# Expected result includes the exact server name
"name": "io.github.example/market-data"
{ ... }

QVeris 与官方 Registry 解决工作流中的不同层。QVeris 可以帮助 Agent 按任务发现能力；Registry 描述已发布 MCP 服务器版本的位置和配置方式。两者都不能取代运行时响应验证和最小权限控制。

如何发布你的 MCP 服务器：分步指南

发布需要公开制品或远程端点、有效的 server.json、所有权证据和已认证命名空间。官方快速入门采用以下四步流程：

官方快速入门没有所谓 1–3 天人工审批队列。认证与验证通过后即可发布；否则会返回软件包验证失败、凭据过期或命名空间权限不匹配等明确错误。

MCP Registry 与子注册表：何时使用哪种

官方 Registry 是上游元数据服务。下游注册表和目录消费该来源，并可增加搜索、治理、安全信号、组织策略或任务级路由。应根据当前决策选择对应层。

架构区别

官方MCP注册表是一个 元数据仓库 ——它保存版本化 server.json 记录，并提供名称、软件包或远程位置、传输方式、代码仓库信息和配置要求。实际制品仍由软件包仓库托管。

像QVeris这样的子注册表是 能力路由层 ——它们可以摄取源元数据、加入自己的证据和策略，并向 Agent 提供任务级接口。其排名、评论、测试和覆盖范围属于下游声明，应独立评估。

可以把它理解为软件供应链的不同层：软件包仓库存储制品，官方 MCP Registry 发布标准化指针和配置契约，下游目录帮助判断服务器是否相关或可接受。

你应该使用哪个？

发布、查询准确源元数据或实现 Registry API 时使用官方 Registry；主要问题是相关性、安全增强、企业策略或动态任务匹配时使用下游层。

许多生产系统同时使用两层：通过官方 API 获取源元数据，由一个或多个下游服务增强，并在安装或执行前经过内部批准。QVeris 可以支持能力发现，但应用仍需负责可信度和运行时控制。

顶级 MCP 服务器目录对比

应按职责比较生态层，而不是比较容易变化的服务器数量。索引更大并不自动意味着更安全、更新或更适合特定 Agent。

这些层相互补充：先发布制品，再发布 MCP 元数据，随后增强或批准记录，最后才允许 Agent 在明确权限与可观测性控制下安装或调用服务器。

我们如何评估这些目录

我们从六个生产维度评估 Registry 工作流。 来源权威性：记录来自官方 API、上游软件包仓库还是其他索引？ 版本完整性：能否固定并复现准确的服务器和制品版本？ 所有权证据：命名空间是否与已认证发布者及软件包元数据一致？ 发现质量：搜索结果是否可解释、保持新鲜并可追溯到源元数据？ 运行时适配：实际服务器是否提供预期工具、传输方式、鉴权和错误行为？ 安全控制：应用能否隔离执行、限制密钥和权限并撤销访问？

本对比依据 2026 年 8 月 3 日核对的官方 Registry 文档。该服务仍处于 Preview，因此 API 行为、Schema 版本、支持的软件包类型和治理规则都可能变化。部署前请验证当前官方契约。

生产环境评估：三个关键问题

投入生产前，需要回答三个问题。第一： 能否验证并复现这个准确版本？ 将 server.json 追溯到软件包或远程端点、代码仓库、发布者命名空间和不可变版本。第二： 服务器将获得哪些权限？ 审查每个密钥、文件系统路径、网络目标、OAuth Scope 和用户确认边界。第三： 服务器失败或变化时会怎样？ 开放 Agent 访问前，测试启动、鉴权、超时、限流、异常响应、并发、回滚和撤销。

Registry 收录只是评估的起点，不是最终批准。内部白名单应记录获批版本、证据、权限、负责人、审查日期和回滚路径。若使用 QVeris 发现能力，应在执行审计记录中保留所选提供商和检查结果。