MCP Registry
Author: modelcontextprotocol
Description: A community driven registry service for Model Context Protocol (MCP) servers—an “app store” API that lists MCP servers and supports publishing with namespace ownership verification.
Stars: 6.6k
Forks: 663
License: Other
Category: Official
Overview
Installation
# Start full development environment
make dev-composeMCP_REGISTRY_SEED_FROM=data/seed.json MCP_REGISTRY_ENABLE_REGISTRY_VALIDATION=false make dev-compose# Run latest stable release
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:latest
# Run latest from main branch (continuous deployment)
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:main
# Run specific release version
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:v1.0.0
# Run development build from main branch
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:main-20250906-abc123d# Build the latest CLI
make publisher
# Use it!
./bin/mcp-publisher --help# Run lint, unit tests and integration tests
make checkFAQs
What is the difference between the official MCP Registry and GitHub's MCP registry for discovering MCP servers?
The official MCP Registry provides a REST API for programmatic publishing and consumption, while GitHub's registry integrates directly into Copilot and VS Code with one-click installation. GitHub's version uses repository signals for curation and is optimized for IDE convenience, whereas the official registry focuses on namespace-verified upstream metadata that other platforms consume.
How do I publish an MCP server to the official MCP Registry using the publisher CLI?
After authenticating with GitHub OAuth via the publisher CLI, create a server.json manifest defining your namespace, description, repository object with url and source fields, and packages array specifying registry type, package name, and version. Run the publish command to submit. For custom domains, add a DNS TXT record with your registry token before publishing to verify ownership of com.example namespaces.
How does namespace verification work in MCP Registry, and should I use io.github or a custom domain namespace?
MCP Registry verifies io.github.username namespaces through GitHub OAuth and com.example namespaces via DNS TXT records. While documentation suggests io.github is broadly usable, the validator currently enforces URL-to-domain matching in some cases, causing failures for servers on Cloudflare Workers, AWS Lambda, or Railway. Custom domain namespaces with DNS verification offer more reliable publishing for non-GitHub-Pages deployments.
Can I self-host a private MCP Registry for my organization, and what Docker images are available?
Yes, you can self-host using the official open-source repository. Docker images are published at `ghcr.io/modelcontextprotocol/registry:latest` for the most recent build, plus versioned tags for stable releases. This approach mirrors typical internal package registry patterns, letting you control access and apply organizational policies while maintaining API compatibility with the upstream implementation.
Why can't MCP clients like Claude Desktop or Cursor auto-discover servers from the MCP Registry yet?
Most MCP clients haven't integrated the registry REST API as a built-in discovery source yet. They support MCP protocol connections through manual JSON configuration files, but lack native client-side logic to fetch, filter, and present registry-listed servers automatically. A proposed `.well-known/mcp.json` discovery standard remains under discussion but unshipped, leaving programmatic discovery as separate infrastructure for downstream platforms rather than end-user clients.
What is the io.github namespace validation bug, and how do I work around it when publishing servers deployed on Cloudflare Workers or AWS Lambda?
The validator enforces that servers using io.github.username namespaces must match a derived username.github.io domain URL, causing failures for Cloudflare Workers or AWS Lambda deployments. Switch to a custom domain namespace like com.yourdomain/server-name and verify ownership through DNS TXT records instead of GitHub OAuth to bypass this constraint entirely.