MCP Registry: Standardizing Server Discovery

As the MCP ecosystem grows, discoverability becomes a real challenge. With dozens of registries emerging weekly, the community has been in need of a canonical, centralized registry to locate and publish MCP servers.

This article breaks down the goals and architecture of the official MCP Server Registry, based on a joint presentation by Tadas A. (PulseMCP), Alex H. (Block), and Toby P. (GitHub).

What Problems Does the Registry Solve?

1. Fragmented Listings

Most third-party registries rely on scraping GitHub for MCP servers. That approach:

• Misses nested or remote (non-GitHub) servers
• Lacks consistency
• Requires maintainers to update multiple registries manually

2. Installation Confusion

Clients often parse a server’s README to guess how to install and run it. This is error-prone and brittle.

3. No Source of Truth

There’s no agreed-upon standard for where to find MCP server metadata, installation steps, or source code references.

---

What the Official Registry Does

Defines a server.json Format

A single file holds:

• name, description, tags
• Optional remote endpoint or source_url
• Structured installation instructions

Standardized CLI for Publishing

This pushes the metadata to the centralized registry using OAuth for authentication.

Supports ETL Layers for Client Apps

Clients (e.g., VS Code, Goose) can use mirrors that:

• Fetch official registry data
• Enrich it (e.g., stars, usage stats)
• Filter/search based on their UX needs

What It Does Not Cover

• Source Storage: Still relies on GitHub, PyPI, npm, etc.
• Advanced Search or Ranking: Left to downstream clients
• Custom Registry Frontends: Encouraged to build on top of the base API

Federated Architecture & Reusability

The registry promotes reuse of its data model:

• Open API schemas for consistency
• Mirrors and overlays can interoperate
• Encourages client apps to compose registry data and layer their own enhancements

Demo: How It Works

1. Run the registry locally with Docker Compose
2. Use the CLI to publish a server.json
3. Clients (like Goose or VS Code) fetch and display registry metadata via their own ETL layers

This allows tools to:

• Enrich installation flows
• Display accurate documentation
• Provide tailored discovery experiences

Acknowledgements

This guide is based on the collaborative session "MCP Registry: Designing for Server Discovery" presented by Tadas A., Alex H, and Toby P.

Thanks to the GitHub, PulseMCP, and VS Code teams for driving the development, and to the broader MCP community for shaping the registry through open discussions and contributions.