Wiki · Concept · Last reviewed June 25, 2026

MCP Registry

The MCP Registry is the official preview metadata repository and API for publicly accessible Model Context Protocol servers; it improves discovery, but it is not a security review, package host, or procurement approval layer.

Category: Concept / Agent Infrastructure Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: MCP, registry, agents, tool discovery, server metadata, supply chain

Definition

The MCP Registry is the official centralized metadata repository for publicly accessible Model Context Protocol servers. The Model Context Protocol project launched the registry in preview on September 8, 2025 as an open catalog and API for discovering MCP servers and giving downstream registries a common upstream data source.

The registry does not host the server code in the way npm, PyPI, NuGet, Docker Hub, or an OCI registry hosts packages and images. It hosts metadata that points to installable packages, remote server URLs, execution instructions, versions, and discovery data. The official documentation describes this metadata as a standardized server.json format.

The preview status matters. The official registry documentation says breaking changes or data resets may occur before general availability, and the aggregator documentation says the registry does not provide uptime or data-durability guarantees. A registry entry should therefore be treated as a current discovery record, not as a permanent endorsement, archival guarantee, or assurance result.

Current Context

As of June 25, 2026, the official registry documentation describes the MCP Registry as a preview service at registry.modelcontextprotocol.io, with a public read API, namespace verification, standardized installation and configuration information, and a server.json metadata format. The documentation also says the registry is for public servers: private network servers and packages in private package registries should be handled through a private registry or subregistry.

The registry is designed as upstream infrastructure, not as the final user-facing trust layer. The official documentation says host applications are not expected to consume the official registry directly; they should generally consume downstream registries or marketplaces that implement the registry OpenAPI interface and add their own curation, ratings, scans, enterprise policy, or review metadata.

That division is important for agent governance. An MCP server may expose tools, transports, remote endpoints, local packages, secrets, environment variables, and downstream APIs. Discovery metadata helps clients find and install servers, but the decision to give a server access to files, credentials, business systems, or user data belongs to the host, administrator, marketplace, or enterprise control plane.

Metadata Model

A server record has a unique name, commonly in reverse-DNS form such as io.github.user/server-name or a domain-backed namespace. It can describe where to locate the server, how to run it, which package registry or remote endpoint is involved, which version is being published, and what capabilities or descriptive data a client or aggregator may need before presenting it to a user.

The supported package-type documentation lists npm, PyPI, NuGet, Docker or OCI images, and MCPB artifacts, each with its own verification pattern. For example, npm package ownership is checked through an mcpName property in package.json, while Docker or OCI image ownership uses an io.modelcontextprotocol.server.name annotation. MCPB package metadata includes a SHA-256 hash, which clients validate before installation.

Remote servers are represented through a remotes property in server.json. The official remote-server guide says a remote server must be publicly accessible at its specified URL, and documents Streamable HTTP and SSE transport entries, URL template variables, and required HTTP headers that clients may need to collect from users.

Versioning is part of the trust surface. The registry requires a version string in server.json, recommends semantic versioning, and treats published version metadata as immutable; updates require a new server.json with a unique version string. The aggregator guide separately notes that server metadata is generally immutable except for a status field such as deprecated or deleted.

The registry also exposes an unauthenticated read-only REST API for aggregators. The official aggregator guide names GET /v0.1/servers, version-listing, and version-fetching endpoints, with cursor pagination and an updated_since filter for incremental synchronization. The intended consumers are downstream aggregators and marketplaces, not every host application directly.

Trust and Security

The registry's trust model starts with namespace authentication. Publishing under a GitHub namespace requires GitHub-based authentication, while domain-backed namespaces can use DNS or HTTP verification. This helps bind a server name to a GitHub account or domain owner, but it does not prove that the server is safe, high quality, or appropriate for a given workflow.

The official registry page says security scanning is delegated to underlying package registries and downstream aggregators. The moderation policy is deliberately permissive: it focuses on illegal content, malware, spam, and non-functioning servers, while saying that low-quality servers, buggy servers, vulnerable servers, duplicate servers, and adult-content servers are generally not removed merely for those reasons.

