The Model Context Protocol ecosystem has a discovery problem: as MCP adoption grows, clients need a reliable way to find servers, understand how to install or connect to them, identify who published them, and decide which metadata to trust.
The Official MCP Registry is the protocol ecosystem’s answer to that discovery problem. It is a centralized metadata repository for publicly accessible MCP servers, with standardized server identities, a REST API for discovery, namespace verification and a common server.json format for describing packages and remote endpoints.
But the Registry is not an app store, not a security certification and not the same thing as the new server/discover RPC introduced with MCP 2026-07-28. Those distinctions matter if you are building agents, MCP hosts, marketplaces or enterprise governance systems.
This guide explains how MCP Registry discovery works in 2026, what server.json contains, how namespaces are verified, how remote MCP servers are published, how aggregators consume Registry data and where the trust boundary really sits.
What Is the MCP Registry?
The MCP Registry is the official centralized metadata repository for publicly accessible Model Context Protocol servers. Server creators publish metadata to it; clients, directories and marketplaces can consume that metadata through a standardized API.
As of September 2026, the Registry documentation still labels the service as preview. That means breaking changes or data resets can still occur before general availability, so production systems should avoid treating the Registry as an infallible source of uptime or durable state.
The Registry solves four main problems:
- Identity: servers use namespaced identifiers tied to a verified GitHub account or domain.
- Metadata: installation, package and remote endpoint information is represented in a standardized schema.
- Discovery: clients and aggregators can search or enumerate server metadata through a REST API.
- Distribution: marketplaces and subregistries can ingest the official metadata and add their own ratings, scans or enterprise policy layers.
If you need the basic protocol architecture first, see Vynula’s What Is MCP? and MCP Client vs Server vs Host guides.
The Registry Stores Metadata, Not MCP Server Code
This is one of the most important concepts to understand. The Official MCP Registry does not host the server application itself.
For a packaged local server, the actual artifact may live in npm, PyPI, Docker Hub or another package registry. For a remote MCP server, the actual service runs at the publisher’s HTTPS endpoint. The MCP Registry stores the metadata that describes how a host can identify, install or connect to that server.
This design keeps the Registry lightweight and lets the ecosystem use existing package and hosting infrastructure rather than inventing a new artifact distribution system.
What Is server.json?
server.json is the standardized metadata document used when publishing an MCP server to the Registry. The official mcp-publisher tool can generate a template with mcp-publisher init.
A typical document includes fields such as:
$schema— the Registry schema used to validate the metadata.name— the globally namespaced MCP server identifier.title— an optional human-friendly display name.description— what the server does.version— the published server version.repository— source repository metadata where applicable.packages— package registry information for installable server artifacts.remotes— one or more remote MCP endpoints.
The important point is that server.json describes distribution and connection metadata. It is not the runtime protocol message sent on every MCP tool call.
Why Namespaced Server Names Matter
Random package names are not enough for an ecosystem where AI agents can execute tools. The Registry therefore uses namespace authentication.
Names follow reverse-domain-style patterns such as:
io.github.username/server-namecom.example/server-name
The namespace connects a published server identity to a verified GitHub owner or domain. The goal is not to prove that the code is secure; it is to make impersonation harder and create accountability around who is allowed to publish under a given namespace.
For GitHub-based publishing, the server name must correspond to the authenticated GitHub namespace. Domain owners can use DNS or HTTP-based authentication.
How Namespace Verification Works
The Registry supports multiple ways to prove control of a namespace. GitHub authentication is convenient for open-source projects. Domain-based publishers can verify ownership through DNS or HTTP.
With DNS authentication, the publisher proves domain control through a DNS TXT record. With HTTP authentication, a verification record is hosted under a well-known path such as /.well-known/mcp-registry-auth.
This prevents an unrelated publisher from casually registering a server as if it came from another company’s domain.
Publishing a Package-Based MCP Server
The standard publishing flow for a packaged server looks roughly like this:
- Publish the actual server artifact to an underlying package registry such as npm.
- Add package verification metadata, such as the expected
mcpNamewhere required. - Install the official
mcp-publisherCLI. - Generate and review
server.json. - Authenticate to the Registry using the namespace-appropriate method.
- Run
mcp-publisher publish.
The Registry validates the submitted metadata and publishes the server version into the discovery API if the required checks succeed.
Publishing Remote MCP Servers
Remote MCP is now a major part of the ecosystem. A hosted server can be described through the remotes property in server.json.
A remote entry can specify:
- the transport type, such as Streamable HTTP;
- the remote MCP URL;
- URL variables for tenants, regions or environments;
- headers or values that a host may need to supply;
- metadata that helps a compatible host configure the connection.
The Registry also allows packages and remotes to coexist, which means a server can offer both an installable local package and a hosted remote endpoint.
That is useful for products that want to serve both developers who prefer local deployment and users who prefer a managed hosted connection.
Remote Variables and Multi-Tenant Endpoints
A remote URL does not have to be a single fixed endpoint. Registry metadata can describe variables, allowing a client or user to supply values such as a tenant identifier or region.
For example, a multi-region provider could expose one server definition while letting the final URL resolve to a US, EU or APAC deployment based on a required variable.
This is metadata-driven configuration, not protocol-level service discovery inside the running MCP request itself.
MCP Registry API
The Registry exposes an unauthenticated read-only REST API for discovery consumers. The official documentation describes endpoints for listing servers, listing versions of a named server and retrieving a specific or latest version.
That API is intentionally useful to more than end-user clients. Marketplaces, enterprise catalogs, IDEs and agent platforms can ingest the Registry and maintain their own searchable index.
This is where the concept of an aggregator becomes important.
What Is an MCP Registry Aggregator?
An aggregator consumes official Registry data and adds value on top of it. That added value might include:
- security scanning;
- user reviews;
- download or popularity metrics;
- enterprise allowlists;
- curation by category;
- compatibility information;
- uptime monitoring;
- organization-specific metadata.
The official Registry is therefore closer to a canonical metadata source than a polished consumer marketplace.
An aggregator can also operate as a subregistry by implementing the compatible OpenAPI interface, allowing MCP hosts to consume the downstream catalog through a standardized shape.
Official Registry vs MCP Marketplace
These terms are often used interchangeably, but they are not the same.
| Layer | Main job | Typical value |
|---|---|---|
| Official MCP Registry | Canonical metadata and namespace verification | Identity + standardized discovery |
| Aggregator / subregistry | Consumes Registry data | Ratings, scans, filtering, enterprise metadata |
| Marketplace | User-facing discovery experience | Search, categories, recommendations, installation UX |
| MCP Gateway | Runtime routing and policy | Authorization, observability, traffic control |
For the runtime control layer, see Vynula’s MCP Gateway guide.
Does the MCP Registry Security-Scan Servers?
No—not as its primary role.
The official documentation says the Registry focuses on namespace authentication and metadata hosting. Security scanning of actual server code is delegated to underlying package registries and downstream aggregators that may provide additional scanning or curation.
This creates a critical rule for users:
Being listed in the Official MCP Registry does not mean a server is safe to grant powerful permissions.
A verified namespace helps you answer “who claims this server identity?” It does not answer “is every tool safe, is the dependency chain clean, or should my agent be allowed to execute these actions?”
That is why MCP discovery should be combined with the controls in Vynula’s AI Agent Security, AI Agent Supply Chain Security and Secrets Management guides.
MCP Registry vs server/discover
This is one of the easiest 2026 concepts to confuse.
The MCP Registry helps a client or catalog find which servers exist and how they are distributed or reached.
server/discover, introduced with the 2026-07-28 protocol generation, is an optional runtime RPC that lets a client learn capabilities from a server it is already communicating with.
In simple terms:
- Registry discovery: “What MCP servers are available?”
server/discover: “What can this particular server instance tell me about itself before I make another request?”
The first is ecosystem discovery. The second is protocol/runtime capability discovery.
How MCP 2026-07-28 Changes Discovery Architecture
The July 28, 2026 MCP specification made the protocol core stateless. The old initialize/initialized handshake and protocol session assumptions were removed for the new revision. Each request can carry the protocol version, client identity and capabilities, while server/discover is available when a client wants server capabilities up front.
This matters because remote MCP infrastructure can now look more like conventional HTTP infrastructure. A request can land on any compatible instance behind ordinary load balancing without depending on shared protocol session state.
Registry metadata and stateless runtime discovery therefore complement each other: one helps find and configure the service, while the other helps operate the connection.
Versioning and Server Status
The Registry can expose multiple versions of the same namespaced server. Aggregators can query version lists and retrieve a specific version or the latest version.
The documentation also describes a mutable server status field. A server can be marked with states such as deprecated or deleted, even though most published metadata is otherwise treated as immutable.
Consumers should pay attention to that status rather than caching a server forever and assuming its standing never changes.
Why Registry Data Should Be Cached Carefully
The Registry’s aggregator guidance explicitly says the service does not provide uptime or data-durability guarantees for downstream consumers. Aggregators are expected to ingest data periodically and maintain their own store.
That means a production MCP host that depends on a curated catalog should not necessarily make its entire runtime availability depend on a live Registry request for every tool invocation.
Discovery data can be synchronized, validated and governed separately from runtime traffic.
Enterprise MCP Discovery
Large organizations will usually need more than the public Registry alone. They may want an internal subregistry or enterprise catalog that includes only approved servers.
An enterprise workflow might look like:
- Ingest public Registry metadata.
- Verify publisher identity and source repository.
- Run package, dependency and behavioral security checks.
- Classify exposed tools by risk.
- Approve selected server versions.
- Add internal metadata, ownership and support contacts.
- Expose only approved servers to employees or agent platforms.
- Route production connections through an MCP gateway or policy layer.
This separates public discovery from organizational trust.
Safe MCP Discovery Checklist
- Confirm the server namespace matches the expected vendor or maintainer.
- Check whether the server is local, packaged, remote or both.
- Review the latest version and status.
- Inspect the actual package or source repository—not only Registry metadata.
- Review every exposed tool and the permissions it requires.
- Prefer read-only or narrow scopes where possible.
- Use strong agent identity and short-lived credentials for remote servers.
- Keep high-impact tools behind human approval.
- Log MCP tool calls and policy decisions.
- Re-evaluate approved servers when versions or ownership change.
For credential design, see AI Agent Identity and Authentication and AI Agent Secrets Management.
How the Registry Fits the Wider Agent Discovery Stack
MCP server discovery is one piece of a larger machine-readable discovery problem. Agents increasingly need to discover tools, skills, APIs, remote agents, registries and capabilities.
Vynula’s How AI Agents Discover Tools, Skills and Other Agents guide covers that broader layer. The MCP Registry is more specific: it standardizes discovery metadata for MCP servers.
It also should not be confused with an AI Agent Registry, where the unit being discovered is an agent or service identity rather than an MCP server package or endpoint.
Registry vs Gateway vs Runtime
These layers solve different problems:
- Registry: Which servers exist, who published them and how can they be installed or reached?
- Gateway: Which MCP requests are allowed, where should they be routed and how should they be observed?
- Runtime: How does the agent execution stay durable, isolated and recoverable while using tools?
See MCP Gateway Explained and AI Agent Runtime Explained for those adjacent layers.
Frequently Asked Questions
Is the MCP Registry an official directory?
Yes. It is the official MCP project’s centralized metadata repository and discovery API for publicly accessible MCP servers.
Is every server in the Registry safe?
No. Namespace verification helps establish publisher identity, but the Registry does not itself certify the security of every server implementation.
Does the Registry host MCP server packages?
No. Package artifacts remain in underlying registries such as npm, while remote servers remain hosted by their providers.
Can a server be both packaged and remote?
Yes. Registry metadata can include both packages and remotes, allowing a host to select an appropriate distribution method.
What is server.json?
It is the standardized Registry metadata file that describes the server identity, version, repository, packages, remote endpoints and related configuration.
Is server/discover the same as the Registry?
No. The Registry supports ecosystem-level discovery; server/discover is an optional protocol RPC for learning about a connected server’s capabilities.
Final Takeaway
The MCP Registry is becoming the metadata backbone of MCP server discovery. It gives publishers a canonical identity and distribution format, while giving clients and aggregators a predictable API for finding servers.
Its real value is standardization: namespaced identities, versioned metadata, package references and remote endpoints can all be described consistently instead of being scattered across README files and manually copied configuration snippets.
But the Registry does not eliminate the need for security review. In a production agent system, the right architecture is discover → verify → approve → connect → monitor, not “found in a registry → automatically trust.”
Related Vynula Guides
- Best MCP Servers in 2026
- What Is MCP?
- MCP Client vs Server vs Host
- What Is an MCP Gateway?
- MCP vs APIs vs Function Calling
- How AI Agents Discover Tools, Skills and Other Agents
- AI Agent Security in 2026
- AI Agent Identity and Authentication
- AI Agent Secrets Management
- AI Agent Runtime Explained
Primary Sources
- Official MCP Registry — About: https://modelcontextprotocol.io/registry/about
- MCP Registry Publishing Quickstart: https://modelcontextprotocol.io/registry/quickstart
- MCP Registry Authentication: https://modelcontextprotocol.io/registry/authentication
- MCP Registry Aggregators: https://modelcontextprotocol.io/registry/registry-aggregators
- Publishing Remote Servers: https://modelcontextprotocol.io/registry/remote-servers
- MCP 2026-07-28 Specification Release: https://blog.modelcontextprotocol.io/posts/2026-07-28/
