MCP Registry Governance: Discovery, Provenance, and Safe Installation

The Short Version

An MCP Registry solves a discovery problem. It does not automatically solve trust, authorization, package security, tenancy, billing, or operations.

registry entry
      |
      v
reviewed source + pinned artifact or endpoint
      |
      v
isolated installation + runtime policy
      |
      v
authenticated Tool call + object authorization

The word “official” is not a security property. Always record the registry implementation, schema revision, source URL, artifact digest or endpoint owner, review decision, and runtime policy that turned metadata into an installation.

Registry, Catalog, and Package Repository

These terms describe different layers:

The official MCP registry repository and service may evolve independently of client marketplaces and private catalogs. Do not call every GitHub list, marketplace, or package index “the GitHub MCP Registry.”

What a Manifest Should Describe

Use the exact schema required by the target registry. A conceptual manifest might contain:

{
  "name": "com.example/invoice-summary",
  "version": "1.4.0",
  "description": "Return an approved, read-only invoice summary.",
  "repository": {
    "url": "https://github.com/example/invoice-summary",
    "revision": "pinned-revision"
  },
  "artifacts": [
    {
      "type": "package",
      "registry": "package-registry",
      "identifier": "example-invoice-summary",
      "version": "1.4.0",
      "digest": "sha256:pinned-digest"
    }
  ],
  "transports": ["stdio"],
  "declared_side_effects": "read_only",
  "required_scopes": ["invoices.read"],
  "data_classes": ["tenant_invoice_metadata"]
}

This is an illustration, not a universal server.json. A registry may use different field names, package records, remote records, or version rules. Validate against the target schema and keep runtime policy outside descriptive metadata.

Do not put secrets in a manifest. Environment variable names may be documented, but values, tokens, database URLs, and private keys belong in a secret manager.

Discovery Is Not Authorization

Search and semantic matching can help a Host propose a capability. The application still decides:

• whether the publisher and artifact are approved;
• which tenant and principal may use it;
• which Tools and Resources are exposed;
• which data may leave the boundary;
• whether an external side effect needs confirmation;
• how quotas, cost, and retention apply.

A model-selected registry result must be treated as untrusted input. It must not select an owner, role, price, credential, or destination.

Provenance Review

Before installation, collect evidence in a review record:

Namespace or domain verification is useful evidence of control, not a clean bill of health.

Publishing Workflow

A defensible publishing workflow is explicit about implementation-specific steps:

1. generate metadata from the pinned release;
2. validate against the target registry schema;
3. verify source, artifact, endpoint, and namespace ownership;
4. run dependency, secret, license, and malware checks;
5. exercise Tool contracts with a sandbox and representative fixtures;
6. record capabilities, side effects, data classes, and required scopes;
7. publish through a short-lived CI identity;
8. retain the review record and a rollback reference.

Do not claim that a generic mcp-publisher command, GitHub OAuth flow, DNS proof, or OIDC workflow works for every registry. Use the target registry’s current documentation and pin the CLI version.

Runtime Installation Boundary

Installing a Server can grant access to files, networks, credentials, or external APIs. Treat it like deploying code:

• require an allowlist or approval policy;
• pin package versions and digests;
• run local processes with a dedicated OS identity;
• isolate filesystem and network access;
• inject only the minimum secrets;
• deny ambient credentials and broad environment inheritance;
• capture bounded audit events without raw secrets;
• stage, canary, roll back, and revoke;
• delete artifacts, caches, credentials, and derived records on removal.

An Agent may request installation, but a deployment controller or human approval must authorize it.

Security Model

Use defense in depth, but assign each control to the right layer:

Do not describe badges, trust scores, annotations, or automated scans as authorization.

Private Enterprise Catalogs

A private catalog can contain approved internal Servers, mirrored public entries, or both. Design it as a policy service:

• separate public discovery from internal approval;
• require tenant and environment labels;
• maintain an allowlist of artifact sources and domains;
• store provenance, review owner, expiry, and exception reason;
• support staged rollout and emergency revoke;
• prevent a public entry from silently replacing an internal artifact;
• keep secrets and runtime policy out of catalog metadata;
• synchronize deletion and legal-hold decisions;
• audit installation, upgrade, use, and removal.

An API-compatible index is not automatically compatible with every client. Test authentication, pagination, version selection, transport records, and error semantics with the exact client and SDK.

Safe Search and Ranking

Ranking should favor evidence, not only popularity:

• verified publisher control;
• recent reviewed release;
• reproducible artifact or source link;
• declared data and side effects;
• test coverage and compatibility evidence;
• vulnerability and incident status;
• support and deprecation policy.

Do not rank a Server higher because a model guessed it is relevant, because it has more downloads, or because it exposes more Tools. More capability increases review and blast-radius cost.

Revocation, Upgrade, and Deletion

Plan lifecycle before publication:

An immutable release can still be revoked. Immutability prevents silent mutation; it does not make a vulnerable version safe.

Tests Before Exposure

registry metadata
  -> schema and provenance tests
  -> artifact and dependency tests
  -> sandbox Tool contract tests
  -> identity, tenant, object, and egress tests
  -> canary and rollback

At minimum test:

• malformed or unknown manifest fields;
• package and digest mismatch;
• namespace or source ownership mismatch;
• expired credentials and wrong token resource;
• cross-tenant object access;
• malicious descriptions, prompts, Resources, and Tool Results;
• oversized output and pagination;
• cancellation, timeout, retry, and duplicate side effects;
• package upgrade and rollback;
• registry outage and stale metadata;
• removal and deletion propagation.

Practical Checklist

• [ ] Name the exact registry, implementation, schema revision, and client.
• [ ] Separate registry, catalog, package, source, endpoint, and runtime responsibilities.
• [ ] Record publisher, source, artifact digest, dependencies, capabilities, data, and egress.
• [ ] Treat metadata, annotations, ratings, and scan results as evidence, not authorization.
• [ ] Require approval before installation and keep Agent selection advisory.
• [ ] Isolate processes, credentials, filesystems, and network access.
• [ ] Enforce principal, tenant, object, purpose, quota, and side-effect policy at runtime.
• [ ] Test upgrades, revocation, rollback, outage, duplicate delivery, and deletion.
• [ ] Keep a review owner, expiry date, exception record, and incident contact.

Conclusion

An MCP Registry can make capabilities easier to find, but discovery is only the first step. The trustworthy path is: verify provenance, pin the artifact or endpoint, review the declared contract, install with least privilege, enforce authorization in the server, and keep rollback and deletion operational. This approach scales better than treating a directory entry or a popularity signal as a security decision.

Primary Sources

• Model Context Protocol Registry repository
• Model Context Protocol Specification
• Model Context Protocol Tools
• Model Context Protocol Authorization
• SLSA: Supply-chain Levels for Software Artifacts