Wiki · Concept · Last reviewed June 25, 2026

MCP Registry

The MCP Registry is the official preview metadata repository and API for discovering publicly accessible Model Context Protocol servers, with namespace verification and room for downstream subregistries.

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.

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. A registry entry should therefore be treated as a current discovery record, not as a permanent endorsement or archival guarantee.

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, 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.

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 necessarily 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.

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, or simply wrong for the data class it touches.

Governance Pattern

A responsible client or enterprise subregistry should preserve the upstream server name, version, package identifier, endpoint, publisher namespace, registry fetch time, hash where available, status field, tool list, capability summary, and downstream review notes. It should also record when a server was added, deprecated, blocked, or re-approved.

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, and policy labels for read-only or write-capable tools. The official OpenAPI-compatible subregistry model is useful because it lets different institutions share an interface while carrying different risk judgments.

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 for endpoint claims.

Do not cite the registry 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