Registries answer “what servers exist and how do I install them?” Hosting answers “how do my servers run in production?” Keep those jobs separate.
Official MCP Registry (preview)
Primary source: The MCP Registry.
Key facts from that page:
- Official centralized metadata repository for publicly accessible MCP servers
- Backed by major ecosystem contributors (the page lists Anthropic, GitHub, PulseMCP, Microsoft among others)
- Currently in preview — breaking changes or data resets may occur before general availability
- Provides: a place to publish metadata, namespace management via DNS verification, a REST API for clients/aggregators, standardized install/config information
- Metadata lives in a standardized
server.jsonformat (name, location, execution instructions, discovery fields)
Schema reference linked from the registry docs: server.schema.json (draft).
What it is not
From the same official page:
| Concern | Official stance |
|---|---|
| Hosting source code/binaries | Package registries (npm, PyPI, Docker Hub, …) host packages; the MCP Registry hosts metadata that points to them |
| Private/internal-only servers | Not supported on the official registry; run a private MCP registry instead |
| Primary consumer of the API | Intended mainly for downstream aggregators / marketplaces, not for every host app to hit directly every time |
| Self-hosting the official codebase | Not designed for self-hosting; maintainers do not support that use case |
Trust model (official)
- Namespace authentication — names like
io.github.user/serverorcom.example/servertied to verified GitHub/domain ownership (Authentication guide) - Security scanning — delegated to underlying package registries and downstream aggregators; the registry focuses on namespace auth + metadata
- Spam prevention — namespace auth, validation limits, manual takedown (Moderation policy)
Related official pages:
Aggregators and marketplaces
The official ecosystem diagram (on the about page) positions:
- Developers publish metadata to the MCP Registry
- Aggregators pull via API on a regular basis and may add curation/ratings
- Host applications often consume aggregators that implement the registry OpenAPI interface
Third-party indexes (Glama-scale search, vendor marketplaces, etc.) are aggregators or product catalogs — useful for discovery, but not substitutes for the official registry’s role unless they implement/aggregate from it. Compare product positioning carefully: MCPLambda vs Glama.
Platform catalogs (e.g. MCPLambda)
Many hosts ship an in-product registry (Official + Community install into a project). That is a product catalog, not the official MCP Registry.
MCPLambda’s product docs: MCP Server Registry. Install still lands on package, Git, or image deployment under the hood; bring-your-own sources remain first-class.
How to use registries well
- Prefer official publish path for public servers you maintain (quickstart)
- Treat aggregator ratings as extra signal, not protocol truth
- Pin versions when promoting to production (versioning)
- Test before prod (Inspector)
- Keep private business servers off the public registry
Worked scenario: Metadata is not a runtime
A PM asks why the official registry “does not run our private server.” You explain: the registry is a preview metadata catalog pointing at public packages/remotes—not a private PaaS. Private servers stay on your host.
You still use the registry to discover public tools and to publish open servers with DNS/GitHub namespace verification. Aggregators may add ratings; they do not replace your production deploy pipeline for BYO code.
Checklist for this topic
- Treat official registry as public metadata (preview)
- Publish only public installable servers there
- Pin versions when consuming catalog servers
- Use private hosting for private servers
- Verify namespace ownership when publishing
- Review security of third-party servers before prod
Topic-specific failure modes
| Failure | Likely cause | Fix |
|---|---|---|
| Expecting private support | Misread registry scope | Private host/registry |
| Assuming code hosting | Metadata vs packages | Use npm/PyPI/Docker for code |
| Unpinned community tool | Supply chain | Pin + review updates |
| Host hits registry every request | Wrong consumer | Aggregators/cache; hosts use stable installs |
Related guides
Catalog vs BYO · Registry about · Package for production
In practice: publish checklist (public servers)
- Namespace authentication done
- server.json accurate
- Package installable from a clean machine
- Version pinned policy for consumers documented
- Security contact / repo status clear
Publishing is a promise of installability—not just a marketing listing.
Aggregator vs official registry
Use the official registry when you care about namespace authenticity and public metadata. Use aggregators when you want search UX, screenshots, or opinionated rankings. Production installs should still pin versions and run your own staging evaluation regardless of where you discovered the server.
Takeaways
For MCP Registry 101: Official Registry, Aggregators, and Platform Catalogs, remember three things:
- Be specific to this problem — the worked scenario “Metadata is not a runtime” is the failure mode you should design against, not a generic outage narrative.
- Registry metadata helps discovery; it is not a runtime, SLA, or security boundary.
- Prefer official registry + your own vetting for anything that touches production credentials.
If you only remember one habit: list for distribution; host and monitor for production.
Sources
- The MCP Registry — about
- Registry FAQ
- Authentication
- Aggregators
- MCPLambda product: Registry docs
