Introducing the MCP Registry: A Central Catalog for MCP Servers

Introducing the MCP Registry: A Central Catalog for MCP Servers

Published on September 10, 2025

Finding a compatible model server shouldn’t feel like a scavenger hunt. The MCP Registry launches in preview as an open, centralized catalog and API for publicly available Model Context Protocol (MCP) servers — designed to make discovery reliable, standardized, and easier to automate. This post explains what the Registry is, how it’s organized, how to get started, and what to expect during the preview phase.

What the MCP Registry is and why it matters

The problem it solves

Teams historically hard-code endpoints, maintain brittle lists, or rely on ad-hoc discovery. That creates wasted time and fragile integrations. The MCP Registry provides a single, community-maintained source of truth for publicly listed MCP servers so clients can query for servers that match capabilities, tags, or other metadata instead of guessing. The result: faster integration, better visibility for server maintainers, and a more interoperable ecosystem.

Open and standards-first

The Registry is an official MCP project, open source, and built on a published OpenAPI reference so implementers can build compatible tooling and sub-registries. The preview is available at https://registry.modelcontextprotocol.io and the source and docs live in the registry GitHub repository: github.com/modelcontextprotocol/registry. The project is permissively licensed and intended to be auditable and extensible. Discover how the OpenAI Agents SDK is transforming AI development with innovative features and seamless integration here.

How the registry is structured

Central registry vs. sub-registries

Think of the MCP Registry as the canonical public feed. Downstream systems can consume it or build an augmented view — called a sub-registry. Sub-registries come in two main flavors:

  • Public sub-registries (marketplaces): Opinionated listings tailored to a client or audience, adding UI metadata, ratings, or curated filters on top of upstream data.
  • Private sub-registries (enterprise mirrors): Internal registries that keep sensitive servers off the public index while reusing upstream schemas and SDKs for compatibility.

Because the registry publishes an OpenAPI specification, sub-registries can implement compatible APIs and tooling, enabling an interoperable ecosystem rather than a single locked system.

Main use cases

Common scenarios the Registry supports:

  • Server maintainers publishing metadata so clients can discover endpoints and capabilities.
  • Client developers listing and filtering servers by tags, supported features, or region.
  • Marketplace operators creating curated storefronts that ingest and augment upstream data.
  • Enterprises running private mirrors while preserving compatibility with public tooling.

Community moderation and governance

Moderation model

The Registry operates with community-driven moderation. If you see spam, impersonation, or malicious listings, you can open an issue in the registry repository and reference the moderation guidelines. Registry maintainers review reports and can denylist or remove entries from public access as needed. The moderation guidelines and administration docs are published in the repo so the process stays transparent: moderation guidelines. Discover how Anthropic AI bridges human values with technology, redefining AI safety and alignment here.

Participation and transparency

Because the project is developed in the open and permissively licensed, anyone can propose changes, audit the implementation, or run a compatible sub-registry. Community membership and contributions are encouraged via GitHub Discussions, Issues, and Pull Requests in the registry repository: github.com/modelcontextprotocol/registry.

Technical quickstart — hands-on discovery

Try a simple discovery request (illustrative)

To get a feel for discovery, you can query the Registry’s discovery endpoints. The exact paths and parameters are defined in the repository’s OpenAPI spec; the following example is illustrative — consult the OpenAPI reference for the canonical request/response shapes.

curl "https://registry.modelcontextprotocol.io/servers?limit="10""

Typical read operations are public for discovery. Publishing or updating entries generally requires authentication and follows the publishing guide in the repo. For the most accurate endpoints, query patterns, and schemas, refer to the official docs and the OpenAPI reference in the repository: Accessing MCP Registry Data and official OpenAPI spec.

Illustrative example response (trimmed)

Below is an illustrative, trimmed JSON fragment showing common metadata fields you can expect when discovering servers. This is an example for guidance — consult the OpenAPI spec for the exact schema.

{
  "items": [
    {
      "id": "example-server-1",
      "name": "Example MCP Server",
      "description": "A server that supports context-aware responses",
      "api": "https://example-server.example.com/mcp",
      "openapi_url": "https://example-server.example.com/openapi.json",
      "version": "2025-08-01",
      "license": "Apache-2.0",
      "tags": ["context", "text-generation"],
      "updated_at": "2025-09-01T12:00:00Z"
    }
  ],
  "meta": {
    "limit": 10,
    "next_page": null
  }
}

