These docs are synced to modelcontextprotocol.io which uses Mintlify for rendering. Mintlify routes are extension-less, so links like `./package-types.mdx` produce 404s on the live site. Dropping the `.mdx` suffix fixes those broken links. The trade-off is that the links no longer resolve when browsing the raw files on GitHub. Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
93 lines
6.3 KiB
Text
93 lines
6.3 KiB
Text
---
|
|
title: The MCP Registry
|
|
sidebarTitle: About
|
|
---
|
|
|
|
<Note>
|
|
The MCP Registry is currently in preview. Breaking changes or data resets may occur before general availability. If you encounter any issues, please report them on [GitHub](https://github.com/modelcontextprotocol/registry/issues).
|
|
</Note>
|
|
|
|
The MCP Registry is the official centralized metadata repository for publicly accessible MCP servers, backed by major trusted contributors to the MCP ecosystem such as Anthropic, GitHub, PulseMCP, and Microsoft.
|
|
|
|
The MCP Registry provides:
|
|
|
|
- A single place for server creators to publish metadata about their servers
|
|
- Namespace management through DNS verification
|
|
- A REST API for MCP clients and aggregators to discover available servers
|
|
- Standardized installation and configuration information
|
|
|
|
Server metadata is stored in a standardized [`server.json` format](https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/server-json/draft/server.schema.json), which contains:
|
|
|
|
- The server's unique name (e.g., `io.github.user/server-name`)
|
|
- Where to locate the server (e.g., npm package name, remote server URL)
|
|
- Execution instructions (e.g., command-line args, env vars)
|
|
- Other discovery data (e.g., description, server capabilities)
|
|
|
|
## The MCP Registry Ecosystem
|
|
|
|
The MCP Registry is part of an ecosystem that looks something like:
|
|
|
|

|
|
|
|
### Relationship with Package Registries
|
|
|
|
Package registries — such as npm, PyPI, and Docker Hub — host packages with code and binaries.
|
|
|
|
The MCP Registry hosts metadata that points to those packages.
|
|
|
|
For example, a `weather-mcp` package could be hosted on npm, and metadata in the MCP Registry could map the "weather v1.2.0" server to `npm:weather-mcp`.
|
|
|
|
The [Package Types guide](./package-types) lists the supported package types and registries. More package registries may be supported in the future based on community demand. If you are interested in building support for a package registry, please [open an issue](https://github.com/modelcontextprotocol/registry).
|
|
|
|
### Relationship with Server Developers
|
|
|
|
The MCP Registry supports both open-source and closed-source servers. Server developers can publish their server's metadata to the registry as long as the server's installation method is publicly available (e.g., an npm package or a Docker image on a public registry) _or_ the server itself is publicly accessible (e.g., a remote server that is not restricted to private networks).
|
|
|
|
The MCP Registry **does not** support private servers. Private servers are those that are only accessible to a narrow set of users. For example, servers published on a private network (like `mcp.acme-corp.internal`) or on private package registries (e.g. `npx -y @acme/mcp --registry https://artifactory.acme-corp.internal/npm`). If you want to publish private servers, we recommend that you host your own private MCP registry and add them there.
|
|
|
|
### Relationship with Downstream Aggregators
|
|
|
|
The MCP Registry is intended to be consumed primarily by downstream aggregators, such as MCP server marketplaces.
|
|
|
|
The metadata hosted by the MCP Registry is deliberately unopinionated. Downstream aggregators can provide curation or additional metadata such as community ratings.
|
|
|
|
We expect that downstream aggregators will use the MCP Registry API to pull new metadata on a regular but infrequent basis (for example, once per hour). See the [MCP Registry Aggregators guide](./registry-aggregators) for more information.
|
|
|
|
### Relationship with Other MCP Registries
|
|
|
|
In addition to a public REST API, the MCP Registry defines an [OpenAPI spec](https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/api/openapi.yaml) that other MCP registries can implement in order to provide a standardized interface for MCP host applications.
|
|
|
|
We expect that many downstream aggregators will implement this interface. Private MCP registries can implement it as well to benefit from existing host application support.
|
|
|
|
Note that the official MCP Registry codebase is **not** designed for self-hosting, and the registry maintainers cannot provide support for this use case. If you choose to fork it, you would need to maintain and operate it independently.
|
|
|
|
### Relationship with MCP Host Applications
|
|
|
|
The MCP Registry is not intended to be directly consumed by host applications. Instead, host applications should consume other MCP registries, such as downstream marketplaces, via a REST API conforming to the official MCP Registry's OpenAPI spec.
|
|
|
|
## Trust and Security
|
|
|
|
### Verifying Server Authenticity
|
|
|
|
The MCP Registry uses namespace authentication to ensure that servers come from their claimed sources. Server names follow a reverse DNS format (like `io.github.username/server` or `com.example/server`) that ties them to verified GitHub accounts or domains.
|
|
|
|
This namespace system ensures that only the legitimate owner of a GitHub account or domain can publish servers under that namespace, providing trust and accountability in the ecosystem. For details on authentication methods, see the [Authentication guide](./authentication).
|
|
|
|
### Security Scanning
|
|
|
|
The MCP Registry delegates security scanning to:
|
|
|
|
- **Underlying package registries** — npm, PyPI, Docker Hub, and other package registries perform their own security scanning and vulnerability detection.
|
|
- **Downstream aggregators** — MCP Registry aggregators and marketplaces can implement additional security checks, ratings, or curation.
|
|
|
|
The MCP Registry focuses on namespace authentication and metadata hosting, while relying on the broader ecosystem for security scanning of actual server code.
|
|
|
|
### Spam Prevention
|
|
|
|
The MCP Registry uses multiple mechanisms to prevent spam:
|
|
|
|
- **Namespace authentication requirements** — Publishers must verify ownership of their namespace through GitHub, DNS, or HTTP challenges, preventing arbitrary spam submissions.
|
|
- **Character limits and validation** — Free-form fields have strict character limits and regex validation to prevent abuse.
|
|
- **Manual takedown** — The registry maintainers can manually remove spam or malicious servers. See the [Moderation Policy](./moderation-policy) for details on what content is removed.
|
|
|
|
Future spam prevention measures under consideration include stricter rate limiting, AI-based spam detection, and community reporting capabilities.
|