What is an MCP registry?

By Nolan Sullivan, Founding Growth Engineer

·Published August 25, 2026

An MCP registry supplies discovery metadata. It records what exists and, in its private form, what is approved to exist. It does not show what runs on employee laptops, which credentials those servers hold, or which agents call them. Those records belong to an MCP inventory, while enforcement belongs to an MCP gateway. A registry, inventory, and gateway answer different security questions.

What is an MCP registry?

An MCP registry, also called an MCP server registry, stores metadata about MCP servers, and clients, marketplaces, and platform teams query it to discover them. The official registry documentation describes each entry as a standardized server.json record containing the server’s unique name in reverse-DNS format, such as io.github.user/server-name, a pointer to where the server lives, such as an npm package name or a remote server URL, execution instructions such as command-line arguments and environment variables, and discovery data such as a description and capabilities.

The registry hosts none of the code. Packages can stay on npm, PyPI, or Docker Hub, while remote servers can remain on the vendor’s infrastructure. The registry entry points at them. Consumers read the catalog through a REST API, with GET /v0.1/servers at registry.modelcontextprotocol.io returning the full list for downstream systems to ingest.

Is there an official MCP registry?

Yes. The official MCP Registry at registry.modelcontextprotocol.io launched in preview in September 2025 as part of the MCP open-source project, backed by Anthropic, GitHub, PulseMCP, and Microsoft. It remains in preview as of its about page, which warns that breaking changes or data resets may occur before general availability, so treat any dependency on it as a dependency on a preview service.

Its scope is narrower than the name suggests. The boundaries matter for anyone evaluating it as a governance control.

• Namespace authentication does not verify server code. Publishing under io.github.* requires the matching GitHub account, and domain namespaces require DNS or HTTP verification. The registry performs no security scanning of server code. It delegates scanning to package registries and downstream aggregators, and its own moderation is limited to takedowns of spam and malicious entries.
• Public servers only. The registry does not support private servers, meaning anything on an internal hostname or a private package registry. The official recommendation for those is to host your own private MCP registry.
• Not built for self-hosting. The official codebase is not designed to be run internally, and the maintainers state they cannot support forks.
• Aggregators are the intended readers. The registry expects marketplaces and subregistries to consume its API and serve host applications, rather than host applications querying it directly, with the OpenAPI spec as the shared interface.

What are the third-party MCP registries?

Third-party MCP registries have multiplied since the official preview launched. The official project’s naming convention defines an “MCP registry” in lowercase as any third-party service implementing the MCP Registry API. For a CISO, sorting them into three kinds is more useful than enumerating them because each kind answers a different procurement question.

The evaluation question is which kind you are looking at. An aggregator improves discovery of public servers. A cloud catalog folds MCP servers into an inventory you already keep. An enterprise product adds governance to the same OpenAPI shape. Whichever kind you pick, the record of what is actually running on your endpoints still comes from an MCP inventory.

What is a private or central MCP registry?

A private MCP registry is the catalog an organization hosts for the servers the public one will not take. The official documentation recommends that servers on internal hostnames or private package registries be published to a private MCP registry the organization runs itself, implementing the same OpenAPI spec so existing clients and host applications can consume it without custom work.

A central MCP registry is the organization-wide version of the same idea, and it is the phrase that matters in a security review. It identifies which servers employees may install, who owns each one, and which environments see them, instead of relying on per-developer mcp.json files. The official preview announcement describes this pattern for private subregistries inside enterprises that use the official registry as their upstream data source.

What a central MCP registry records

Both remain catalogs of metadata. A central registry can record that a server is approved and who owns the approval. It does not record which employees run it from local configuration files or whether an unapproved server has appeared. That continuously updated record of servers actually in use, with transports, credentials, last-seen timestamps, and sanctioned status, is an MCP inventory, and the unsanctioned population it surfaces is shadow MCP.

How is an MCP registry different from an MCP gateway?

A registry handles discovery. It records server metadata, install targets, and namespaces outside the tool-call path. Once a client has connection details, the registry’s involvement ends. An MCP gateway handles enforcement. It terminates tool calls and applies identity, allowlists, audit logging, and data controls on every request. That is where MCP security controls execute.

When should an organization use an MCP registry and gateway together?

Each works without the other, with predictable gaps:

• A registry alone cannot block a call. An approved-server catalog without an enforcement point is a policy document.
• A gateway alone governs traffic when servers are added by URL. It does not provide discovery of public servers or a sanctioned catalog for employees to browse.

Together, the registry defines what is approved and the gateway makes that approval binding. That pairing explains why the enterprise products in the table include both.

The diagram separates the discovery, runtime enforcement, and observation roles.

How does Speakeasy use the official MCP Registry?

The Speakeasy AI Control Plane uses the official MCP Registry as the source for its catalog. The Catalog page, under Connect > Catalog in the dashboard, lets teams browse, search, and filter registry entries, then install the servers they approve into a project. Viewing requires the project:read or mcp:write scope and adding a server requires mcp:write, so a Member can browse the catalog while installs stay with holders of the write scope, which the default Admin role includes.

An install creates a remote MCP server on the platform. The vendor keeps running the server. The platform registers its URL and proxies sessions to it, adding authentication, per-tool access control, and tool logs without copying or re-hosting the server. One catalog entry can create several servers when it publishes multiple remote endpoints. Only streamable HTTP endpoints are accepted, and entries marked Manual Setup require configuration outside the one-click path.

The registry feed covers the sanctioned side only. Servers employees wire up on their own are surfaced by shadow MCP detection, which works from agent hooks and live traffic rather than from any registry, and both populations land in the MCP inventory the platform maintains. The official registry supplies the catalog of what exists, the platform turns the approved subset into a governed and auditable path, and the gateway and inventory cover what is actually running. To see the catalog and the inventory against your own estate, visit the AI Control Plane or talk to us.

Organization administrators can also search the catalog, register servers, and check readiness from an agent through the Speakeasy Platform MCP.