- Go 92.9%
- PLpgSQL 3.1%
- HTML 1.9%
- Shell 1.6%
- Makefile 0.5%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
72f9f80d68summary - use the indexed primary key (`id`) for `getbyid`, `updateserver`, and list ordering/cursor, instead of extracting `_meta...id` from jsonb - in `updateserver`, error if the body tries to change the id; set `meta.official.id` when missing changes - database: `getbyid` → `where id = $1` - database: `updateserver` → `where id = $2`; fail on id mismatch; set id if missing - database: `list` orders by `id` and paginates via `id > $cursor` - no schema or api changes <details> <summary>performance</summary> - env: repo docker compose postgres, 5k–10k rows, warm cache - getbyid: `id` ≈ 0.02 ms vs jsonb path ≈ 0.80 ms - update: `id` ≈ 0.15 ms vs jsonb path ≈ 0.78 ms - list (limit 100): order by `id` ≈ 0.13 ms vs jsonb path id ≈ 2.24 ms (~17x slower) </details> <details> <summary>explain analyze snippets</summary> getbyid by `id` ``` Index Scan using idx_benchmark_servers_id on benchmark_servers (actual time≈0.01–0.02 ms) Buffers: shared hit≈3 ``` getbyid by jsonb path ``` Seq Scan on benchmark_servers (actual time≈0.43–0.83 ms) Filter: ((value->'_meta'->'io.modelcontextprotocol.registry/official'->>'id') = $1) Rows Removed by Filter: ≈4999 Buffers: shared hit≈455 ``` update by `id` ``` Update on benchmark_servers … -> Index Scan using idx_benchmark_servers_id … (actual time≈0.007 ms) Execution Time: ≈0.15 ms ``` update by jsonb path ``` Update on benchmark_servers … -> Seq Scan on benchmark_servers … Rows Removed by Filter: ≈4999 Execution Time: ≈0.78 ms ``` </details> <details> <summary>reproduce quickly</summary> - start postgres: `docker compose up -d postgres` - create a simple table (id varchar pk, value jsonb) with several thousand rows - compare plans: `explain (analyze, buffers) select value from … where id = $1` vs the jsonb path predicate </details> --------- Co-authored-by: Adam Jones <adamj@anthropic.com> |
||
| .githooks | ||
| .github/workflows | ||
| .vscode | ||
| cmd | ||
| data | ||
| deploy | ||
| docs | ||
| internal | ||
| pkg | ||
| scripts | ||
| tests/integration | ||
| tools | ||
| .dockerignore | ||
| .env.example | ||
| .gitignore | ||
| .golangci.yml | ||
| .goreleaser.yaml | ||
| CLAUDE.md | ||
| docker-compose.yml | ||
| Dockerfile | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
MCP Registry
The MCP registry provides MCP clients with a list of MCP servers, like an app store for MCP servers.
📤 Publish my MCP server | ⚡️ Live API docs | 👀 Ecosystem vision | 📖 Full documentation
Development Status
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).
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.
Alternative: Local setup without Docker
Prerequisites:
- PostgreSQL running locally
- Go 1.24.x installed
# Build and run locally
make build
make dev-local
The service runs on localhost:8080 by default. This can be configured with environment variables in .env - 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.
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-mcpyou must login to GitHub asdomdomegg, or be in a GitHub Action on domdomegg's reposme.adamjones/my-cool-mcpyou must prove ownership ofadamjones.mevia DNS or HTTP challenge
More documentation
See the documentation for more details if your question has not been answered here!