--- title: "What Is an MCP Registry? Server.json, Namespaces & Trust" url: "https://atlan.com/know/ai-agent/what-is-an-mcp-registry/" description: "An MCP registry catalogs Model Context Protocol servers via server.json and reverse-DNS namespaces. See how the official MCP Registry works, and what it skips." author: "Emily Winks" author_role: "Data Governance Expert" published: "2026-09-25" updated: "2026-09-25T00:00:00.000Z" --- --- An MCP registry is a catalog that lets AI clients discover Model Context Protocol servers and the data they connect to. Any MCP server, including Atlan's own, can be listed there. The official MCP Registry, the single project at registry.modelcontextprotocol.io, stores each server's metadata in a `server.json` file under a verified, reverse-DNS namespace, and its REST API entered a version freeze on October 24, 2025 ahead of general availability. The mechanics below cover how that registry actually works, what it explicitly does not do, and how it differs from a private registry, an MCP gateway, and ad hoc MCP usage. ### Check Whether This Registered Server Is Trustworthy Give it the registry type, what the server does, and how its output gets used. It returns what registration actually verified and what it never checked. [Read the skill](/skills/mcp-registry-trust-check.md). *Paste into a new chat* ``` Use the skill at https://atlan.com/skills/mcp-registry-trust-check.md to check whether a registered MCP server is actually trustworthy. Ask me for whatever it needs. ``` *Run once in a terminal* ``` curl -fsSL --create-dirs \ -o ~/.agents/skills/mcp-registry-trust-check/SKILL.md \ https://atlan.com/skills/mcp-registry-trust-check.md ``` *For an agent* ``` curl -fsSL https://atlan.com/skills/mcp-registry-trust-check.md ``` Human Agent ClaudeChatGPTGeminiCursorOther Copy .skp{margin:1.75rem 0;padding:1rem 1.125rem 1.125rem} .skp h3{margin:0 0 .375rem!important;font-size:20px!important;line-height:24px!important; font-family:var(--font-funnel-display)!important;font-weight:600!important;color:#2B2B39!important} .skp > p{margin:0 0 .875rem!important;font-size:14px!important;line-height:22px!important;color:#555572!important} .skp > p a{color:#2026D2;text-decoration:underline} .skp-box{margin-bottom:.75rem} .skp-p em{display:block;font-size:10px;font-weight:700;letter-spacing:.06em;text-transform:uppercase; color:#F34D77;font-style:normal;margin-bottom:.25rem} .skp-p > p{margin:0!important} #seo-layout article .skp .skp-p pre{margin:0!important;overflow-x:auto} #seo-layout article .skp .skp-p pre code{color:#2B2B39!important;font-size:12px!important;line-height:19px; white-space:pre-wrap;overflow-wrap:anywhere;background:none;padding:0; font-family:ui-monospace,SFMono-Regular,Menlo,monospace} .skp-p + .skp-p{margin-top:.625rem} .skp-cs{display:flex;flex-wrap:wrap;align-items:center;gap:.375rem} .skp-seg{display:inline-flex;flex:0 0 auto;border:1px solid #DDDDE3;border-radius:999px;overflow:hidden;background:#fff} .skp-m{min-height:32px;padding:.25rem .75rem;border:0;background:transparent;font-family:inherit;color:#77778E;cursor:pointer} .skp-m:hover{color:#2026D2} .skp-m.on{background:#2026D2;color:#fff} .skp-sep{flex:0 0 auto;width:1px;height:20px;background:#DDDDE3;margin:0 .25rem} .skp-tools{display:inline-flex;flex-wrap:wrap;gap:.375rem;min-width:0} .skp-cp{margin-left:auto;min-height:32px;padding:.25rem .75rem;border-radius:999px;background:#fff; font-family:inherit;color:#555572;cursor:pointer} .skp-cp:hover{border-color:#2026D2!important;color:#2026D2} .skp-cs .skp-c{display:inline-flex!important;width:auto;flex:0 0 auto;align-items:center;gap:.375rem; min-height:32px;padding:.25rem .625rem;border-radius:999px;background:#fff;font-family:inherit; color:#555572;cursor:pointer} .skp-cs .skp-c img{display:block!important;width:14px!important;height:14px!important; max-width:14px!important;flex:0 0 auto;opacity:.55;margin:0} .skp-c:hover img,.skp-c.on img{opacity:1} .skp-cs .skp-c:hover{border-color:#797DE4!important;color:#2026D2} .skp-cs .skp-c.on{border-color:#2026D2!important;background:#F4F4FD;color:#2026D2} .skp-agent .skp-tools,.skp-agent .skp-sep{display:none} (function(){ var p=document.querySelector('.skp[data-skill="mcp-registry-trust-check"]');if(!p)return; var panes=p.querySelectorAll('.skp-p'); function show(id){panes.forEach(function(x){x.hidden=x.dataset.skp!==id;});} function cur(){var a=p.querySelector('.skp-p:not([hidden]) pre code');return a?a.textContent:'';} show('prompt'); p.querySelectorAll('.skp-p em').forEach(function(e){ var par=e.parentElement; ((par.tagName==='P'&&par.textContent.trim()===e.textContent.trim())?par:e).hidden=true; }); p.querySelectorAll('.skp-c').forEach(function(b){ b.addEventListener('click',function(){ p.querySelectorAll('.skp-c').forEach(function(x){var on=x===b;x.classList.toggle('on',on);x.setAttribute('aria-pressed',on);}); show(b.dataset.skp); }); }); p.querySelectorAll('.skp-m').forEach(function(m){ m.addEventListener('click',function(){ var agent=m.dataset.skpMode==='agent'; p.classList.toggle('skp-agent',agent); p.querySelectorAll('.skp-m').forEach(function(x){var on=x===m;x.classList.toggle('on',on);x.setAttribute('aria-pressed',on);}); if(agent){show('agent');}else{var s=p.querySelector('.skp-c.on');show(s?s.dataset.skp:'prompt');} }); }); var c=p.querySelector('[data-skp-copy]'); c.addEventListener('click',function(){ navigator.clipboard.writeText(cur()).then(function(){ c.textContent='Copied';setTimeout(function(){c.textContent='Copy';},1600); }); }); })(); --- A registry answers one question: does this server exist, and where can a client find it. It does not answer whether the data that server returns is current, owned by anyone, or safe to act on, and that distinction runs through everything below. * **"An MCP registry" and "the MCP Registry" are not the same thing.** The first is any catalog of MCP servers. The second is one specific, official project. * **The registry is scoped narrowly on purpose.** It does not scan for security issues itself, does not support private servers, and was never meant for a host application to query directly. * **Registration is a discovery signal, not a trust signal.** A listed server has a verified publisher namespace. It says nothing about whether the server's underlying data is governed. | What it is | Governed by | Launched | Cost | Core format | Does NOT support | | --- | --- | --- | --- | --- | --- | | A catalog of MCP servers that AI clients can discover | Anthropic, GitHub, PulseMCP, and Microsoft as backing maintainers of an open community project | Preview, September 8, 2025; REST API froze at v0.1 on October 24, 2025 | Open and free to publish to | `server.json` per entry, under a reverse-DNS namespace | Private or internal-only servers; direct consumption by host applications; self-hosted forks with maintainer support | --- ## What is an MCP registry? A registry, in the general sense, is a discovery catalog. It is not the [Model Context Protocol](https://atlan.com/know/what-is-model-context-protocol/) itself, and not the runtime connection between a client and a server, which the [MCP architecture deep dive](https://atlan.com/know/ai-agent/mcp-architecture-deep-dive/) covers in full. A registry sits alongside the protocol, listing which servers exist so a client knows what to connect to. The core [MCP specification](https://modelcontextprotocol.io/specification/2025-06-18/basic), dated 2025-06-18, defines the base protocol, lifecycle management, authorization, and server and client capabilities. It never defines a registry: discovery is a separate ecosystem project layered on top, which is why "an MCP registry" and "the MCP Registry" need to be told apart first. **"An MCP registry"** (lowercase, general) is any catalog of MCP servers: official, vendor-run, or self-hosted. **"The MCP Registry"** (capitalized, specific) is the one official community project, launched in preview on September 8, 2025 and backed by Anthropic, GitHub, PulseMCP, and Microsoft as its named maintaining organizations, according to the Model Context Protocol's own [preview announcement](https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/). An MCP registry is also a different animal from an [AI agent registry](https://atlan.com/know/ai-agent/what-is-an-ai-agent-registry/), a [model registry](https://atlan.com/know/ai-agent/agent-registry-vs-model-registry/), or the vendor-specific case of an [AWS agent registry](https://atlan.com/know/ai-agent/aws/what-is-aws-agent-registry/); [what is AI registry](https://atlan.com/know/what-is-ai-registry/) covers that broader category, and [agent registry vs. MCP registry](https://atlan.com/know/ai-agent/agent-registry-vs-mcp-registry/) covers the specific comparison in depth. The registry answering "does this exist" instead of "can this be trusted" is not a gap in an early product. It is the boundary the official project draws around itself deliberately, and the next two sections show exactly where that boundary sits. --- ## How does the MCP Registry work? The MCP Registry stores each server's metadata as a `server.json` file, identified by a reverse-DNS namespace the publisher had to verify, and reachable through a versioned REST API that any MCP client or aggregator can query. Three mechanisms carry the weight: the schema, the namespace, and the API version itself. ### The `server.json` schema According to the official [MCP Registry documentation](https://modelcontextprotocol.io/registry/about), server metadata is stored in a standardized `server.json` format defined by a published [JSON schema](https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/server-json/draft/server.schema.json). The core fields: | Field | What it captures | Example value | | --- | --- | --- | | `name` | The server's unique, namespaced identifier | `io.github.acme/weather-server` | | `packages` / `remotes` | Where to find and run it: an npm package, a Docker image, or a remote URL | `npm: @acme/weather-mcp` | | `version` | The published release version of that server entry | `1.2.0` | | `description` | Short, discovery-facing summary of what the server does | "Weather data via MCP" | The registry does not host the server's code. It hosts metadata that points to where the code already lives, on npm, PyPI, Docker Hub, or a public remote URL, in the same way a library catalog card points to a shelf rather than containing the book. A server that exposes lineage or catalog data, the kind covered in [MCP-connected data catalog](https://atlan.com/know/mcp-connected-data-catalog/), lists the same way: a `server.json` entry, nothing more. ### Reverse-DNS namespaces and authentication Every server name follows a reverse-DNS format, such as `io.github.username/server-name` or `com.example/server-name`, tied to a verified GitHub account or domain. According to the official docs, this namespace system ensures only the legitimate owner of that account or domain can publish under it, which prevents impersonation and name-squatting. A separate [AI agent identity](https://atlan.com/know/ai-agent/ai-agent-identity/) concern, who or what is acting on a system's behalf at runtime, sits one layer up from this publisher-identity question. ### API versioning and the v0.1 freeze The registry's REST API entered a freeze at version v0.1 on October 24, 2025, ahead of general availability, per the [MCP Registry's GitHub repository](https://github.com/modelcontextprotocol/registry). That versioning detail matters more for the aggregators and marketplaces built on top of the registry than for a reader evaluating whether to use it directly. A server appearing correctly in `server.json`, under a verified namespace, on a versioned API, tells a client one thing: this server is real and reachable. What it does not tell a client is covered next. --- ## What does the MCP Registry not do? The official registry limits its own scope on purpose, and it says so directly in its own documentation rather than leaving the boundary implicit. Four things it explicitly does not do: | It does not | Why, per the official docs | What to use instead | | --- | --- | --- | | Support private or internal-only servers | Scoped to servers that are publicly accessible or publicly installable; private-network servers are explicitly excluded | Run a private registry (see the section below) | | Perform its own security scanning of listed servers | Delegates scanning to the underlying package registries (npm, PyPI, Docker Hub) and to downstream aggregators, rather than duplicating it | Vet a server through its package registry's own scanning, or an aggregator that adds curation | | Get consumed directly by host applications | Built to be consumed by downstream aggregators and marketplaces via its REST API, not queried directly inside a chat client | Consume through a downstream aggregator implementing the registry's OpenAPI spec | | Ship as a self-hostable, maintainer-supported fork | The codebase is not designed for self-hosting, and the maintainers cannot support that use case | Build or buy a purpose-built private registry instead of forking the official one | All four rows trace to the same primary source: the official [MCP Registry documentation](https://modelcontextprotocol.io/registry/about), which states plainly that the registry "does not support private servers," "is not intended to be directly consumed by host applications," and has a codebase "not designed for self-hosting." This is the registry's own stated shape, and the practical trigger that pushes most enterprise teams toward a [private MCP server registry](https://atlan.com/know/ai-agent/public-vs-private-mcp-server-registry/) the moment they need to list anything inside a firewall. Being listed answers existence, and existence is not the same as being current, owned, or correct, a distinction that becomes unavoidable once the growth of [agent sprawl](https://atlan.com/know/ai-agent/agent-sprawl/) across a large organization, or [orchestrating multiple agents](https://atlan.com/know/multi-agent-system-orchestration/) against the same listed servers, forces the question of which listed entries can actually be trusted at runtime. The same question sits underneath broader [AI agent governance](https://atlan.com/know/ai-agent-governance/), including the practicalities of [governing agents across multiple clouds](https://atlan.com/know/ai-agent/how-to-govern-ai-agents-across-multiple-clouds/), once more than a handful of registries are in play. --- ## MCP registry vs. MCP gateway: what's the difference? Discovery and traffic management solve different problems, and conflating a registry with a gateway is the most common confusion in this space. A registry helps a client find a server it does not yet know about. A gateway sits in front of servers a client already knows about, routing, authenticating, and managing traffic to them once discovery is done. Discovery happens before a connection exists; a gateway operates after one does, and the two often sit in the same stack: find a server through a registry, then reach it through a gateway that adds authentication and centralized routing. That gateway is a specific case of the broader [AI gateway / LLM gateway](https://atlan.com/know/what-is-ai-gateway-llm-gateway/) category, scoped to MCP traffic. For the full mechanics and when a single [MCP server](https://atlan.com/know/mcp-server-implementation-guide/) stops being enough, see [what is an MCP gateway](https://atlan.com/know/ai-agent/what-is-an-mcp-gateway/) and [MCP gateway vs. a single MCP server](https://atlan.com/know/ai-agent/mcp-gateway-vs-single-mcp-server/); for how a gateway relates to a governed context layer, see [MCP gateway vs. context layer](https://atlan.com/know/ai-agent/mcp-gateway-vs-context-layer/). --- ## Do you need the official MCP registry, or should you build your own? The official registry's own non-support for private servers is the practical trigger most enterprise teams hit first: the moment a server lives on an internal network or a private package feed, the public registry is out of scope, and a team needs its own. Two named approaches illustrate what that looks like. Docker's [MCP Catalog](https://docs.docker.com/ai/mcp-catalog-and-toolkit/catalog/) supports custom catalogs that let a team add its own private servers alongside public ones. Microsoft's [Azure API Center](https://learn.microsoft.com/en-us/azure/api-center/register-discover-mcp-server) registers remote and local MCP servers, including ones that never leave an internal network, through its own MCP registry endpoint. The same public-versus-private split shows up one layer up the stack in [agent skills registry](https://atlan.com/know/ai-agent/ai-agent-skills/agent-skills-registry/), a parallel discovery pattern for a different artifact type. Neither example resolves the harder question of when a formal registry is worth building at all versus when a small team can keep track of a handful of servers informally. That decision, with the team-size and governance thresholds that actually separate the two, is covered in [MCP registry vs. ad hoc MCP usage](https://atlan.com/know/ai-agent/mcp-registry-vs-ad-hoc-mcp-usage/). --- ## Registered doesn't mean trustworthy Being listed confirms two things: a server exists, and a verified publisher put it there. It confirms nothing about whether the data that server returns is current, owned by a specific team, or correct at the moment an agent calls it. That gap is not a flaw in the MCP Registry specifically. It is what any discovery catalog, official or private, is built to leave open, because discovery and data quality are different problems solved by different layers. An MCP server itself, including [Atlan's own MCP server](https://atlan.com/know/what-is-atlan-mcp/), is exactly the kind of thing a registry, public or private, would list: a namespaced entry with a `server.json` pointing to where it runs. Whether what that server returns is governed, carrying real lineage, ownership, and certification rather than a bare schema name, is a separate concern from whether it is discoverable at all. That is the question [delivering business context through MCP](https://atlan.com/know/mcp-delivers-business-context/) answers, and the same distinction [MCP for data lineage](https://atlan.com/know/mcp/mcp-for-data-lineage/) and [why MCP matters for AI agents](https://atlan.com/know/mcp/why-mcp-matters-for-ai-agents/) cover for MCP specifically, and [whether agent registries need a context layer](https://atlan.com/know/ai-agent/context-layer/do-agent-registries-need-a-context-layer/) covers for registries generally. A reader who now understands namespaces, `server.json`, and the registry's own stated non-goals has answered "does this server exist." Whether to trust what it returns once an agent actually calls it is a question that starts with the [enterprise context layer](https://atlan.com/know/what-is-the-enterprise-context-layer/), not with the registry entry. --- ## FAQs about MCP registries ### 1. What is the official MCP Registry? The official MCP Registry is the community-run catalog at registry.modelcontextprotocol.io, backed by Anthropic, GitHub, PulseMCP, and Microsoft, that stores metadata about publicly accessible Model Context Protocol servers. It launched in preview on September 8, 2025 and is meant to be consumed primarily by downstream aggregators and marketplaces, not queried directly by a chat client. ### 2. How do you publish a server to the MCP registry? A publisher verifies ownership of a namespace, tied to a GitHub account or a domain, then submits a `server.json` file describing the server's name, where to find it (an npm package, a Docker image, or a remote URL), and its version. The server's installation method or the server itself must be publicly accessible; the registry does not accept private-only entries. ### 3. Is the MCP Registry the same as an MCP marketplace? No. The MCP Registry hosts raw, unopinionated metadata. A marketplace is a downstream aggregator that pulls from the registry's API and layers curation, ratings, or search on top. The registry is explicitly built to feed marketplaces rather than to function as one itself. ### 4. What's the difference between an MCP registry and an MCP gateway? A registry helps a client discover a server it does not yet know about; a gateway sits in front of servers a client already knows about to handle routing, authentication, and traffic management. Discovery happens before a connection exists; a gateway operates once one does, and the two commonly work together in the same stack. ### 5. Does the MCP Registry support private or internal servers? No. The official registry explicitly excludes servers restricted to a narrow set of users, such as ones on an internal network or a private package feed, and recommends that organizations needing that host their own private registry instead. ### 6. Do you need to use the official MCP Registry, or can you run your own? Both are valid. The official registry fits publicly discoverable servers. An organization with internal-only servers needs a private registry by definition, since the official one does not support that case; Docker and Microsoft are two vendors offering private-registry approaches built for it. ### 7. Is being listed in the MCP Registry the same as being verified or trustworthy? No. A listing confirms the server exists and that its publisher namespace was verified, nothing more. It does not confirm the server's underlying data is current, correctly owned, or safe to act on, which is a governance question the registry was never designed to answer. --- ## Sources 1. [The MCP Registry, official documentation](https://modelcontextprotocol.io/registry/about) 2. [Introducing the MCP Registry, September 8, 2025, Model Context Protocol blog](https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/) 3. [modelcontextprotocol/registry, GitHub repository](https://github.com/modelcontextprotocol/registry) 4. [server.json schema reference, modelcontextprotocol/registry GitHub](https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/server-json/draft/server.schema.json) 5. [MCP specification, 2025-06-18, Basic overview](https://modelcontextprotocol.io/specification/2025-06-18/basic) 6. [MCP Catalog, Docker documentation](https://docs.docker.com/ai/mcp-catalog-and-toolkit/catalog/) 7. [Inventory and discover MCP servers in your API Center, Microsoft Learn](https://learn.microsoft.com/en-us/azure/api-center/register-discover-mcp-server)