- Go 92.9%
- PLpgSQL 3.1%
- HTML 1.9%
- Shell 1.6%
- Makefile 0.5%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
Refs #28. After some thinking, this tries for a 'best of both worlds' approach. Simple arguments can be present essentially as the original spec recommended. As discussed, we don't specify the args for `npx` and friends directly, so a simple package is merely... ```yaml - name: my-api-mcp # ... packages: - type: npm name: "@c4312/my-api-mcp" version: "0.0.1" arguments: # Named inputs in 'arguments' generate a `--name=<value>` - type: named name: "api-key" is_required: true is_secret: true ``` However, I think we need to be able to specify runtime args in some cases, otherwise the registry eventually mirrors all docker configs and options which is not a great situation to be in. So, I suggest a `runtime_args` in the same format. Say I wanted that for npm, I could: ```yaml - name: my-api-mcp # ... packages: - type: npm name: "@c4312/my-api-mcp" version: "0.0.1" runtime_arguments: # Arguments with a pre-specified `value` don't get prompted for input - type: positional value: "--experimental-eventsource" ``` But Docker mounts are... complex, and ultimately we may deal with cases that need multiple inputs in an argument like that. So for that I suggest the third kind of "templated" input that does basic replacements and has `properties` that follow the same general input schema: ```yaml - name: server-filesystem # ... packages: - type: docker name: "mcp/filesystem" version: "0.0.1" runtime_arguments: - type: template description: Mount paths to access. required: true repated: true template: "--mount=type=bind,src={host_path},dst={container_path}" values: host_path: description: Path to access on the local machine required: true format: filepath container_path: description: Path to mount in the container. It should be rooted in `/project` directory. required: true format: string default: "/project" arguments: - type: positional value: "/project" ``` And then client config ends up being pretty simple, for the above case for example a client could have this config: ``` { "filesystem": { "server": "@modelcontextprotocol/servers/src/filesystem@1.0.2", "package": "docker", "settings": { "mount_config": [ { "source_path": "/Users/username/Desktop", "target_path": "/project/desktop" }, { "source_path": "/path/to/other/allowed/dir", "target_path": "//projects/other/allowed/dir,ro" }, ] } } } ``` Which might generate a CLI: ``` docker run \ --mount=type=bind,src=/Users/username/Desktop,dst=/project/desktop \ --mount=type=bind,src=/path/to/other/allowed/dir,dst=/project/other/allowed/dir,ro \ mcp/filesystem:1.0.2 \ /project ``` I think this does a good job of accomplishing the goals we care about: - We get nicely defined inputs that are easy to extend, easy to process, and easy for clients to configure. - Versioning is enforced as we don't require the package to specify the identifier to npx/uvx/etc. - We _usually_ can break away from a dependency on a specific runtime. This promise is broken a bit with `runtime_arguments`, most packages should not need this and those that do are those inherently more tightly coupled to a specific runtime like Docker (e.g. they would be pretty uncommon for Node or Python.) - We don't have a suple complex template system with loops and fallbacks and conditionals, like we would if we tried to have a single template string for a command. |
||
| .vscode | ||
| api | ||
| cmd/registry | ||
| data | ||
| internal | ||
| scripts | ||
| tools/publisher | ||
| .gitignore | ||
| CONTRIBUTING.md | ||
| docker-compose.yml | ||
| Dockerfile | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| 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. If you would like to contribute, please check out the contributing guidelines.
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
Getting Started
Prerequisites
- Go 1.18 or later
- MongoDB
- Docker (optional, but recommended for development)
Running
The easiest way to get the registry running is to use docker compose. This will setup the MCP Registry service, import the seed data and run MongoDB in a local Docker environment.
# Build the Docker image
docker build -t registry .
# Run the registry and MongoDB with docker compose
docker compose up
This will start the MCP Registry service and MongoDB with Docker, exposing it on port 8080.
Building
If you prefer to run the service locally without Docker, you can build and run it directly using Go.
# Build a registry executable
go build ./cmd/registry
This will create the registry binary in the current directory. You'll need to have MongoDB running locally or with Docker.
By default, the service will run on http://localhost:8080.
Project Structure
├── cmd/ # Application entry points
├── config/ # Configuration files
├── internal/ # Private application code
│ ├── api/ # HTTP server and request handlers
│ ├── config/ # Configuration management
│ ├── model/ # Data models
│ └── service/ # Business logic
├── pkg/ # Public libraries
├── scripts/ # Utility scripts
└── tools/ # Command line tools
└── publisher/ # Tool to publish MCP servers to the registry
API Documentation
The API is documented using Swagger/OpenAPI. You can access the interactive Swagger UI at:
/v0/swagger/index.html
This provides a complete reference of all endpoints with request/response schemas and allows you to test the API directly from your browser.
API Endpoints
Health Check
GET /v0/health
Returns the health status of the service:
{
"status": "ok"
}
Registry Endpoints
List Registry Server Entries
GET /v0/servers
Lists MCP registry server entries with pagination support.
Query parameters:
limit: Maximum number of entries to return (default: 30, max: 100)cursor: Pagination cursor for retrieving next set of results
Response example:
{
"servers": [
{
"id": "1",
"name": "Example MCP Server",
"description": "An example MCP server implementation",
"url": "https://example.com/mcp",
"repository": {
"url": "https://github.com/example/mcp-server",
"stars": 120
},
"version": "1.0.0",
}],
"metadata": {
"next_cursor": "cursor-value-for-next-page"
}
}
Publish a Server Entry
POST /v0/publish
Publishes a new MCP server entry to the registry. Authentication is required via Bearer token in the Authorization header.
Headers:
Authorization: Bearer token for authentication (e.g.,Bearer your_token_here)Content-Type: application/json
Request body example:
{
"server_detail": {
"name": "io.github.username/repository",
"description": "Your MCP server description",
"version_detail": {
"version": "1.0.0"
},
"registries": [
{
"name": "npm",
"package_name": "your-package-name",
"license": "MIT"
}
],
"remotes": [
{
"transport_type": "http",
"url": "https://your-api-endpoint.com"
}
]
},
"repo_ref": "username/repository"
}
Response example:
{
"message": "Server publication successful",
"id": "1234567890abcdef12345678"
}
Ping Endpoint
GET /v0/ping
Simple ping endpoint that returns environment configuration information:
{
"environment": "dev",
"version": "registry-<sha>"
}
Configuration
The service can be configured using environment variables:
| Variable | Description | Default |
|---|---|---|
MCP_REGISTRY_APP_VERSION |
Application version | dev |
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_FILE_PATH |
Path to import seed file | data/seed.json |
MCP_REGISTRY_SEED_IMPORT |
Import seed.json on first run |
true |
MCP_REGISTRY_SERVER_ADDRESS |
Listen address for the server | :8080 |
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.
Contributing
See the CONTRIBUTING file for details.