MCP Registry 治理：发现、来源与安全安装

核心结论

MCP Registry 解决的是发现问题，不会自动解决信任、授权、Package 安全、Tenant、计费或运营问题。

Official MCP Registry 当前仍处于 Preview：在 GA 前可能发生破坏性变更或数据重置，也不承诺 Uptime 与 Data Durability。其公共读取 API 当前提供 GET /v0.1/servers 等 v0.1 Endpoint。集成方应把这些事实视为带版本的接口，而不是永久保证。

Registry 条目
      |
      v
审核来源 + 固定 Artifact 或 Endpoint
      |
      v
隔离安装 + Runtime Policy
      |
      v
已认证 Tool 调用 + 对象授权

“官方”不是安全属性。每次安装都应记录 Registry 实现、Schema 版本、来源 URL、Artifact Digest 或 Endpoint Owner、审核结论，以及将元数据转化为安装的 Runtime Policy。

Registry、Catalog 与 Package Repository

这些词代表不同层次：

Official MCP Registry 是 registry.modelcontextprotocol.io 上的公共服务；MCP Registry API 是第三方 Registry 或 Subregistry 可以实现的 OpenAPI 契约。Marketplace 或企业 Catalog 可以同步官方 Feed，增加 Rating 或 Policy Metadata，再暴露兼容 API，但它仍是独立信任域。不要把每个 GitHub 列表、Marketplace 或 Package Index 都称为“GitHub MCP Registry”。

Manifest 应描述什么

使用目标 Registry 要求的准确 Schema。当前 Official MCP Registry 的 Package Record 形如：

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "io.github.example/invoice-summary",
  "title": "Invoice Summary",
  "version": "1.4.0",
  "description": "Return an approved, read-only invoice summary.",
  "repository": {
    "url": "https://github.com/example/invoice-summary",
    "source": "github"
  },
  "packages": [
    {
      "registryType": "npm",
      "identifier": "@example/invoice-summary",
      "version": "1.4.0",
      "transport": {
        "type": "stdio"
      }
    }
  ]
}

这是用于说明 Schema 的示例，不代表推荐这个虚构 Package。Official MCP Registry 保存的是这份 Metadata，而不是 npm Artifact。记录也可以描述其他受支持的 Package Registry 或 Remote Server。应对引用的 Schema 做校验，并把本地审批、数据分类和副作用 Policy 保留在描述性 Metadata 之外。

Manifest 不应放 Secret。可以记录环境变量名称，但值、Token、Database URL 和 Private Key 必须放在 Secret Manager。

发现不是授权

搜索和语义匹配可以帮助 Host 提出能力建议，但应用仍需决定：

• Publisher 和 Artifact 是否获批；
• 哪个 Tenant 和 Principal 可以使用；
• 暴露哪些 Tools 和 Resources；
• 哪些数据可以离开边界；
• 外部副作用是否需要确认；
• 配额、成本和留存如何执行。

模型选择的 Registry 结果必须按不可信输入处理，不能据此选择 Owner、Role、Price、Credential 或 Destination。

来源审核

安装前应在审核记录中收集证据：

Namespace 或 Domain 验证可以证明控制权，是有用证据，但不是安全背书。

发布流程

可靠的发布流程应明确实现相关步骤。对于 Official MCP Registry，应先发布 Package 或部署 Remote Server，创建带版本的 server.json，认证 Namespace 控制权，再使用固定版本的 mcp-publisher 提交。之后执行更完整的审核：

1. 从固定 Release 生成 Metadata；
2. 按目标 Registry Schema 校验；
3. 验证 Source、Artifact、Endpoint 和 Namespace 所有权；
4. 执行依赖、Secret、License 和 Malware 检查；
5. 在 Sandbox 和代表性 Fixture 中测试 Tool Contract；
6. 记录 Capability、副作用、数据类别和 Required Scope；
7. 通过短期 CI 身份发布；
8. 保存审核记录和回滚引用。

官方 Namespace 验证可以使用受支持的 GitHub、DNS 或 HTTP 机制。它只能证明相关 Namespace 的控制权，不能证明 Package 无害。不要声称同一套 mcp-publisher 命令或认证流程适用于所有 Registry。应使用目标 Registry 的当前文档并固定 CLI 版本。

Runtime 安装边界

安装 Server 可能授予文件、网络、凭证或外部 API 访问权，应按部署代码治理：

• 要求 Allowlist 或审批策略；
• 固定 Package 版本和 Digest；
• 使用专用 OS 身份运行本地进程；
• 隔离文件系统和网络；
• 只注入最小 Secret；
• 禁止环境继承中的 Ambient Credential 和宽泛权限；
• 记录有界且脱敏的审计事件；
• 执行 Staging、Canary、Rollback 和 Revoke；
• 卸载时删除 Artifact、Cache、Credential 和派生记录。

Agent 可以请求安装，但 Deployment Controller 或人工审批必须授权。

确定性准入门禁应拒绝证据缺失的候选，而不是让模型猜测是否可信：

package main

import "fmt"

type candidate struct {
	PublisherVerified bool
	DigestPinned      bool
	ApprovedSource    bool
	EffectClass       string
}

