The MCP Registry is the official catalog where Model Context Protocol servers are listed, indexed, and made discoverable to clients across the ecosystem. It launched in public preview on September 8, 2025, with the v0.1 REST API entering a freeze on October 24, 2025, and is backed by Anthropic, GitHub, PulseMCP, and Microsoft. This article is a practical reference for developers who need to find trustworthy MCP servers, read their server.json metadata, understand how the registry federates with sub-registries, and publish their own servers. It assumes basic familiarity with MCP primitives such as tools, resources, and transports, and focuses on the registry layer rather than server implementation. Where claims depend on a preview-stage API, the text flags the version sensitivity explicitly.
The MCP Registry is the official centralized metadata repository for publicly accessible Model Context Protocol servers. It launched in public preview on September 8, 2025, and on October 24, 2025 its v0.1 REST API entered a freeze, meaning the API will remain stable for at least a month with no breaking changes while real-world integrations are validated. Until the project reaches general availability, breaking changes and even data resets remain possible, so any code written against the registry today should be treated as version-sensitive. The project is backed by Anthropic, GitHub, PulseMCP, and Microsoft, and the live service is reachable at https://registry.modelcontextprotocol.io (modelcontextprotocol.io/registry/about, GitHub: modelcontextprotocol/registry).
Two boundaries define the registry's scope and are worth stating before any schema or API discussion:
server.json documents describing how to locate and run a server — package references, transport hints, endpoint URLs, and declared capabilities. The actual server binaries and source code remain in external package registries such as npm or PyPI. The registry explicitly delegates security scanning to those upstream package registries; it tells you who published something, not whether it is safe to run.mcp.acme-corp.internal or packages fetched from an internal Artifactory — are explicitly out of scope. The official guidance for such cases is to host a private MCP registry and add those servers there.The official codebase is not designed for self-hosting, and the registry maintainers cannot provide support for self-hosted deployments. Organizations that need a private mirror must fork the codebase and operate the fork independently. The OpenAPI specification, however, is part of the public MCP project, and any compatible sub-registry — public marketplace or private enterprise catalog — can implement that same interface and benefit from existing host-application support.
The registry follows a "discovery, not execution" principle. It stores endpoint URLs, transport hints, and authentication requirements, but it does not proxy runtime traffic and does not run servers itself. Clients use the registry to find servers, then connect to them directly. Public sub-registries and marketplaces may pull registry data, enrich it with ratings or curation, and expose opinionated views to their end users, but the central registry remains a metadata layer rather than a runtime.
Every entry in the MCP Registry is described by a server.json document validated against a single official schema. The schema is the contract that lets clients, aggregators, and sub-registries parse a listing without prior knowledge of the publisher. The registry performs basic validation against this schema and enforces unique namespaces, which is what keeps the catalog machine-readable across vendors (MCP Registry server.json Format; MCP Registry for Enterprise AI).
The name field is the entry's unique identifier and the only field the registry treats as a primary key. Names follow a reverse-DNS convention that ties them to a verified identity:
io.github.username/server-name — proven by control of the GitHub account.com.example/server — proven by DNS ownership of the domain.Only the legitimate owner of the underlying GitHub account or domain can publish under that namespace, which is how the registry provides provenance without re-running identity checks for every client (MCP Registry Trust and Authentication). A namespace, once claimed, cannot be reused by a different publisher.
The location group tells a client where to obtain the server binary or endpoint. Typical values are an npm package name, a container image, or a remote server URL reachable over Streamable HTTP or SSE. Importantly, the registry stores metadata about the location but does not run the server or proxy runtime traffic — discovery and execution are deliberately separate concerns (MCP Registry for Enterprise AI).
The execution fields describe how to start the server once fetched. This includes the command to invoke, command-line arguments, and any required environment variables. Clients use this group to generate install commands or render configuration UIs without having to inspect package internals.
The discovery group contains everything that helps a developer decide whether to install the server: a description, declared capabilities, transport protocols, version information, icons, and authentication requirements. Because this metadata is also what shows up in catalog UIs, it tends to evolve most often and is the area most likely to gain new optional fields before v1.
The Registry API entered a v0.1 freeze on October 24, 2025, after a public preview launch on September 8, 2025 (MCP Registry). Integrators writing against server.json today should pin to the v0.1 snapshot, because the v1 GA release may evolve field semantics — particularly in the discovery group. The registry also explicitly does not vet code; it delegates security scanning to the underlying package registries and does not accept private servers, so a server.json confirms provenance, not safety (Best MCP Servers for Developers 2026; MCP Registry and Server Developers).
The MCP Registry does not replace npm, PyPI, or Docker Hub. It sits one layer above them as a metadata catalog. Package registries continue to host the actual server code, binaries, and signed artifacts; the MCP Registry stores server.json documents that point at those packages by name and version. A concrete illustration from the official documentation: a weather-mcp package can live on npm, while the registry entry maps the logical server weather v1.2.0 to npm:weather-mcp. The registry's job is discovery and standardized configuration — the server.json schema records a unique reverse-DNS name, a server location (npm package name, Docker image, or remote URL), execution instructions, and discovery data such as declared capabilities (modelcontextprotocol.io/registry/about).
Because install paths still resolve through the underlying package manager, anything you already do for npm or PyPI keeps working. Version pinning, lockfiles, npm ci reproducibility, integrity hashes, and provenance attestations all apply to MCP server packages exactly as they do to any other dependency. The MCP Registry adds a discoverability surface on top, not a parallel delivery channel; clients typically read server.json, then invoke the package registry's normal install flow.
The registry explicitly does not run its own code review or vulnerability scanning. According to its documentation, security scanning is delegated to two parties: the underlying package registries (npm, PyPI, Docker Hub, and similar), and downstream aggregators or marketplaces that may layer additional checks, ratings, or curation on top (modelcontextprotocol.io/registry/about). What the registry does provide is provenance — reverse-DNS namespaces tie server names to a verified GitHub account or domain — but it tells you who published a server, not whether the code is safe to run.
Treat the package reference inside server.json as the ground truth. Let your existing package-management tooling handle verification, audit, SBOM generation, and version pinning rather than trusting registry metadata as a substitute for those controls. Given that the registry remains in preview and its schema is subject to change, pin package versions explicitly and prefer lockfile-driven installs over floating ranges.
A core architectural decision behind the MCP Registry is that it is intentionally not the only place to find them. The official registry acts as a canonical source of public MCP server metadata, while other registries build on top of it. This federation model preserves the existing ecosystem of community catalogs, client marketplaces, and private deployments without forcing everyone to depend on a single host. As the official documentation notes, the registry is "not intended to be directly consumed by host applications"; instead, hosts should consume downstream registries that conform to the registry's OpenAPI spec.
The registry's role is also narrowly scoped: it stores metadata, not server code. Package registries such as npm, PyPI, and Docker Hub continue to host binaries, while the MCP Registry maps names like weather-mcp v1.2.0 to those package references. That separation is what makes federation possible — anyone can publish a metadata entry, and anyone can index those entries.
Public sub-registries are opinionated "MCP marketplaces" associated with specific MCP clients. They are free to augment the data they ingest from the upstream MCP Registry with ratings, search filters, security audit information, or curation tailored to a particular audience. The launch announcement explicitly frames this as a way to avoid displacing registries that the community and companies have already built.
The GitHub MCP Registry is the clearest concrete example. GitHub works closely with Anthropic and the MCP Steering Committee on the open-source upstream, hosted at github.com/modelcontextprotocol/registry/. Developers self-publish servers there, and the entries automatically appear in the GitHub MCP Registry without a second submission. The stated benefits are:
Because both layers speak the same OpenAPI, MCP hosts that integrate with one integrate with both.
Enterprise registries merge public MCP entries with internally developed servers, then layer on governance, role-based access, and approval policies. The launch announcement describes this as the home for private sub-registries "within enterprises that have strict privacy and security requirements," with the public registry serving as a single upstream data source they can build upon.
A typical enterprise registry tracks, beyond the standard endpoint and transport fields:
Importantly, enterprise registries still expose a compatible API to MCP clients. Because the OpenAPI spec is shared, the same host implementation that works against the public catalog can be pointed at a private registry with minimal integration work. This is also why the upstream codebase is explicitly not designed for self-hosting; forks must be operated on their own, but they remain interoperable by reusing the standard schema.
For developers, federation means one publish can reach many surfaces, and one client integration can talk to many catalogs — provided every layer conforms to the same OpenAPI contract. The preview-stage nature of the v0.1 API (frozen on October 24, 2025) means the exact schema fields and aggregation rules may still shift, so consumers should pin to documented endpoints rather than rely on undocumented behavior.
Every published server starts with a server.json that conforms to the official schema. The schema captures a unique reverse-DNS name (for example io.github.username/server-name or com.example/server-name), the server's installation location (such as an npm package name or a remote URL), execution instructions (CLI args, environment variables), and discovery metadata (description, capabilities, version). Conforming to this schema is what lets downstream clients parse listings consistently.
The namespace prefix is not decorative. It must point to a publisher identity the registry can verify, so choose between a GitHub-based form (io.github.<account>/*) or a domain-based form (com.example/*) that you actually control before you begin authoring metadata.
The registry ties each namespace to a verifiable identity, and only the legitimate owner can publish under it. For GitHub-based namespaces, ownership is confirmed during sign-in via OAuth against the linked GitHub account. For domain-based namespaces, ownership is validated through DNS records or an HTTP verification challenge hosted on the domain. This step happens before submission and is what gives listings their provenance.
Once the server.json is ready and the namespace is verified, submit the file to the registry's REST API. The registry then runs a fixed pipeline:
server.json definition.Submissions that fail any of these checks are rejected with an error response, so publishers can iterate without leaving a broken record behind.
After acceptance, ongoing changes are handled by publishing new server.json revisions through the same API. Registry maintainers retain the right to manually remove spam or malicious entries under the moderation policy, so publishing is a recurring responsibility, not a one-time event.
A successful publish proves who put the listing in front of clients, not whether the underlying package is safe. The registry delegates security scanning to the underlying package registries, so inspect the npm package, container image, or remote endpoint before wiring a server into a production client. During the preview phase the API carries no durability guarantees and breaking changes are possible before general availability, so treat published metadata as version-sensitive.
The registry answers who published this and under what namespace, not is this code safe to run. Its own documentation states that security scanning is delegated to the underlying package registries (npm, PyPI, Docker Hub) and to downstream aggregators, so the catalog is a provenance layer, not a vetting service. Treat it as such: the namespace is the only thing the registry itself guarantees.
Start with the namespace. MCP server names follow a reverse-DNS format such as io.github.<username>/<server> or com.<example>/<server>, and the registry ties them to a verified GitHub account or domain via OAuth or DNS-based ownership checks. Before installing, confirm that the namespace actually resolves to the publisher you expect and that the linked GitHub organization or domain is under their control. A green namespace only proves the publisher is who they claim to be — not that their code is benign.
Most servers are distributed as npm or PyPI packages, so the package registry remains the primary trust boundary. Check the maintainers, recent commit or publish activity, download counts, and whether the version pinned in server.json still matches what is actually published. Be alert to typosquats and to recently transferred packages. One 2025 audit of 33 MCP repositories found that none of them published a Software Bill of Materials and the SBOM pass rate was 0%, which is the kind of gap package-level scanning cannot fully compensate for.
Read the server's declared tools, resources, and required environment variables against the principle of least privilege. A server that asks for a wildcard-scoped token, access to every repository you can see, or write access to sensitive paths deserves more scrutiny than one with a narrow, read-only mode. Note the transport as well:
Understanding which transport is in play determines where credentials live and which authentication surface you are exposing.
For production use, layer the public registry on top of an internal approval workflow. The catalog is not a substitute for code review, dependency scanning, signed releases, or change management. Federation helps here: enterprise sub-registries can apply their own governance while keeping the upstream API contract.
Because the registry is still pre-GA and the v0.1 REST API is in freeze, expect schema and metadata refinements before pinning tooling against it long-term.