The official MCP Registry says it directly: “The MCP Registry does not support private servers,” and recommends teams “host your own private MCP registry and add them there” instead (The MCP Registry, Model Context Protocol). Not a governance philosophy. A documented scope limitation, and the reason the public-versus-private question exists at all.
Registry choice runs on a spectrum: public-only for well-known, already-verified servers; a curated allowlist on top of that; fully private for anything touching internal-only systems, schemas, or regulated data. Azure API Center and Docker’s custom MCP catalogs already ship production patterns for the private and hybrid ends of that spectrum, and the postmark-mcp incident from September 2025, the first publicly documented malicious MCP server, is the clearest publicly documented evidence that registry presence was never registry vetting.
| Dimension | Official public registry | Private / enterprise registry |
|---|---|---|
| Who runs it | Community-run, backed by Anthropic, GitHub, PulseMCP, Microsoft | Your organization, self-hosted or vendor-provided |
| Private servers | Explicitly not supported | The core use case |
| Admission check | Namespace authentication only | Org-defined, can include manual review |
| Security vetting | Identity check only, not a vetting signal | Whatever the org builds on top |
| Maturity | Preview status, API stable since 2025-10-24 | Vendor-dependent (Azure, Docker, self-hosted forks) |
| Best fit | Small teams, low-sensitivity tooling | Internal-only servers, regulated data |
Public vs. private MCP server registry: what’s the difference?
A public registry indexes what any server publisher submits under its own trust model. A private registry restricts what a given organization’s clients can even discover. The official registry is explicit about which job it does: it accepts servers as long as the installation method or the server itself is publicly reachable, nothing narrower. “Private servers are those that are only accessible to a narrow set of users,” the documentation says, giving examples like a server on a private network or a private package registry (The MCP Registry, Model Context Protocol).
That non-goal traces to how the registry started: a grassroots project from February 2025 that launched in public preview on September 8, 2025 with “16 contributing individuals from at least 9 different companies,” backed by Anthropic, GitHub, PulseMCP, and Microsoft, built as “a primary source of truth for publicly available MCP servers” for downstream aggregators, not end users (Introducing the MCP Registry, MCP Blog).
Most of the confusion is a naming problem, showing up across adjacent questions: what an AI agent registry is, how it differs from an MCP registry, and how it differs from a model registry. The bridge is real: the official registry publishes an OpenAPI spec other registries, including private ones, can implement. A private MCP server registry that speaks that spec is a use of infrastructure the project itself publishes for exactly this purpose, not a workaround. For when a formal registry earns its keep versus pointing agents at servers directly, see MCP registry vs. ad hoc MCP usage.
What is the official MCP Registry?
The official MCP Registry is a community-run, spec-backed index of publicly available MCP servers, built as infrastructure for the ecosystem rather than a destination most people browse directly. Servers register through a standardized server.json schema, namespaced under a reverse-DNS pattern like io.github.username/server that ties every listing to a verified GitHub account or domain.
Admission is authentication, not review. The registry “uses namespace authentication to ensure that servers come from their claimed sources,” while security scanning is delegated to npm, PyPI, Docker Hub, and downstream aggregators, not performed centrally (The MCP Registry, Model Context Protocol). A server can be exactly who it claims to be and still ship malicious code, because those are two separate checks.
That trust model is deliberate. The registry is “not intended to be directly consumed by host applications,” and its codebase “is not designed for self-hosting” (The MCP Registry, Model Context Protocol). It’s infrastructure other things build on, the same way an MCP gateway sits between clients and servers, or ai agent tool use depends on a discovery layer most agents never see. The client-server mechanics sit in the MCP architecture deep dive; the scope limitation here is the deeper story it only touches in passing.
Core components of the official registry
- Namespace authentication: reverse-DNS namespace tied to a verified GitHub account or domain.
server.jsonschema: the metadata format every listed server publishes, reusable by private registries too.- Aggregator-first design: built for downstream tools to query on a cadence, not for direct human browsing.
- No private-server support: a documented non-goal, not a gap.
The registry entered a v0.1 API freeze on October 24, 2025, holding the interface stable “with no breaking changes” while the team gathers integration feedback for a future v1 (modelcontextprotocol/registry, GitHub). Stability at the API layer isn’t stability of the trust model; the scope limitation above held before the freeze and holds after it.
What is a private MCP server registry?
Where the official registry answers “what’s out there,” a private MCP server registry answers “what is my team allowed to use”: an organization’s own inventory of approved servers, self-hosted or vendor-provided, exposed only to its own clients. It exists precisely because the official registry never tried to answer that.
Two production examples already ship this. Azure API Center exposes a private MCP registry endpoint in the format https://<name>.data.<region>.azure-apicenter.ms/workspaces/default/v0.1/servers, configurable in VS Code and GitHub Copilot with access-management controls over who can view or use registered servers. Docker’s custom MCP catalogs let a team “restrict which servers your organization approves for use,” “add your organization’s private MCP servers alongside public ones,” and “control which server versions your team uses” (Docker MCP Catalog, Docker Docs).
Neither is a workaround; both follow the pattern the official registry’s own documentation points toward. An AI agent identity layer, similar in spirit to the public registry’s namespace authentication, is usually the first thing a private registry needs before anything in it can be trusted. Teams that get this far are usually ready to build MCP servers for enterprise data of their own.
Core components of a private registry
- Curated server list: an explicit allowlist instead of the full public catalog.
- Private server hosting: internal-only MCP servers, registered alongside or instead of public ones.
- Access management: control over which teams can view or use which servers.
- Version pinning: control over which server versions are approved.
A private registry solves discoverability inside one organization’s boundary. It doesn’t, alone, solve whether the server it discovers is safe, which is the gap the next section covers directly.
Public vs. private MCP registry: head-to-head comparison
The two models diverge on trust, scope, and who’s accountable when a listed server misbehaves, and converge more than the framing suggests once the dimensions sit side by side.
| Dimension | Official public registry | Private / enterprise registry |
|---|---|---|
| Admission check | Namespace authentication only | Org-defined, can include manual review, allowlisting |
| Code review before listing | None, delegated to npm, PyPI, Docker Hub | Org-defined, often mandatory |
| Internal-only servers | Not supported by design | Core use case |
| Discoverability | Any client querying the public index | Restricted to the org’s own clients |
| Version control | Publisher-managed | Org can pin or approve specific versions |
| Failure mode | A malicious server can pass namespace auth and still get listed | A misconfigured allowlist can still expose an unreviewed server internally |
| Who’s accountable | The package registry the server ships through | The organization operating the private registry |
The “failure mode” row isn’t hypothetical. In September 2025, a malicious npm package called postmark-mcp impersonated the real Postmark integration, built trust over 15 versions, then added a backdoor that secretly BCC’d every outgoing email to an attacker-controlled address; Postmark confirmed it had never published an official MCP server on npm at all (Security alert: malicious postmark-mcp npm package, Postmark). Namespace authentication would not have stopped that. Presence and vetting are different checks, a gap academic work on MCP security now names directly, proposing “centralized governance using private registries or gateway layers” while flagging “verifiable registries” as an open research problem (Securing the Model Context Protocol (MCP): Risks, Controls, and Governance, arXiv).
A platform team rolling out coding-agent tooling makes this concrete: engineers need well-known public servers and an internal server reading production schemas. The public registry solves discovery for the first, not the second, so the team adds a private registry scoped through ai agent access control. Registry presence answers whether a server is listed, never whether it deserves trust.
How do public and private MCP registries work together?
In practice, most organizations don’t pick a pole. They run something in between, and the spectrum between public-only and fully private is more useful than a binary choice.
The public-to-private MCP registry spectrum.
| Model | What’s exposed | Example implementation | Best for |
|---|---|---|---|
| Public-only | Full public catalog, no restriction | Direct queries against registry.modelcontextprotocol.io | Small teams, early experimentation |
| Hybrid / curated subset | A vetted slice of public servers plus private ones | Docker MCP Catalog custom catalogs | Most mid-to-large engineering orgs |
| Fully private | Nothing public exposed, entirely internal | Azure API Center private endpoint, self-hosted spec fork | Regulated industries, internal-only tooling |
Each row adds a piece on top of the last: an allowlist over the public catalog’s namespace-verified identities, then access control and hosting for internal-only servers reusing the same server.json schema, then full control once nothing public is exposed, trading away the shared index’s convenience. Public-only is enough with nothing internal-only to expose; private becomes necessary once internal servers, whether schemas, proprietary APIs, or GDPR- or HIPAA-scoped data, need controls beyond namespace authentication. Hybrid is where most rollouts land, and it’s also where ai agent scaling in production forces the question: a registry that worked for five servers rarely stays public-only at fifty.
How Atlan approaches MCP server governance
Registry choice answers which servers a client can discover. It doesn’t answer which context those servers are allowed to expose, and that’s the governance question upstream of any registry decision.
Organizations that solve the registry question and stop there run into the same problem one layer up. A server being listed, public or private, says nothing about whether the context it serves is accurate, current, or approved to leave its system of record. The postmark-mcp incident showed what happens when presence gets mistaken for vetting at the server level; the identical gap exists at the level of the context itself, a different problem from what any context catalog or semantic layer for AI agents solves.
Atlan’s context layer governs which context is trustworthy and approved to be exposed at all, covering access control, lineage, and approved sources, before it reaches a client through any interface, MCP included. MCP is one of several protocols it serves through, alongside APIs, SQL, search, and vector retrieval, which is also why agent registries and context layers and an MCP gateway compared against a context layer resolve to the same answer. A private registry restricts which servers are discoverable; Atlan’s governance model restricts which context, once discovered, is trustworthy enough to act on. Picking a registry model before deciding what governed context means for a context repository risks re-litigating the decision once that question surfaces anyway.
Registry presence was never the same as being safe to use
The public registry’s own scope statement is the fact worth carrying forward: it does not support private servers, stated plainly rather than left for a team to infer from a support ticket that goes nowhere. A private registry exists to answer the question the official one was never built to answer, and the real decision most teams face isn’t public versus private at all. It’s where on the spectrum, from a curated public subset to a fully internal catalog, an organization’s own mix of public and internal-only servers lands.
Given how many organizations already mix well-known public servers with internal-only ones, most production setups are likely to land hybrid rather than at either pole, and postmark-mcp is the clearest publicly documented evidence that registry presence alone was never a vetting signal, on the public registry or a private fork of it. As more organizations register internal servers and build enterprise-ready AI agents around them, the middle of that spectrum looks likely to become the default. The registry question and the governance question stay separate throughout: getting the official MCP registry decision right and getting the context engineering underneath it right are two different projects, and treating them as one risks rebuilding the second.
FAQs about public vs. private MCP server registries
1. What’s the difference between a public and a private MCP server registry?
A public registry indexes servers any publisher submits under a namespace-authentication trust model. A private registry restricts what a specific organization’s clients can discover: a curated public subset, an internal-only inventory, or both.
2. Can I publish a private MCP server to the official MCP Registry?
No. Its documentation states it does not support private servers, meaning anything accessible only to a narrow set of users, like an internal network or private package registry, and recommends self-hosting a private registry instead.
3. Does the official MCP Registry vet or scan servers before listing them?
Not in the way “vetting” usually implies. Admission is namespace authentication only, confirming a publisher owns the claimed GitHub account or domain. Security scanning is delegated to npm, PyPI, and Docker Hub, not performed centrally.
4. Do I need a private MCP registry if I only use a handful of MCP servers?
Usually not, if every server is well-known and already public. A private registry earns its cost once you have internal-only servers, need controls beyond namespace authentication, or want to restrict which public servers your team can discover.
5. How do I set up a private MCP server registry for my organization?
Two paths ship today. Azure API Center exposes a private registry endpoint that VS Code and GitHub Copilot can query directly. Docker’s custom MCP catalogs let you restrict the public catalog and add private servers, or self-host a fork of the official spec.
6. What is a “hybrid” MCP registry?
A hybrid registry sits between public-only and fully private, exposing a curated public subset, an organization’s own private servers, or both, through one surface. Most production rollouts land here, not at either pole.
7. What happened with the postmark-mcp malicious server incident, and what does it change?
An npm package called postmark-mcp impersonated the real Postmark integration, building trust across 15 versions before a hidden backdoor began copying outgoing emails to an attacker-controlled address. It’s the clearest public evidence that listing and vetting are separate checks.
8. Do Azure API Center or Docker offer a private MCP registry today?
Yes, both ship this now. Azure API Center provides a private MCP registry endpoint with access-management controls, usable from VS Code and GitHub Copilot. Docker’s custom catalogs let an organization restrict, curate, and add private servers to its default catalog.
9. Is registry presence the same as a server being safe to use?
No. Registry presence, public or private, confirms a server’s namespace identity, not the safety of its code. The postmark-mcp incident passed namespace authentication and still shipped a malicious payload.
10. How does namespace authentication work in the official MCP Registry?
Servers register under a reverse-DNS namespace, such as io.github.username/server, tied to a verified GitHub account or domain. This confirms the publisher controls that account or domain, but doesn’t review the server’s code, which package registries handle separately.