Note: the exact field names, pagination model, and auth requirements are set by the Registry’s OpenAPI specification — always consult that reference for production integrations.

Publishing, authentication, and recommended flows

How to publish (overview)

Server maintainers should follow the publishing guide in the repository for step-by-step instructions. The guide explains how to prepare standardized MCP metadata for your server and how to submit it to the Registry. See: Adding Servers to the MCP Registry.

Authentication and write paths

Discovery read endpoints are generally intended to be public. Publishing or updating an entry typically requires authentication and follow-up verification steps; consult the publishing guide for the exact process and required fields. If your organization needs a private install, you can run a sub-registry or mirror and control write access internally.

Practical integration advice

  • Start in staging: test discovery flows and metadata parsing before relying on the Registry in production.
  • Cache and retry: design clients to cache responses, use reasonable TTLs, and implement retries for transient failures. Learn more about testing AI technologies like text-to-video AI here.
  • Plan for change: the preview may introduce schema changes — make your client tolerant to unknown fields and capable of graceful degradation.

Operational guidance for sub-registries and mirrors

Sync and augmentation strategies

Sub-registries typically consume the central feed and add a layer of filtering or enrichment. Common approaches include:

  • Periodic pull: schedule regular pulls (e.g., every few minutes or hours) and reconcile deltas to handle upstream updates.
  • Event-driven/webhooks: if the upstream exposes events, use them to reduce latency between updates; otherwise, combine webhooks with periodic verification.
  • Local mirroring: maintain a local cache for production stability during the preview and sync in the background.

Caching, freshness, and conflict handling

Decide on a cache TTL based on your data freshness needs. When augmenting upstream data, store provenance metadata so you can trace whether values came from the upstream Registry or your marketplace layer. Establish conflict-resolution rules (e.g., prefer local overrides for UI metadata, always use upstream for canonical server endpoints).

Governance, moderation, and contributor transparency

How to report an issue

If you find problematic entries, open an Issue in the registry repository and follow the moderation guidelines. Maintainers review reports and can denylist entries if they violate policy. The moderation guide documents examples of violations and steps the maintainers can take.

Maintainers and contributors

The Registry is a community effort. Core maintainers and contributors played key roles in the launch, including (among others) David Soria Parra (Lead Maintainer), Tadas Antanavicius (Registry Maintainer), Toby Padilla (Registry Maintainer), and Adam Jones (Registry Maintainer). A broader set of contributors from multiple companies supported development and reviews.

See the full contributors graph and discussion threads in the repo for complete attribution and history: contributors graph and initial discussion.

Preview state, roadmap, and expectations

What preview means

The Registry is available in preview to collect feedback and iterate. During preview, the project does not guarantee data durability or backward-compatibility. Expect the schema and API to evolve before general availability.

How to plan for updates

Clients should:

  • Subscribe to the repository for release notes and breaking-change announcements.
  • Design integrations to tolerate unknown fields and minor schema changes.
  • Run local mirrors or private sub-registries if you need production-grade stability during the preview.

Checklist — should you adopt the Registry now?

  • If you publish a public MCP server: prepare the standardized metadata and try publishing to increase discoverability.
  • If you build a client or marketplace: prototype a simple discovery flow in staging and consider whether a public or private sub-registry fits your needs.
  • If you operate in an enterprise: plan a private mirror or sub-registry to meet compliance while leveraging shared schemas and tooling.
  • If you rely on stability today: treat the preview as experimental and run a local mirror until GA is announced.
  • If you find abuse or suspicious entries: open an issue and follow the moderation guide so maintainers can investigate.

Next steps and how to help

Get involved: try a discovery query in staging, publish a test server, or open issues and PRs in the registry repository. The project welcomes feedback and contributions — code, docs, moderation, or usage notes all help shape the Registry as it matures.

For the authoritative documentation, API details, publishing workflow, and moderation rules, see the registry repo: github.com/modelcontextprotocol/registry.

Thanks to everyone who has contributed so far — open infrastructure succeeds when people show up to build, test, and govern it. Your early feedback during preview will help make the MCP Registry a reliable foundation for finding and connecting to context-aware servers.

Back to Blog