What is an MCP Registry?

A registry is a discovery and metadata service for MCP servers. The exact fields, API, namespaces, and publishing workflow depend on the registry implementation and revision. A registry entry is not proof that the referenced package or remote endpoint is safe.

Does a registry host MCP server code?

The Official MCP Registry hosts metadata, not packages or binaries. Its records point to package registries such as npm, PyPI, or container registries, or describe remote servers. Other registry implementations may make different choices, so clients must identify the exact service and schema they consume.

Does namespace verification make installation safe?

No. It can provide evidence about who controls a name or account. It does not prove the code is benign, the dependencies are current, the endpoint is isolated, or the server is authorized for a tenant.

Can an enterprise run a private catalog?

Yes. An organization can maintain an allowlisted index or an implementation compatible with a public API. It must still govern review, provenance, credentials, egress, upgrades, revocation, incident response, and deletion.

Should an Agent install a server at runtime?

Treat installation as a privileged deployment action, not an ordinary Tool call. Require an approved source, pinned version, isolated credentials, human or policy approval, and a reversible rollout.

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.

The Official MCP Registry is still a preview service: breaking changes or data resets may occur, and it provides no uptime or data-durability guarantee. Its public read API currently exposes v0.1 endpoints such as GET /v0.1/servers. Treat those facts as a versioned integration surface, not a permanent promise.

text

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:

Layer	Responsibility	What it does not prove
registry	publish and query server metadata	safe code or authorized Tool calls
catalog	curate, filter, or allowlist entries	complete security review
package repository	distribute packages or images	that an MCP server behaves safely
source repository	maintain code and releases	that a downloaded artifact matches source
remote endpoint	execute server-side behavior	that its owner, data, or egress is acceptable
runtime policy	decide identity, tools, data, and network access	that metadata is truthful

The Official MCP Registry is the public service at registry.modelcontextprotocol.io. The MCP Registry API is the OpenAPI contract that third-party registries or subregistries can implement. A marketplace or enterprise catalog may ingest the official feed, add ratings or policy metadata, and expose a compatible API, but it is still a separate trust domain. 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 current Official MCP Registry package record has this shape:

json

{
  "$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"
      }
    }
  ]
}

This is a schema-oriented example, not an endorsement of the fictional package. The Official MCP Registry stores this metadata but not the npm artifact. A record may instead describe other supported package registries or a remote server. Validate against the referenced schema and keep local approval, data classification, and side-effect 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:

Evidence	Review question
publisher identity	who controls the namespace, repository, package, and endpoint?
source-to-artifact link	can the released artifact be mapped to reviewed source?
version and digest	what exact bytes will be installed?
dependencies	are lockfiles, transitive packages, and base images reviewed?
release history	are changes signed, reproducible, and reversible?
capabilities	do declared Tools, Resources, and Prompts match observed behavior?
network	which hosts, DNS names, and egress paths are needed?
data	what is read, stored, exported, or retained?
support	who handles incidents, revocation, and deletion?

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. For the Official MCP Registry, publish the package or remote deployment first, create a versioned server.json, authenticate namespace control, and submit with a pinned mcp-publisher release. Then apply the broader review:

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

Official namespace verification can use supported GitHub, DNS, or HTTP mechanisms. It proves control of the relevant namespace; it does not prove the package is benign. Do not claim that the same mcp-publisher command or authentication flow 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.

A deterministic admission gate should reject unknown evidence rather than asking the model to infer trust:

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)
}

The evidence fields must come from verified CI and review records, not registry descriptions or model output. A successful admission still needs runtime identity, tenant, object, and egress enforcement.

Security Model

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

Control	Layer	Limitation
namespace proof	registry	proves control of a name, not benign behavior
schema validation	registry/CI	checks shape, not intent or runtime
dependency scan	CI/package tooling	misses novel behavior and runtime abuse
signature/digest	artifact supply chain	proves bytes, not safety
sandbox and egress	runtime	limits blast radius, not business authorization
principal and object policy	application server	authoritative for data and side effects
review and incident response	organization	requires continued operation

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. The official OpenAPI contract can improve client interoperability, but cloning or running the public service does not create an enterprise approval model. Design the private layer 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. The official aggregator guidance expects consumers to persist their own copy because the preview service offers no uptime or durability guarantee.

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:

Event	Required action
vulnerable release	stop new installs, notify users, publish fixed version
compromised publisher	revoke credentials, quarantine entries, investigate artifacts
endpoint ownership change	re-verify domain and principal before rollout
breaking protocol change	publish a new compatibility record and migration path
uninstall	revoke credentials and remove local/runtime data
deletion request	propagate to catalog, cache, index, backups, and exports as applicable

For the Official MCP Registry, published version metadata is immutable: changing metadata requires a new unique version. Publishers currently cannot delete or unpublish a server themselves. Moderation may mark records with statuses such as deprecated or deleted, and downstream catalogs must ingest those status changes, but an enterprise still needs its own immediate denylist and credential revocation path. Immutability prevents silent mutation; it does not make a vulnerable version safe.

Tests Before Exposure