- Go 92.9%
- PLpgSQL 3.1%
- HTML 1.9%
- Shell 1.6%
- Makefile 0.5%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
0a97e59ecb## Summary Promotes [v1.7.3](https://github.com/modelcontextprotocol/registry/releases/tag/v1.7.3) to production. Contents: - **#1220** — `RemoteURL` filter SQL rewritten to use JSONB containment (`@>`) instead of `EXISTS jsonb_array_elements`. The new form is GIN-indexable; the old form forced a full table scan. Local benchmark: 40,398 → 294 buffer reads, 17 ms → 1.6 ms. Maps to prod's 10,005 ms cold-cache observation. - **#1221** — pgxpool `MaxConns 30→60`, `MinConns 5→10`. PG `max_connections 100→200`. Explicit PG `resources:` block (was unset). ## What this addresses - **#1220**: yesterday's 17:08 UTC `Publish Endpoint Latency` alert (`dev.storage/mcp` publish took 14.8s with `remotes_ms=10980` — pinpointed by the per-phase slog from #1215). - **#1221**: yesterday's 17:35–17:40 UTC `Availability dropped below 95%` alert and 18:17 UTC `Publish Endpoint Latency` re-fire. Both were scraper-driven concurrency on `/v0/servers` (~15 req/s sustained from ServiceNow + others). With the bumped pool, the queue at the Go HTTP layer should clear faster instead of blowing up to 20–35s nginx-level latencies. ## Deployment caveat The PG `max_connections` change is a postmaster-level setting → CNPG triggers a PG restart on the next prod Pulumi run. With `instances: 1` this is brief downtime — staging took **~30s** during the equivalent restart, with **one registry pod bouncing once** on its 8-attempt DB-retry budget before recovering on the next kubelet restart. **Time the merge for a low-traffic UTC window.** Alert history suggests very early UTC (02:00–04:00) is quietest. ## Resource impact PG node memory is currently 39% (~2.4 GiB / 6 GiB allocatable). Worst-case PG memory growth with `max_connections=200` lands around 3–4 GiB, putting the node at ~65% — fits with headroom. Empirically, prod PG has peaked at **413 MiB** in the last 30h of incident data, so the proposed 4 GiB limit is ~10× the historical max — guardrail not constraint. ## Post-merge CNPG handles `pg_stat_statements` extension creation automatically (no manual `CREATE EXTENSION` step needed — it was already done in v1.7.2's deploy). Verify after deploy: ```bash PATH=/opt/homebrew/share/google-cloud-sdk/bin:$PATH # max_connections actually changed kubectl exec -i registry-pg-1 -c postgres \ --context gke_mcp-registry-prod_us-central1-b_mcp-registry-prod \ -- psql -U postgres -tAc "SHOW max_connections" # expect: 200 # resources block applied kubectl get pod registry-pg-1 \ --context gke_mcp-registry-prod_us-central1-b_mcp-registry-prod \ -o jsonpath='{.spec.containers[?(@.name=="postgres")].resources}{"\n"}' # pgxpool MaxConns reflected (registry app uses 60 per pod after restart) kubectl exec -i registry-pg-1 -c postgres \ --context gke_mcp-registry-prod_us-central1-b_mcp-registry-prod \ -- psql -U postgres -tAc "SELECT count(*) FROM pg_stat_activity WHERE datname='app'" ``` ## Test plan - [x] v1.7.3 release built and pushed (`ghcr.io/modelcontextprotocol/registry:1.7.3`) - [x] Staging deployed cleanly; PG restarted and came back with `max_connections=200`; one staging pod bounced as expected - [ ] Prod Pulumi run applies cleanly; brief PG restart - [ ] Confirm `SHOW max_connections` returns 200 on prod - [ ] Confirm `publish complete` events show `remotes_ms` < 10ms - [ ] Watch for any "too many connections" errors during the rollout window (none expected — Pulumi orders CNPG cluster before Deployment, so PG accepts the new conn limit before pgxpool tries to use it) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
| .githooks | ||
| .github | ||
| .vscode | ||
| cmd | ||
| data | ||
| deploy | ||
| docs | ||
| internal | ||
| pkg | ||
| scripts | ||
| tests/integration | ||
| tools | ||
| .env.example | ||
| .gitignore | ||
| .golangci.yml | ||
| .goreleaser.yaml | ||
| .ko.dockerignore | ||
| .ko.yaml | ||
| CHANGES.md | ||
| CLAUDE.md | ||
| complete.md | ||
| CONTRIBUTING.md | ||
| docker-compose.yml | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| SECURITY.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-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).
Current key maintainers:
- Adam Jones (Anthropic) @domdomegg
- Tadas Antanavicius (PulseMCP) @tadasant
- Toby Padilla (GitHub) @toby
- Radoslav (Rado) Dimitrov (Stacklok) @rdimitrov
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
- 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. Note that the image does not bundle PostgreSQL, so you need to run your own and point the registry at it via MCP_REGISTRY_DATABASE_URL (see docker-compose.yml for a working example):
# 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)
│ ├── 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
Community Projects
Check out community projects to explore notable registry-related work created by the community.
More documentation
See the documentation for more details if your question has not been answered here!