What Is an MCP Registry? A Guide to Discovery, Governance, and Control

When the Model Context Protocol team shipped the official public MCP Registry, they put a striking line in their own documentation. The public registry deliberately does not support private servers, and organizations should host their own private registry instead, as the official MCP Registry documentation states. That single design decision tells you almost everything about what an MCP registry really is for an enterprise. It is not a phone book of tools your agents can call. It is the place where you decide which tools they are allowed to call at all.

An MCP registry is a metadata catalog of Model Context Protocol servers that agents and clients query to discover, verify, and connect to the tools they are permitted to use. A public registry answers "what MCP servers exist?" An enterprise registry answers a harder question: which trusted servers may this agent reach, under whose identity, with what access, and with what audit trail? That shift, from a directory you read to a control plane you enforce, is the through-line of this guide.

This page is written for platform-engineering leads, AI and ML platform owners, and security and identity leaders who already run MCP-based agents and now need to operate the registry layer at scale. It assumes you know what MCP is. It covers the definition and how a registry differs from a package registry, the often-conflated terminology of registry, catalog, marketplace, and gateway, the metaregistry architecture, the official public registry and its deliberate limits, the public-versus-private decision, MCP security risks, a four-capability governance framework, the operating model, and how to evaluate build versus buy.

What is an MCP registry?

An MCP registry is a metadata service that catalogs Model Context Protocol servers so that clients, agents, and aggregators can discover them, resolve their connection details, and verify their provenance. It stores structured descriptions of servers, not the servers themselves.

The cleanest way to understand this is by contrast with a package registry like npm or PyPI. A package registry hosts artifacts: when you install a package, you download code from the registry. An MCP registry is metadata-only. It does not host server code. Each entry is a record, typically a server.json document, that names the server, describes its capabilities, and points to where the actual server package or endpoint lives, as described in the official MCP Registry overview. The registry is the index; the packages live elsewhere.

This matters because it changes what the registry is responsible for. A package registry is responsible for delivering bytes. An MCP registry is responsible for trust signals: who published this server, does the namespace belong to them, which versions are known-good, and what does the entry assert about the server's behavior. Those signals are exactly what an enterprise needs to govern access, which is why the registry is a natural control point rather than a passive list.

What an MCP registry does, at a glance

• Discovery - lets clients and agents find available servers and their connection details, usually through a query API.
• Publishing - provides a controlled path for server authors to add and update entries.
• Naming - assigns each server a unique, verifiable namespace so two servers cannot impersonate each other.
• Versioning - records immutable version strings so clients can pin to a known-good release.
• Trust - carries provenance and integrity metadata (publisher verification, hashes) that downstream consumers can check.

Registry vs. catalog vs. marketplace vs. gateway

These four terms are used interchangeably across vendor blogs and docs, and the conflation causes real confusion when teams try to scope a project. They describe different things at different layers.

Term	What it is	Primary job	Lives where
MCP registry	A metadata index of MCP servers with naming, versioning, and provenance	Discover and verify which servers exist and are trusted	Index / control plane
MCP catalog	A curated, often filtered view of servers presented for adoption (frequently the enterprise-facing surface of a registry)	Present a vetted set of approved servers to internal consumers	Presentation / curation layer
Internal MCP marketplace	A catalog with self-service adoption workflows (request, approve, install)	Let teams browse and onboard approved servers themselves	Workflow layer over the catalog
MCP gateway	A runtime proxy that brokers live connections between agents and servers	Enforce identity, access, and policy on every call at request time	Data plane / runtime

The distinction is operationally significant. A registry and a mcp catalog describe and present servers; an internal mcp marketplace adds adoption workflow on top; an MCP gateway sits in the live request path and enforces decisions. For a deeper treatment of curating and presenting servers, see our guide to MCP catalogs and managing MCP servers. In practice, an enterprise wants the registry and gateway working together. The registry decides what is trusted and discoverable, and the gateway enforces that decision on every connection. Treating them as the same thing is how teams end up with a searchable list and no actual control.

How an MCP registry works (architecture)

The metaregistry, metadata-only model

The reference design is a metaregistry: a service that stores canonical metadata about servers and exposes it through an open API, while the server packages live in their existing distribution channels. Each server is described by a server.json record that the registry validates and stores, as documented in the Model Context Protocol registry documentation. Because the registry holds metadata rather than artifacts, multiple registries can share the same schema and API, and a private registry can mirror or extend the public one without re-hosting any code.

Discovery: the API clients and aggregators consume