func admit(item candidate) (bool, string) {
	if !item.PublisherVerified {
		return false, "publisher control is not verified"
	}
	if !item.DigestPinned {
		return false, "artifact digest is not pinned"
	}
	if !item.ApprovedSource {
		return false, "artifact source is not approved"
	}
	if item.EffectClass != "read_only" {
		return false, "effectful servers require separate approval"
	}
	return true, "admitted for isolated read-only canary"
}

func main() {
	allowed, reason := admit(candidate{
		PublisherVerified: true,
		DigestPinned:      true,
		ApprovedSource:    true,
		EffectClass:       "read_only",
	})
	fmt.Printf("allowed=%t reason=%q\n", allowed, reason)
}

这些证据字段必须来自经过验证的 CI 与审核记录，不能来自 Registry Description 或模型输出。准入成功后，Runtime 仍要执行身份、Tenant、对象和 Egress 控制。

安全模型

采用纵深防御，同时将控制分配到正确层次：

不要把 Badge、Trust Score、Annotation 或自动扫描描述成授权。

企业私有 Catalog

私有 Catalog 可以包含审核过的内部 Server、镜像的公共条目或两者。官方 OpenAPI 契约有助于提高 Client 互操作性，但复制或运行公共服务代码不会自动产生企业审批模型。应将私有层作为 Policy Service 设计：

• 将公共发现与内部审批分开；
• 要求 Tenant 和 Environment 标签；
• Allowlist Artifact 来源和域名；
• 保存来源、审核 Owner、过期时间和例外原因；
• 支持分阶段发布和紧急撤销；
• 防止公共条目静默替换内部 Artifact；
• 将 Secret 和 Runtime Policy 排除在 Catalog Metadata 之外；
• 同步删除和 Legal Hold 决策；
• 审计安装、升级、使用和移除。

API 兼容的索引不一定兼容每个 Client。应使用准确 Client 和 SDK 测试认证、Pagination、Version Selection、Transport Record 和 Error Semantics。官方 Aggregator 指南要求消费方持久化自己的副本，因为 Preview 服务不承诺 Uptime 或 Data Durability。

安全搜索与排序

排序应优先证据，而不是只看热度：

• Publisher 控制权已验证；
• 最近审核过的 Release；
• 可复现 Artifact 或 Source 关联；
• 已声明数据和副作用；
• 测试覆盖与兼容性证据；
• 漏洞和事件状态；
• 支持和弃用策略。

不要因为模型猜测相关、下载量更多或暴露 Tool 更多，就提高 Server 排名。能力越多，审核和爆炸半径成本越高。

撤销、升级与删除

发布前就规划生命周期：

对于 Official MCP Registry，已发布版本的 Metadata 不可变；修改 Metadata 必须提交新的唯一 Version。Publisher 当前不能自行删除或 Unpublish Server。Moderation 可以把记录标记为 deprecated 或 deleted，下游 Catalog 也应同步这些状态，但企业仍需要自己的即时 Denylist 与 Credential Revocation。不可变只防止静默修改，不会让有漏洞的版本变安全。

暴露前测试

Registry Metadata
  -> Schema 与来源测试
  -> Artifact 与依赖测试
  -> Sandbox Tool Contract 测试
  -> 身份、Tenant、对象与外发测试
  -> Canary 与 Rollback

至少测试：

• Manifest 畸形字段和未知字段；
• Package 与 Digest 不匹配；
• Namespace 或 Source 所有权不匹配；
• Credential 过期和错误 Token Resource；
• 跨 Tenant 对象访问；
• 恶意描述、Prompt、Resource 和 Tool Result；
• 超大输出和 Pagination；
• Cancellation、Timeout、Retry 和重复副作用；
• Package 升级和回滚；
• Registry 故障和过期 Metadata；
• 移除和删除传播。

实践清单

• [ ] 记录准确的 Registry、实现、Schema 版本和 Client。
• [ ] 分离 Registry、Catalog、Package、Source、Endpoint 和 Runtime 职责。
• [ ] 记录 Publisher、Source、Artifact Digest、Dependencies、Capabilities、Data 和 Egress。
• [ ] 将 Metadata、Annotation、Rating 和 Scan Result 视为证据，而非授权。
• [ ] 安装前要求审批，Agent 选择只作为建议。
• [ ] 隔离进程、凭证、文件系统和网络。
• [ ] 在 Runtime 执行 Principal、Tenant、对象、Purpose、Quota 和副作用策略。
• [ ] 测试升级、撤销、回滚、故障、重复投递和删除。
• [ ] 保存审核 Owner、过期日期、例外记录和事件联系人。

总结

MCP Registry 可以让能力更容易被发现，但发现只是第一步。可信路径应是：验证来源，固定 Artifact 或 Endpoint，审核声明的 Contract，以最小权限安装，在 Server 执行授权，并让回滚与删除真正可用。目录条目或热度信号不应替代安全决策。

延伸阅读

• MCP 协议架构与安全边界解释 Registry 条目最终进入的 Host、Client、Server、Transport 与 Authorization 边界。
• MCP 术语页定义协议，MCP Server 术语页聚焦被发布和治理的能力提供方。

一手来源

• Model Context Protocol Registry 仓库
• Official MCP Registry Preview 公告
• Official MCP Registry 发布教程
• MCP Registry API 与 Aggregator 指南
• MCP Registry FAQ：版本、更新与 Unpublish
• Model Context Protocol Tool 规范
• Model Context Protocol Authorization 规范
• SLSA v1.2