竞品对比与选型
MCP Registry 平台对比
选择 MCP registries ，依据是目录覆盖、服务可信度与可执行工具契约。
Decision brief
概要
它统一公开 Server 的身份、版本、包、Transport 与安装信息，保持中立，主要供下游聚合器消费。
Smithery 把搜索、发布与连接生命周期、OAuth、凭证存储、作用域 Token、CLI 和运行时调用结合起来。
Glama 在 Registry 元数据之上补充构建、实际探测、行为观察、质量评分、数据新鲜度以及 Schema/行为变更历史。
QVeris 不是官方 MCP 元数据注册表，而是通过 Discover、Inspect、Probe、Call、用量审计和积分账本组织可调用能力。
这份 MCP Registry 对比适合谁
这份指南适合选择 MCP Server 发现渠道的开发者、建设内部目录的平台团队、选择分发渠道的 Server 作者，以及决定 Server 进入生产前需要哪些证据的安全团队。
Registry、Directory、Marketplace 与 Runtime 的区别
多数错误对比都源于把不同工作混为一谈：Registry 是机器可读元数据系统；Directory 提供人工浏览；Marketplace 增加分发或商业流程；托管连接层处理凭证与会话；运行时能力层帮助 Agent 检查并执行工具。
| 层级 | 核心问题 | 典型输出 | 不能证明 |
|---|---|---|---|
| Registry | 有哪些公开 Server 与版本？ | 结构化 Server 元数据 | 运行时安全 |
| Directory | 用户能浏览哪些内容？ | 搜索结果与详情页 | 可机器执行的安装 |
| Marketplace | Server 如何分发或连接？ | 发布、安装、OAuth、托管 | 是否适合你的业务 |
| Runtime layer | Agent 现在应该调用哪个能力？ | Schema、执行结果与证据 | 所有上游来源都可信 |
Official MCP Registry、Smithery、Glama 与 QVeris 对比
| 能力 | Official Registry | Smithery | Glama | QVeris |
|---|---|---|---|---|
| 主要角色 | 官方公开元数据 | 发现、发布、连接 | 增强 Registry 与分析 | 能力发现与执行 |
| 搜索/API | 只读 REST API | 全文/语义搜索与 API | 公开增强 Registry API | 自然语言能力发现 |
| 发布者身份 | Namespace 所有权验证 | 发布者与列表元数据 | 维护者验证加分析 | 能力目录中的供应商/工具身份 |
| 代码/行为分析 | 交由下游 | 连接与使用工具 | 构建、探测、观察、评分、漂移记录 | 检查参数、示例、统计；调用前 Probe |
| OAuth / credentials | 不提供托管连接层 | 托管 OAuth、凭证与作用域 Token | 取决于 Connector/Runtime 路径 | QVeris Key 与服务商执行边界 |
| 运行时调用 | 否 | 是，通过托管连接 | 取决于 Connector | 是，发现/检查后通过 Call 执行 |
| 适合场景 | 聚合器与公开元数据同步 | 连接和运行 MCP 集成 | 比较质量并监控变化 | 把 Agent 任务路由到可调用能力 |
重要：某一层通过检查不能替代其他层。元数据真实性、代码扫描、权限审查、连接成功和安全运行行为，是彼此独立的控制项。
四个平台的真实边界
官方 Registry 目前仍处于 Preview。它接收公开 Server 元数据、验证 Namespace 所有权、统一 server.json，并提供只读 REST API；它不托管软件包、不支持私有 Server，也不宣称扫描所有 Server 代码。
Smithery 支持 Server 搜索、发布、CLI 安装、托管连接、OAuth 状态、只写凭证存储、作用域 Service Token、工具列表和工具调用，适合连接运维与发现同样重要的场景。
Glama 将自己定位为官方 Registry 的超集，其方法增加 Schema 捕获、工具质量评分、沙箱或定期行为观察、变更历史与最近扫描时间。
QVeris 提供六个标准 MCP 工具：Discover、Inspect、Probe、Call、Usage History 和 Credits Ledger，帮助 Agent 从意图走向已检查、已报价、已执行且可审计的能力，但不替代官方 Registry 元数据标准。
生产流程：先发现和验证，再连接
Registry 结果只是候选项，不是批准结论。在把工具暴露给 Agent 前，每个 Server 都应通过同一套门控流程。
按任务、Transport、语言、包类型、部署方式和鉴权要求搜索，并保存原始列表 URL 与 Registry 来源。
核对 Namespace、代码仓库、Release Tag、软件包发布者、远程 Endpoint 域名、许可证和维护活跃度。
在隔离环境连接并记录 tools/list，把名称、描述、输入 Schema、Annotation 和权限与 Registry 列表逐项比较。
覆盖非法参数、超大输出、超时、鉴权过期、工具结果中的 Prompt Injection、重复调用和越权资源访问。
固定版本或不可变 Artifact，维护 Allowlist，保存 Schema Hash，并在软件包、Endpoint、工具列表、权限或行为变化时告警。
Registry 与连接实操示例
API 适合资产清单和同步；运行时验证应使用客户端或托管连接层。不要把刚发现的 Server 直接放入高权限生产环境执行。
curl "https://registry.modelcontextprotocol.io/v0.1/servers?limit=100"curl "https://registry.modelcontextprotocol.io/v0.1/servers?updated_since=2026-07-01T00:00:00.000Z"smithery mcp search "github issues"
smithery mcp add github --id team-github
smithery tool list team-github
smithery tool call team-github search_repositories '{"query":"mcp"}'qveris discover "SEC filing retrieval with source URLs"
qveris inspect 1
qveris probe 1 --params '{"ticker":"NVDA","form_type":"10-K"}'
qveris call 1 --params '{"ticker":"NVDA","form_type":"10-K"}'信任 MCP Server 前应该验证什么
安全：Registry 验证不等于运行时可信
官方 Registry 验证发布者是否控制 Namespace，并明确把代码扫描交给软件包 Registry 与下游聚合器。这是有价值的身份依据，但不能证明代码没有漏洞、权限合理、远程 Endpoint 未改变，或每条工具结果都能安全交给 LLM。
- 用隔离用户、容器或沙箱运行不可信本地 Server，并把文件系统和网络权限降到最低。
- 按 Server、环境、用户和租户分离凭证，避免共享高权限 Token。
- 不要把工具描述当作安全策略；授权必须在模型外强制执行。
- 把工具输出视为不可信内容并保留来源边界，降低间接 Prompt Injection 风险。
- 破坏性、金融、管理或对外可见动作必须要求人工批准。
- 版本、Endpoint、依赖、Schema 或权限变化后重新验证。
常见 MCP Registry 失败模式
| 现象 | 根因 | 生产修复 |
|---|---|---|
| 有列表但安装失败 | 软件包过期、Runtime 缺失、Transport 不支持 | 解析精确 Artifact 并在 CI 测试安装 |
| 能看到工具但调用失败 | 配置缺失、OAuth 过期、Scope 错误、Schema 漂移 | 管理连接状态并在真实调用前 Probe |
| “已验证” Server 执行危险动作 | 把所有权验证误当成授权 | 使用 Allowlist、最小权限、策略和审批 |
| 找不到私有 Server | 官方公开 Registry 不支持私有 Server | 建设私有 Registry 或内部覆盖层 |
| Agent Context 过大 | 一次注入所有候选工具 Schema | 按意图搜索、缩小候选、检查后只暴露选中工具 |
应该选择哪个 MCP 平台？
从 Official MCP Registry REST API 开始，持久化数据，处理游标分页和状态变化，再增加自己的增强数据。
如果 OAuth、凭证存储、Namespace、Service Token、CLI 配置和运行时调用是重点，评估 Smithery。
如果 Schema 捕获、行为观察、工具质量评分和历史漂移很重要，评估 Glama。
如果 Agent 需要按意图发现、检查候选、Probe 参数和报价、执行调用并审计用量与结算，评估 QVeris。
建设或采购带 Allowlist、审批状态、Schema Hash、Owner、证据、环境和过期时间的私有覆盖层。
组合多层：官方元数据同步、增强发现、私有审批、隔离运行时与集中审计。
迁移与采用清单
- 盘点每个 Server、版本、软件包、Transport、Endpoint、工具、Owner 和凭证。
- 把发现元数据、审批状态和运行时连接状态分开存储。
- 把平台私有字段映射到统一 Server 记录，并保留原始元数据用于审计。
- 迁移流量前重新运行
tools/list并比较 Schema Hash。 - 先迁移只读、低风险工具；写操作和高权限工具继续要求明确审批。
- 先对小用户群灰度，测量连接成功率、调用成功率、延迟、错误类型和 Schema 漂移。
- 保留回滚说明和旧连接，直到审计证据确认新路径稳定。
QVeris 实现模式：Discover → Inspect → Probe → Call
在用户意图已经明确、最终能力尚未执行时使用 QVeris：Discover 返回候选；Inspect 查看参数、示例以及可用的成功率、延迟和价格信息；Probe 在不执行的情况下校验参数和报价；Call 执行选定能力；Usage History 与 Credits Ledger 提供运维和结算追踪。
边界：Registry 证据与 Runtime 证据应分开。发现结果解释为什么选择该候选项；执行记录解释实际运行了什么、何时运行、输入是什么以及返回了什么。
继续阅读 MCP Registry 指南、MCP Server Directory 指南、MCP 工具发现指南或 QVeris MCP 文档。
FAQ
它是公开 MCP Server 的官方集中式元数据仓库，提供标准元数据与只读发现 API。
不一样。Registry 提供结构化元数据和 API；Directory 侧重人工浏览；Marketplace 与连接平台还会增加运维能力。
不会。它验证 Namespace 并托管元数据；代码或安全扫描由软件包 Registry 和下游聚合器补充。
Smithery 更重视发现、发布、连接、OAuth、凭证和调用；Glama 更重视增强、探测、行为、评分和变更历史。
不代表。发布者身份、代码安全、权限合理性和运行时行为是不同的证明。
可以。常见架构组合官方元数据、增强型下游来源与私有生产 Allowlist。
QVeris 是包含 Discover、Inspect、Probe、Call、用量审计和积分账本的能力路由层，不是官方元数据 Registry。
根据实际任务选择：元数据同步、人工发现、托管鉴权、Server 分析、私有治理或运行时能力路由。