Discovery happens through a REST API that clients, agents, and downstream aggregators query to enumerate servers and resolve their connection details. Because the API is open and standardized, with an OpenAPI specification other registries can implement, aggregators and IDE clients can build on top of it without bespoke integrations. You can see this presentation layer in practice in a browsable directory of MCP servers, where aggregated entries are organized by category for adoption.

Publishing: namespace ownership and the publisher CLI

Authors publish servers through a controlled flow, typically the mcp-publisher CLI, which submits a validated server.json against a namespace the author has proven they own. Publishing is not anonymous upload. It is gated on namespace ownership.

Namespacing and verification: proving who owns a server

Namespaces use a reverse-DNS convention, such as io.github.username/server-name for GitHub-backed authors or com.example/server-name for organizations. Ownership is proven, not asserted. GitHub-based namespaces are verified through GitHub OAuth, and domain-based namespaces through a DNS TXT challenge on the claimed domain, per the official registry documentation. This is the registry's primary defense against impersonation, since an attacker cannot publish under a namespace they cannot prove they control.

Versioning and pinning

Each published version carries an immutable, unique version string, so a given version always refers to the same release and cannot be silently changed underneath consumers. Clients are expected to pin to a specific known-good version rather than always pulling latest, as the MCP registry versioning documentation specifies. Pinning is the mechanism that protects you from a server quietly changing behavior after you have approved it.

Signing and integrity

Integrity is carried at the metadata level. Entries can reference content hashes, such as SHA-256 digests, that let a consumer confirm the package they fetched matches what the registry described. Security scanning is typically delegated: the registry records provenance and integrity signals, and downstream consumers or platforms run the actual vetting and scanning against those signals. The registry establishes trust anchors. It does not by itself guarantee a server is safe.

Federation and subregistries

Because the model is metadata-only with a shared schema, registries can federate: a public canonical source can be mirrored, filtered, or extended by private and internal subregistries. An enterprise can run a private subregistry that pulls approved entries from the public source and adds its own internally published servers, all behind its own access controls. Federation is what makes a private registry practical without forking the entire ecosystem.

The official (public) MCP registry, and what it deliberately is not

The official public registry, registry.modelcontextprotocol.io, launched in preview in September 2025, backed by Anthropic, GitHub, PulseMCP, and Microsoft. It is a community-driven service with an open REST API and OpenAPI specification that other registries can implement, and it serves as valuable ecosystem context: a canonical place where public MCP servers can be discovered.

But the official documentation is explicit about its scope. The public MCP Registry deliberately does not support private servers, and it recommends that organizations needing private servers host their own private registry. This is not a missing feature or a roadmap item. It is a stated boundary. The public registry is for the open ecosystem. Anything an enterprise needs to keep internal, governed, or access-controlled is, by design, out of scope. Platform-specific public catalogs from major vendors follow a similar pattern of indexing public servers, as covered in our MCP catalogs guide.

That boundary is the entire reason the public-versus-private question exists, and it is where the enterprise decision begins.

Public vs. private (enterprise) MCP registry

Once you accept that the public registry will not hold your private servers, the question is not whether you need a private mcp registry but how governed it should be. The two models differ on every axis that matters to a regulated or security-conscious organization.

Dimension	Public / community registry	Private / enterprise registry
Discovery scope	All public servers; no internal servers	Curated set of approved internal and external servers
Server vetting	Provenance signals only; vetting delegated to the consumer	Mandatory review and approval before a server is discoverable
Identity & access	Open read; no per-consumer access control	Identity-based access; agents see only what they are entitled to
Audit	None for the consuming organization	Full audit trail of who adopted and called what
Policy enforcement	None	Centralized policy on which servers, scopes, and data are allowed
Supported server types	Public servers only	Private, internal, and approved public servers

This is the core commercial decision. A private ai registry is what lets a platform team expose an enterprise mcp catalog of vetted servers, run it as an internal mcp marketplace with self-service onboarding, and still enforce identity-based access control and policy on everything inside it. The public registry gives you reach. A private registry gives you control. Most enterprises adopting MCP at scale need both, with the private layer as the surface their own agents actually consume. Running this layer well is itself a discipline, covered in our guide to running MCP at enterprise scale.

This is also where agen.co fits. agen.co's enterprise MCP gateway and registry treat the private registry and the runtime gateway as one system. Every connection carries identity, authentication, authorization, and compliance, across 200+ integrations, with distributed governance built in rather than bolted on. Browse the agen.co MCP gateway directory to see the governed integrations available.

