2e7108d366## Motivation and Context Docs currently don't have very clear organisation, and don't explain core flows. This fixes #89 (although we still might want to push these to `https://modelcontextprotocol.io/docs/`), based on the plan there. One minor change from that plan is that I merged tutorials and guides, because they ended up basically being duplicates which I thought would be annoying for us to keep in sync. Additionally in the Diátaxis framework, tutorials and guides are separated by whether they are focused on acquisition of skills (e.g. in a learning environment) or application of skills (e.g. in a work environment). I expect the registry to be something that will be used occasionally in a work environment, rather than a fundamental 'learnable' skill so I think it's reasonable not to have tutorials and fold these into guides. ## How Has This Been Tested? - Read through all these updated docs - Unit and integration tests (that previously used examples.md and use the schema) working - Ran `npx markdown-link-check .` to check all the links work ## Breaking Changes Links to old docs will break, but I don't think there are any. All internal links have been checked and updated. ## Types of changes <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [x] Documentation update
2.9 KiB
Ecosystem Vision
How the MCP Registry fits into the broader ecosystem and our vision for the future.
The Registry Ecosystem
The MCP registry provides MCP clients with a list of MCP servers, like an app store for MCP servers. (In the future it might do more, like also hosting a list of clients).
There are two parts to the registry project:
- 🟦 The MCP registry spec: An API specification that allows anyone to implement a registry.
- 🟥 The Official MCP registry: A hosted registry following the MCP registry spec at
registry.modelcontextprotocol.io. This serves as the authoritative repository for publicly-available MCP servers. Server creators publish once, and all consumers (MCP clients, aggregators, marketplaces) reference the same canonical data. This is owned by the MCP open-source community, backed by major trusted contributors to the MCP ecosystem such as Anthropic, GitHub, PulseMCP and Microsoft.
The registry is built around the server.json format - a standardized way to describe MCP servers that works across discovery, initialization, and packaging scenarios.
In time, we expect the ecosystem to look a bit like this:
Note that MCP registries are metaregistries. They host metadata about packages, but not the package code or binaries. Instead, they reference other package registries (like NPM, PyPi or Docker) for this.
Additionally, we expect clients pull from subregistries. These subregistries add value to the registry ecosystem by providing curation, or extending it with additional metadata. The Official MCP registry expects a lot of API requests from ETL jobs from these subregistries.
Registry vs Package Registry
Key distinction: MCP Registries are metaregistries.
- Package registries (npm, PyPI, Docker Hub) host actual code/binaries
- The MCP Registry hosts metadata pointing to those packages
MCP Registry: "weather-server v1.2.0 is at npm:weather-mcp"
NPM Registry: [actual weather-mcp package code]
Official vs Community Registries
Official MCP Registry (registry.modelcontextprotocol.io):
- Canonical source for publicly-available servers
- Community-owned, backed by trusted contributors
- Focuses on discoverability and basic metadata
Subregistries (Smithery, PulseMCP, etc.):
- Add value through curation, ratings, enhanced metadata
- ETL from official registry + additional annotations
- Serve specific communities or use cases
How Servers Are Represented
Each server entry contains:
- Identity: Unique name (
io.github.user/server-name) - Packages: Where to download it (
npm,pypi,docker, etc.) - Runtime: How to execute it (args, env vars)
- Metadata: Description, capabilities, version
This is stored in a standardized server.json format that works across discovery, installation, and execution.