registry

MCP Registry

The MCP registry provides MCP clients with a list of MCP servers, like an app store for MCP servers.

📖 Full documentation

Development Status

[!WARNING]
The registry is under active development. The registry API spec is unstable and the official MCP registry database may be wiped at any time.

2025-09-04 update: We're targeting a 'preview' go-live on 8th September. This may still be unstable and not provide durability guarantees, but is a step towards being more solidified. A general availability (GA) release will follow later.

Current key maintainers:

• Adam Jones (Anthropic) @domdomegg
• Tadas Antanavicius (PulseMCP) @tadasant
• Toby Padilla (GitHub) @toby

Contributing

We use multiple channels for collaboration - see modelcontextprotocol.io/community/communication.

Often (but not always) ideas flow through this pipeline:

• Discord - Real-time community discussions
• Discussions - Propose and discuss product/technical requirements
• Issues - Track well-scoped technical work
• Pull Requests - Contribute work towards issues

Quick start:

Pre-requisites

• Docker
• Go 1.24.x
• golangci-lint v2.4.0

Running the server

# Start full development environment
make dev-compose

This starts the registry at localhost:8080 with PostgreSQL and seed data. It can be configured with environment variables in docker-compose.yml - see .env.example for a reference.

# Build and run locally
make build
make dev-local

# Run latest from main branch
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:latest

# Run specific commit build
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:main-20250806-a1b2c3d

Publishing a server

To publish a server, we've built a simple CLI. You can use it with:

# Build the latest CLI
make publisher

# Use it!
./cmd/publisher/bin/mcp-publisher --help

See the publisher guide for more details.

Other commands

# Run lint, unit tests and integration tests
make check

There are also a few more helpful commands for development. Run make help to learn more, or look in Makefile.

Architecture

Project Structure

├── cmd/                     # Application entry points
│   └── publisher/           # Server publishing tool
├── data/                    # Seed data
├── deploy/                  # Deployment configuration (Pulumi)
├── docs/                    # Documentation
├── internal/                # Private application code
│   ├── api/                 # HTTP handlers and routing
│   ├── auth/                # Authentication (GitHub OAuth, JWT, namespace blocking)
│   ├── config/              # Configuration management
│   ├── database/            # Data persistence (PostgreSQL, in-memory)
│   ├── service/             # Business logic
│   ├── telemetry/           # Metrics and monitoring
│   └── validators/          # Input validation
├── pkg/                     # Public packages
│   ├── api/                 # API types and structures
│   │   └── v0/              # Version 0 API types
│   └── model/               # Data models for server.json
├── scripts/                 # Development and testing scripts
├── tests/                   # Integration tests
└── tools/                   # CLI tools and utilities
    └── validate-*.sh        # Schema validation tools

Authentication

Publishing supports multiple authentication methods:

• GitHub OAuth - For publishing by logging into GitHub
• GitHub OIDC - For publishing from GitHub Actions
• DNS verification - For proving ownership of a domain and its subdomains
• HTTP verification - For proving ownership of a domain

The registry validates namespace ownership when publishing. E.g. to publish...:

• io.github.domdomegg/my-cool-mcp you must login to GitHub as domdomegg, or be in a GitHub Action on domdomegg's repos
• me.adamjones/my-cool-mcp you must prove ownership of adamjones.me via DNS or HTTP challenge

More documentation

See the documentation for more details if your question has not been answered here!