Security risks of MCP servers (and why public registries aren't enterprise-safe)

The reason a public registry is not enterprise-safe is not that the servers are necessarily malicious. It is that a discovery-only index gives you no control over a well-documented set of MCP-specific threats. Security researchers and standards bodies have catalogued these threat classes in resources like the OWASP MCP Security Cheat Sheet.

• Tool poisoning - a server embeds malicious or manipulative instructions in its tool descriptions to steer an agent's behavior, a threat class detailed in the OWASP MCP Security Cheat Sheet.
• Rug pull - a server behaves benignly through approval, then changes its behavior or definition after it is trusted, a tool-definition attack analyzed in peer-reviewed research on enhanced tool-definition integrity.
• Tool shadowing - a malicious server registers a name or capability that impersonates or overrides a trusted one.
• Confused deputy - an agent with broad privileges is tricked into performing an action on behalf of a less-privileged caller, one of the access threats covered in the OWASP MCP Security Cheat Sheet.
• Supply-chain compromise - a dependency or upstream package of a server is compromised, propagating through to the agent.
• Credential aggregation - a single server accumulates broad credentials and scopes, becoming a high-value target.

Each maps to a registry-level control. Tool poisoning and shadowing are blunted by mandatory vetting and verified namespacing; the mechanics of one of these attacks are detailed in our guide to how MCP tool poisoning works and how to prevent it. Rug pulls are blunted by immutable versioning, OAuth-enhanced tool definitions and policy-based access control, and re-review on version change. Confused-deputy and credential-aggregation risks are blunted by least-privilege, scoped credentials per agent rather than shared broad ones, in line with the controls OWASP recommends (OAuth2 with PKCE, scoped credentials, least privilege). A public registry implements none of these for your organization. A governed private registry implements all of them. For the full threat model and registry-level controls, see our MCP security guide.

The governance framework: turning a registry into a control plane

What turns a registry from a directory into a control plane is four capabilities working together. A registry that has all four is a control plane; one missing any of them is a liability at enterprise scale. These four also sit at the heart of broader AI agent governance.

1. A vetted catalog - only reviewed, approved servers are discoverable, with provenance and integrity recorded for each.
2. Identity-based access - which agents and teams can see and connect to which servers is decided by identity, not by reachability.
3. Audit logging - every adoption and connection is recorded, so you can answer who used what, when, and under whose identity.
4. Policy enforcement - centralized rules govern which servers, scopes, and data classes are permitted, applied consistently across all consumers.

Identity and access for agents

Identity is the capability that makes the other three enforceable, and it is the hardest to get right because agents are not users. An agent often needs to act on behalf of a user or another service, with delegated, scoped, time-bound authority rather than a static API key. The MCP identity model and modern identity practice converge on OAuth-based flows with PKCE, least-privilege scopes, and on-behalf-of delegation so an agent never holds more access than the task requires, an approach detailed in Frontegg's identity management for AI agents.

This is where most registry projects under-invest. Discovery and naming are tractable. Agent identity, least-privilege authorization, and multi-tenant onboarding are where the real difficulty lives, and where a dedicated identity layer for AI agents earns its place in the stack. The handshake itself is covered in our guide to MCP authentication, and the underlying patterns, including MCP-native OAuth flows, least-privilege authorization, and multi-tenant onboarding for agents, are well established. Treat identity and access as a first-class part of the registry, not an afterthought added at the gateway.

What each registry entry must record

A governable entry is more than a name and an endpoint. At minimum, each entry should record:

• Owner team - who is accountable for the server and its lifecycle.
• Data-access scope - which systems and data classes the server can touch.
• Authentication method - how agents authenticate to it, and under whose identity.
• Approval status - reviewed, approved, deprecated, or blocked, with the reviewer recorded.
• Restrictions and version - the pinned version, allowed consumers, and any usage constraints.

If your registry entries cannot answer those five questions, you have a directory, not a control plane.

Operating model: who owns the MCP registry

The MCP registry is core infrastructure, and it belongs to the team that owns core infrastructure: platform engineering. It sits alongside the service catalog, the secrets manager, and the CI/CD platform as a shared, governed service that other teams consume rather than each rebuild. Security and identity leaders set the policy and the vetting bar; platform engineering operates the registry and the onboarding lifecycle; product teams publish and consume servers within those guardrails.

The lifecycle is concrete: a server is proposed, reviewed against the vetting bar, approved and published with full entry metadata, pinned to a version, made discoverable to entitled consumers, monitored through audit, and re-reviewed on each version change or eventually deprecated. Ownership without this lifecycle decays into an unmaintained list. This operating-model clarity is something most published guidance omits, and it is often the difference between a registry that holds the line and one that quietly rots.

Build vs. buy: evaluating an MCP registry

You can build a metadata registry. The open API and metadata-only model make a minimal directory genuinely achievable for a capable platform team. The hard part is not the directory. It is everything in the governance framework above. Evaluate any approach, internal or vendor, against this checklist:

• Security - verified namespacing, integrity hashing, version pinning, and re-review on change.
• Governance - mandatory vetting, approval workflow, and per-entry metadata as defined above.
• Access control - identity-based, least-privilege, on-behalf-of authorization for agents, not shared keys.
• Discoverability - a clean catalog and self-service onboarding for entitled consumers.
• Federation - the ability to mirror and extend public registries without forking the ecosystem.
• Compliance posture - audit logging and policy enforcement that map to your regulatory obligations.

If a build effort can credibly deliver all six and you have the platform capacity to operate them, build. If the governance, identity, and compliance layers are where you would spend most of your effort, that is precisely the part worth buying. agen.co's enterprise MCP gateway and registry deliver the vetted catalog, identity-based access, audit, and policy enforcement as one governed system, so platform teams stand up a private, controlled registry without rebuilding the control plane from scratch. Explore the agen.co MCP gateway directory to see how a governed catalog is presented to consumers.

Frequently asked questions

What is an MCP registry?

An MCP registry is a metadata service that catalogs Model Context Protocol servers so clients and agents can discover them, resolve their connection details, and verify their provenance. It stores metadata, not server code, and for an enterprise it functions as a control plane that governs which trusted servers agents may use.

What is the difference between an MCP registry and an MCP catalog?

A registry is the underlying metadata index with naming, versioning, and provenance. An MCP catalog is the curated, presented view of approved servers built on top of a registry, often the enterprise-facing surface that internal teams browse and adopt from.

Is the public MCP registry safe to use in an enterprise?

The public registry is fine as ecosystem context for discovering open servers, but it is not enterprise-safe on its own. It offers no per-consumer access control, vetting, audit, or policy enforcement, and its own documentation states it does not support private servers. Enterprises should consume it through a governed private registry.

Do I need a private (internal) MCP registry?

If you run MCP-based agents that touch internal systems or regulated data, yes. The public registry deliberately excludes private servers and recommends self-hosting, so a private registry is the only way to host internal servers and enforce identity, access, audit, and policy over them.

How do agents discover MCP servers through a registry?

Agents and clients query the registry's REST API to enumerate available servers and resolve their connection details. In an enterprise registry, discovery is scoped by identity, so an agent sees only the servers it is entitled to use.

How does an MCP registry verify server authenticity and prevent impersonation?

Through verified namespacing. Servers are named with a reverse-DNS convention, and ownership is proven via GitHub OAuth or a DNS TXT challenge before publishing. Combined with immutable version strings and integrity hashes, this stops an attacker from publishing under a namespace they do not control or silently altering an approved version.

What is the difference between an MCP registry and an MCP gateway?

A registry is the index that decides what is trusted and discoverable; an MCP gateway is the runtime proxy that enforces identity, access, and policy on every live connection. The registry is the control plane's decision layer; the gateway is its enforcement layer. Enterprises run them together.

Who should own the MCP registry in an organization?

Platform engineering should own and operate it as core infrastructure, with security and identity leaders setting the vetting and policy bar. Product teams publish and consume servers within those guardrails.

How do agents authenticate to MCP servers?

Through OAuth-based flows with PKCE, least-privilege scopes, and on-behalf-of delegation, so an agent acts with scoped, time-bound authority rather than a static shared key. A dedicated identity layer for AI agents handles agent authentication, least-privilege authorization, and multi-tenant onboarding.

How do I build or buy an enterprise-grade MCP registry?

Evaluate any option against six criteria: security, governance, access control, discoverability, federation, and compliance posture. A minimal directory is buildable, but the governance, identity, and compliance layers are the hard part and the part most worth buying. If you can credibly deliver and operate all six in-house, build; otherwise buy the control plane.

Related resources

• What is a skills registry - the adjacent concept for managing the skills, rather than the tools, an AI agent can use.
• MCP security - the full threat model and the registry-level controls that contain it.
• MCP catalogs guide - finding, curating, and presenting approved MCP servers to internal teams.
• MCP platform - running MCP at enterprise scale, of which the registry is one layer.
• MCP servers - what the registry actually indexes: how MCP servers work and connect.

If your team is standing up a governed private registry and weighing build versus buy, see how agen.co's enterprise MCP gateway and registry bake identity, authorization, audit, and compliance into every connection. Browse the agen.co MCP gateway directory.