Pcb MCP

The MCP Registry is a platform that provides a list of MCP servers for MCP clients, similar to an app store for MCP servers. The project is currently in the preview stage, the API has been frozen, it supports multiple authentication methods to publish servers, and provides a complete development environment and documentation.

Developer tools Artificial intelligence chatbots #MCP Registry #Server publishing #Development tools #App store .Python

rating : 2.5 points

downloads : 5.6K

update time : 2026-03-12

Open Site

What is the MCP Registry?

The MCP Registry is the official registry for the Model Context Protocol (MCP), similar to an app store for MCP servers. It provides a centralized platform for developers and users to discover, publish, and manage various MCP servers. Through this registry, users can easily find MCP servers that meet their needs, and developers can publish their servers for others to use.

How to use the MCP Registry?

The MCP Registry offers multiple usage methods: As a developer, you can publish your MCP server through a simple CLI tool; as a user, you can browse the list of available servers through the API or the front - end interface; as an integrator, you can integrate the registry into your MCP client to provide server discovery functionality for users.

Applicable scenarios

The MCP Registry is suitable for the following scenarios: 1) Developers want to publish the MCP servers they created; 2) Users need to find MCP servers with specific functions; 3) MCP client developers want to integrate server discovery functionality; 4) Teams need to manage the list of internal MCP servers; 5) Communities want to share and discover useful MCP tools.

Main features

Server discovery

Provides a centralized MCP server directory, allowing users to browse servers by category, function, or popularity.

Server publishing

Supports multiple authentication methods (GitHub OAuth, DNS verification, etc.) to publish MCP servers.

Namespace validation

Automatically verifies the publisher's ownership of the namespace to ensure the server's source is trustworthy.

API stability

Provides a stable v0.1 API to ensure the compatibility of integrated applications.

Local development environment

Provides a complete Docker development environment, supporting rapid local testing and development.

Community integration

Supports the integration of community projects to promote the development of the ecosystem.

Advantages

Officially maintained: Maintained by the MCP core team and the community together to ensure quality and stability.

Easy to use: Provides simple CLI tools and clear documentation to lower the usage threshold.

Multiple authentication: Supports multiple authentication methods such as GitHub OAuth, OIDC, and DNS verification.

Friendly to local development: A complete Docker development environment supports rapid iteration.

Community - driven: An active community support and feedback mechanism for continuous improvement.

Limitations

Preview stage: Currently in the preview version, and the API may still change.

Data reset: Data reset may occur during the preview period.

Dependent on external services: Some functions depend on external services such as GitHub.

Learning curve: Requires an understanding of the basic concepts of the MCP protocol.

How to use

Environment preparation

Install necessary development tools: Docker, Go 1.24.x, ko, and golangci - lint.

Start the development environment

Use Docker Compose to start a complete development environment, including the registry service and the PostgreSQL database.

Publish an MCP server

Use the MCP Publisher CLI tool to publish your MCP server to the registry.

Integrate the registry API

Integrate the registry API into your MCP client to implement server discovery functionality.

Usage examples

Publish a personal MCP server

A developer creates a new MCP server and wants to publish it to the registry for other users to use.

Integrate into an MCP client

An MCP client developer wants to integrate server discovery functionality so that users can browse and select servers.

Team internal server management

A team develops multiple MCP servers for internal use and needs to manage and share them uniformly.

Frequently Asked Questions

What stage is the MCP Registry currently in?

How can I verify my ownership of a namespace?

Will the data in the local development environment be persisted?

How can I get help or provide feedback?

Is the API stable?

Related resources

Quick start guide

A detailed server publishing guide, including step - by - step instructions and examples.

Real - time API documentation

Interactive API documentation, including all endpoints and parameter descriptions.

Ecosystem vision

The long - term development vision and design concept of the MCP Registry.

Preview release announcement

An official blog post announcing the preview release of the MCP Registry.

GitHub repository

The source code repository, including issue tracking and discussion functions.

Community projects

Excellent projects related to the registry created by the community.

🚀 MCP Registry

The MCP registry offers MCP clients a list of MCP servers, functioning like an app store for MCP servers.

| ⚡️ Live API docs | | 📖 Full documentation

🚀 Quick Start

Pre-requisites

Docker
Go 1.24.x
ko - Container image builder for Go (installation instructions)
golangci-lint v2.4.0

Running the server

# Start full development environment
make dev-compose

This starts the registry at localhost:8080 with PostgreSQL. The database uses ephemeral storage and is reset each time you restart the containers, ensuring a clean state for development and testing.

Note: The registry uses ko to build container images. The make dev-compose command automatically builds the registry image with ko and loads it into your local Docker daemon before starting the services.

By default, the registry seeds from the production API with a filtered subset of servers (to keep startup fast). This ensures your local environment mirrors production behavior and all seed data passes validation. For offline development you can seed from a file without validation with MCP_REGISTRY_SEED_FROM=data/seed.json MCP_REGISTRY_ENABLE_REGISTRY_VALIDATION=false make dev-compose.

The setup can be configured with environment variables in docker-compose.yml - see .env.example for a reference.

Alternative: Running a pre-built Docker image

Pre-built Docker images are automatically published to GitHub Container Registry:

# 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

Available tags:

Releases: latest, v1.0.0, v1.1.0, etc.
Continuous: main (latest main branch build)
Development: main-<date>-<sha> (specific commit builds)

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!
./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.

✨ Features

The MCP registry provides MCP clients with a list of MCP servers, similar to an app store for MCP servers.
It supports multiple authentication methods for server publishing, including GitHub OAuth, GitHub OIDC, DNS verification, and HTTP verification.
The registry validates namespace ownership when publishing.

📦 Installation

Pre-requisites

Docker
Go 1.24.x
ko - Container image builder for Go (installation instructions)
golangci-lint v2.4.0

Running the server

# Start full development environment
make dev-compose

Alternative: Running a pre-built Docker image

# 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

💻 Usage Examples

Publishing a server

# Build the latest CLI
make publisher

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

Other commands

# Run lint, unit tests and integration tests
make check

📚 Documentation

Development Status

2025-10-24 update: The Registry API has entered an API freeze (v0.1) 🎉. For the next month or more, the API will remain stable with no breaking changes, allowing integrators to confidently implement support. This freeze applies to v0.1 while development continues on v0. We'll use this period to validate the API in real-world integrations and gather feedback to shape v1 for general availability. Thank you to everyone for your contributions and patience—your involvement has been key to getting us here!

2025-09-08 update: The registry has launched in preview 🎉 (announcement blog post). While the system is now more stable, this is still a preview release and breaking changes or data resets may occur. A general availability (GA) release will follow later. We'd love your feedback in GitHub discussions or in the #registry-dev Discord (joining details here).

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

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)
│   ├── 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

Community Projects

Check out community projects to explore notable registry-related work created by the community.

🔧 Technical Details

Project Structure

The project has a well-organized structure with different directories for various purposes:

cmd/ contains the application entry points, specifically the server publishing tool in cmd/publisher/.
data/ holds the seed data.
deploy/ is for deployment configuration using Pulumi.
docs/ stores all the documentation.
internal/ has private application code, including HTTP handlers, authentication, configuration management, data persistence, business logic, metrics and monitoring, and input validation.
pkg/ contains public packages with API types and data models.
scripts/ has development and testing scripts.
tests/ is for integration tests.
tools/ includes CLI tools and utilities for schema validation.