- Go 92.9%
- PLpgSQL 3.1%
- HTML 1.9%
- Shell 1.6%
- Makefile 0.5%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
Original PR: #227 - Add Pulumi-based infrastructure as code for deploying MCP Registry to Kubernetes - Support for both local development (minikube) and Azure Kubernetes Service (AKS) - Complete deployment orchestration including: - cluster setup: e.g. you point this at an Azure account, and it can set up and manage the cluster for you. e.g. K8s version, number of nodes, type of nodes, ... - cloud agnostic K8s services: cert-manager, nginx-ingress - app services: MongoDB, and registry application (currently using nginx as a placeholder, blocked on #225 (as is #190). but should be a 1 line change) ## How is this different to #190 - Supports cluster setup and management. This enables: - Non-hosting maintainers managing many devops workflows (e.g. scaling up the cluster, or bumping K8s versions). Without this, we'd need to bug/page the organisation hosting the registry when we need these things changed. - Makes it easy to spin up things like staging/temporary clusters, as well as enables contributors to replicate the stack exactly on their own Azure accounts. - Sets up cloud-agnostic services. For example, rather than using the Azure-managed ingresses and CA, we install nginx-ingress and cert-manager. This enables: - Running the entire infra stack can also run locally (e.g. in minikube, k3s, orbstack, colima) - making it much easier for contributors to test changes to infra stuff. - Moving between cloud providers much more easily, e.g. we could shift from Azure to GCP/AWS/other with minimal hassle. - Everything stays written in Go, rather than Helm templates. This means we get things like type-checking etc. for free (which from my experience makes AI tools wayyy better at editing K8s stuff), and contributors don't need to learn a new language if they're already using Go. ## Testing I've got this running well: - locally in minikube - on cloud in Azure (my personal Azure account) <details><summary>Claude written architecture and security review</summary> <p> ## Deployment Review & Assessment ### Current Architecture Strengths **Pulumi IaC Approach** - Well-structured infrastructure as code using Pulumi - Multi-provider support (AKS, local) with clean abstraction - Good separation of concerns in `pkg/` directory **Security Fundamentals** - Non-root container execution (`appuser` with UID 10001) - Secrets properly managed via Kubernetes secrets - TLS/SSL certificate management with cert-manager and Let's Encrypt ### Critical Issues & High-Priority Improvements **1. Production Deployment Not Ready** 🚨 The registry deployment uses `nginx:alpine` placeholder image instead of the actual MCP registry: - `deploy/pkg/k8s/registry.go:67` - TODO comments indicate incomplete setup - Health probes are commented out - Port mapping doesn't match actual application (80 vs 8080) **Fix:** Build and publish actual registry container image to GHCR, update deployment **2. Database Security Considerations** 🔒 - MongoDB deployed without authentication - No backup/disaster recovery strategy - Database credentials hardcoded *Note: MongoDB is not exposed externally (ClusterIP service), so this is not a critical security risk but should be addressed for production.* **3. Monitoring & Observability Gaps** 📊 - No Prometheus/Grafana monitoring stack - No log aggregation (ELK/Loki) - No application metrics/health dashboards - No alerting configured **4. High Availability & Reliability** ⚠️ - Single MongoDB instance (no replication) - No persistent volume backup strategy - Fixed 10Gi storage without growth planning - Only 2 replicas for registry service - No pod disruption budgets - No horizontal pod autoscaling ### Recommended Improvements **Immediate (High Priority)** 1. Complete Registry Deployment - Build proper container image pipeline, enable health checks 2. Secure MongoDB - Add authentication credentials, implement backup strategy **Medium Priority** 3. Add Monitoring Stack - Prometheus, Grafana deployment 4. Security Hardening (Nice to Have) - RBAC policies, Network Policies, Pod Security Standards 5. CI/CD Pipeline Enhancement - Container image building/publishing, automated deployment **Lower Priority** 6. High Availability - MongoDB replica set, HPA for registry pods 7. Operational Excellence - Kubernetes dashboard, cost optimization ### Configuration Issues - Production config has test credentials: `deploy/Pulumi.prod.yaml:4-5` - Missing environment-specific resource sizing - Hardcoded domain names (`example.com`) The deployment setup shows good architectural foundations but needs significant work before production readiness. The most critical issue is the placeholder nginx container - priority should be completing the actual registry application deployment before addressing the other improvements. Security measures like RBAC and Network Policies are nice to have but not strictly necessary given that MongoDB is not exposed externally. 🤖 Generated with [Claude Code](https://claude.ai/code) </p> </details> ## Metadata Working towards #91 --------- Co-authored-by: Claude <noreply@anthropic.com> |
||
| .githooks | ||
| .github/workflows | ||
| .vscode | ||
| cmd/registry | ||
| data | ||
| deploy | ||
| docs | ||
| internal | ||
| scripts | ||
| tests/integration | ||
| tools | ||
| .dockerignore | ||
| .env.example | ||
| .gitignore | ||
| .golangci.yml | ||
| CLAUDE.md | ||
| docker-compose.yml | ||
| Dockerfile | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
MCP Registry
A community driven registry service for Model Context Protocol (MCP) servers.
Development Status
This project is being built in the open and is currently in the early stages of development. Please see the overview discussion for the project scope and goals.
Contributing
Use Discussions to propose and discuss product and/or technical requirements.
Use Issues to track well-scoped technical work that the community agrees should be done at some point.
Open Pull Requests when you want to contribute work towards an Issue, or you feel confident that your contribution is desireable and small enough to forego community discussion at the requirements and planning levels.
Overview
The MCP Registry service provides a centralized repository for MCP server entries. It allows discovery and management of various MCP implementations with their associated metadata, configurations, and capabilities.
Features
- RESTful API for managing MCP registry entries (list, get, create, update, delete)
- Health check endpoint for service monitoring
- Support for various environment configurations
- Graceful shutdown handling
- MongoDB and in-memory database support
- Comprehensive API documentation
- Pagination support for listing registry entries
- Seed data export/import composability with HTTP support
- Registry instance data sharing via HTTP endpoints
Getting Started
Prerequisites
- Go 1.24.x (required - check with
go version) - MongoDB
- Docker (optional, but recommended for development)
For development:
- golangci-lint v2.3.1 - Install with:
curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(go env GOPATH)/bin v2.3.1
Running
The easiest way to get the registry running is uses docker compose. This will setup the MCP Registry service, import the seed data and run MongoDB in a local Docker environment.
# Run the registry and MongoDB with docker compose
make dev-compose
This will start the MCP Registry service and MongoDB with Docker, running at localhost:8080.
Building
If you prefer to run the service locally without Docker, you can build and run it directly:
# Build a registry executable
make build
This will create the registry binary in the current directory. You'll need to have MongoDB running locally or with Docker.
To run the service locally:
# Run registry locally (requires MongoDB)
make dev-local
By default, the service will run on localhost:8080.
To build the CLI tool for publishing MCP servers to the registry:
# Build the publisher tool
make publisher
Development
Available Make Targets
To see all available make targets:
make help
Key development commands:
# Development
make dev-compose # Start development environment with Docker Compose
make dev-local # Run registry locally (requires MongoDB)
# Build targets
make build # Build the registry application
make publisher # Build the publisher tool
# Testing
make test-unit # Run unit tests with coverage report
make test-integration # Run integration tests
make test-endpoints # Test API endpoints (requires running server)
make test-publish # Test publish endpoint (requires BEARER_TOKEN)
make test-all # Run all tests
# Code quality
make lint # Run linter (same as CI)
make lint-fix # Run linter with auto-fix
# Validation
make validate-schemas # Validate JSON schemas
make validate-examples # Validate examples against schemas
make validate # Run all validation checks
# Combined workflows
make check # Run all checks (lint, validate, unit tests)
# Utilities
make clean # Clean build artifacts and coverage files
Linting
The project uses golangci-lint with extensive checks. Always run linting before pushing:
# Run all linters (same as CI)
make lint
# Run linter with auto-fix
make lint-fix
Git Hooks (Optional)
To automatically run linting before commits:
git config core.hooksPath .githooks
This will prevent commits that fail linting or have formatting issues.
Project Structure
├── api/ # OpenApi specification
├── cmd/ # Application entry points
├── config/ # Configuration files
├── internal/ # Private application code
│ ├── api/ # HTTP server and request handlers (routing)
│ ├── auth/ # GitHub OAuth integration
│ ├── config/ # Configuration management
│ ├── database/ # Data persistence abstraction (MongoDB and in-memory)
│ ├── model/ # Data models and domain structures
│ └── service/ # Business logic implementation
├── pkg/ # Public libraries
├── scripts/ # Utility scripts
└── tools/ # Command line tools
└── publisher/ # Tool to publish MCP servers to the registry
Architecture Overview
Request Flow
- HTTP requests enter through router (
internal/api/router/) - Handlers in
internal/api/handlers/v0/validate and process requests - Service layer executes business logic
- Database interface handles persistence
- JSON responses returned to clients
Key Interfaces
- Database Interface (
internal/database/database.go) - Abstracts data persistence with MongoDB and memory implementations - RegistryService (
internal/service/service.go) - Business logic abstraction over database - Auth Service (
internal/auth/auth.go) - GitHub OAuth token validation
Authentication Flow
Publishing requires GitHub OAuth validation:
- Extract bearer token from Authorization header
- Validate token with GitHub API
- Verify repository ownership matches token owner
- Check organization membership if applicable
Design Patterns
- Factory Pattern for service creation with dependency injection
- Repository Pattern for database abstraction
- Context Pattern for timeout management (5-second DB operations)
- Cursor-based Pagination using UUIDs for stateless pagination
API Endpoints
API Documentation
GET /v0/swagger/index.html
The API is documented using Swagger/OpenAPI. This page provides a complete reference of all endpoints with request/response schemas and examples, and allows you to test the API directly from your browser.
Configuration
The service can be configured using environment variables:
| Variable | Description | Default |
|---|---|---|
MCP_REGISTRY_APP_VERSION |
Application version | dev |
MCP_REGISTRY_DATABASE_TYPE |
Database type | mongodb |
MCP_REGISTRY_COLLECTION_NAME |
MongoDB collection name | servers_v2 |
MCP_REGISTRY_DATABASE_NAME |
MongoDB database name | mcp-registry |
MCP_REGISTRY_DATABASE_URL |
MongoDB connection string | mongodb://localhost:27017 |
MCP_REGISTRY_GITHUB_CLIENT_ID |
GitHub App Client ID | |
MCP_REGISTRY_GITHUB_CLIENT_SECRET |
GitHub App Client Secret | |
MCP_REGISTRY_LOG_LEVEL |
Log level | info |
MCP_REGISTRY_SEED_FROM |
Path or URL to import seed data (supports local files and HTTP URLs) | data/seed.json |
MCP_REGISTRY_SERVER_ADDRESS |
Listen address for the server | :8080 |
Pre-built Docker Images
Pre-built Docker images are automatically published to GitHub Container Registry on each release and main branch commit:
# 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
Available image tags:
latest- Latest commit from main branchmain-<date>-<sha>- Specific commit builds
Configuration: The Docker images support all environment variables listed in the Configuration section. For production deployments, you'll need to configure the database connection and other settings via environment variables.
Import Seed Data
Registry instances can import data from:
Local files:
MCP_REGISTRY_SEED_FROM=data/seed.json ./registry
HTTP endpoints:
MCP_REGISTRY_SEED_FROM=http://other-registry:8080 ./registry
Testing
Run the test script to validate API endpoints:
./scripts/test_endpoints.sh
You can specify specific endpoints to test:
./scripts/test_endpoints.sh --endpoint health
./scripts/test_endpoints.sh --endpoint servers
License
See the LICENSE file for details.