The moderation policy also matters after removal. When a server is removed, the policy says the status is set to deleted while metadata normally remains accessible through the registry API, so aggregators can remove or flag it. That makes status synchronization a safety control, not just a display preference.

That is the key governance boundary. A registry is a discovery layer. It is not a security review, procurement approval, data-processing agreement, vulnerability assessment, or human approval interface. An MCP-compatible server can still be malicious, overbroad, stale, misleading, vulnerable, or simply wrong for the data class it touches.

Boundary Tests

Not a package registry. The MCP Registry does not replace npm, PyPI, NuGet, Docker Hub, OCI registries, GitHub releases, or vendor package distribution. It points to them and stores discovery metadata about MCP servers.

Not a marketplace by itself. A marketplace or enterprise subregistry may add ratings, scans, allowlists, license data, policy labels, and review notes. The official registry intentionally leaves many of those judgments to downstream aggregators.

Not proof of safe authority. A verified namespace says something about who may publish under a name. It does not prove that the server's tools are least-privilege, that its OAuth design is correct, that its dependencies are clean, or that its outputs are safe for a model to treat as evidence.

Not a private inventory. The official registry excludes private servers. Internal MCP servers need a separate AI System Inventory, private registry, or enterprise subregistry that records owners, data classes, credentials, and review status.

Not an attestation layer. Registry metadata can complement SLSA Provenance, SPDX, SCITT, signatures, hashes, and vulnerability scans, but it is not itself a complete software supply-chain attestation.

Governance Pattern

A responsible client, marketplace, or enterprise subregistry should preserve the upstream server name, title, version, schema URL, package identifier, remote endpoint, transport, publisher namespace, authentication method, registry fetch time, package hash where available, status field, tool list, capability summary, and downstream review notes. It should also record when a server was added, deprecated, blocked, re-approved, or removed from a user-facing catalog.

Subregistries can add opinionated layers that the official registry intentionally avoids: security scans, popularity signals, internal approval status, license notes, data-retention tags, jurisdiction notes, incident contacts, vulnerability-disclosure links, and policy labels for read-only, write-capable, destructive, open-world, or secret-handling tools. The official OpenAPI-compatible subregistry model is useful because it lets different institutions share an interface while carrying different risk judgments.

For higher-risk deployments, registry review should connect to AI Agent Sandboxing, AI Agent Identity, AI Audit Trails, AI Bill of Materials, and Secure AI System Development. A server approved for demo weather lookups should not inherit the same authority as a server that can read email, modify code, query customer records, deploy infrastructure, or trigger payments.

The mistake to avoid is registry laundering. A server appearing in an official registry should not automatically appear in a user's agent with broad access to files, accounts, cloud systems, or production data. Discovery should lead to review; it should not bypass review.

Source Discipline

Claims about the MCP Registry should name the source and date because the registry is in preview. Use the official registry documentation for current behavior, the launch post for the September 2025 preview announcement, the GitHub repository for implementation and API-freeze notes, and the registry API documentation or OpenAPI file for endpoint claims.

Separate registry facts from server facts. A registry entry may document a name, version, package, remote URL, status, transport, or publisher namespace; it does not prove what the server implementation actually does at runtime. For runtime behavior, cite the server repository, package contents, released artifact, endpoint documentation, signed provenance, security advisory, or independent test record.

Do not cite registry presence as proof that a server is secure or endorsed. The primary sources explicitly place much of that responsibility on package registries, downstream aggregators, marketplaces, and consumers.

Spiralist Reading

Spiralism reads the MCP Registry as a directory of doors. It tells agents where tools may be found, who claims the name, and how the tool might be installed or reached.

The danger is mistaking a directory for a temple guard. Naming a door is not the same as guarding it. The registry makes the agent ecosystem legible, but institutions still have to decide which doors may open, for whom, and with what record left behind.

Open Questions

Sources

Return to Wiki