This commit implements support for publishing MCP servers to GitHub Container Registry (ghcr.io) in addition to the existing Docker Hub support, addressing Docker Hub rate limiting concerns as requested in #393. Key changes: - Add RegistryURLGHCR constant for https://ghcr.io - Refactor OCI validation to support multiple container registries with extensible RegistryConfig system - Implement registry-agnostic authentication system that handles: - Docker Hub token-based authentication via auth.docker.io - GHCR token-based authentication via ghcr.io/token service - Update Accept headers to support OCI image indexes for multi-arch images - Extract helper functions to reduce cyclomatic complexity and improve code maintainability - Add comprehensive test coverage for both Docker Hub and GHCR scenarios - Include real image testing with github/github-mcp-server and nkapila6/mcp-local-rag - Update publishing documentation with GHCR examples and authentication details The implementation maintains backward compatibility with existing Docker Hub usage while providing a future-proof architecture for adding additional container registries. All authentication is now handled through proper token services for both registries. Fixes #393 ## Motivation and Context Docker Hub rate limiting has been causing issues for the MCP registry when validating OCI images. Adding GHCR support provides an alternative container registry that many MCP server authors are already using, reducing the load on Docker Hub and providing more options for the community. ## How Has This Been Tested? - All existing unit tests continue to pass - Added comprehensive test coverage for GHCR scenarios including: - Non-existent images (proper error handling) - Real images without MCP annotations (github/github-mcp-server) - Real images with proper MCP annotations (nkapila6/mcp-local-rag) - Registry URL validation for both supported registries - Tested authentication flow manually using curl commands - Verified multi-arch image support with OCI index manifests ## Breaking Changes None. This is a purely additive change that maintains full backward compatibility with existing Docker Hub configurations. ## Types of changes - [x] New feature (non-breaking change which adds functionality) - [x] Documentation update ## Checklist - [x] I have read the [MCP Documentation](https://modelcontextprotocol.io) - [x] My code follows the repository's style guidelines - [x] New and existing tests pass locally - [x] I have added appropriate error handling - [x] I have added or updated documentation as needed ## Additional context The implementation uses a RegistryConfig struct to abstract registry-specific details like API endpoints, authentication URLs, and token services. This design makes it straightforward to add support for additional container registries in the future (such as AWS ECR, Azure Container Registry, etc.) by simply adding new cases to the getRegistryConfig function. The authentication system properly handles the different token services used by each registry: - Docker Hub: auth.docker.io with service=registry.docker.io - GHCR: ghcr.io/token with service=ghcr.io Both registries now support the full OCI specification including multi-arch images via OCI image indexes.
14 KiB
Publish Your MCP Server
Complete guide to publishing an MCP server to the registry.
Tip
Using an agentic AI coding assistant? Just use this prompt:
Read https://raw.githubusercontent.com/modelcontextprotocol/registry/refs/heads/main/docs/guides/publishing/publish-server.md and https://raw.githubusercontent.com/modelcontextprotocol/registry/refs/heads/main/docs/guides/publishing/github-actions.md. Evaluate the best way to publish this server to the registry (prefer automated CI flows over manual flows where possible), and implement that. If possible, validate the server.json against the $schema before telling the user you are done, using a proper json schema library or tool available on the user's machine. If you get stuck, guide the user through the parts of the publishing process they need to do (e.g. logging into the publisher CLI if doing manual pubishing).
What You'll Learn
By the end of this tutorial, you'll have:
- Created a server.json file for your MCP server
- Authenticated with the registry
- Successfully published your server
- Verified your server appears in the registry
Prerequisites
- An MCP server you've already built (follow this guide if you don't have one already)
Deployment Options
You can make your MCP server available in multiple ways:
- 📦 Package deployment: Published to registries (npm, PyPI, NuGet, Docker Hub, etc.) and run locally by clients
- 🌐 Remote deployment: Hosted as a web service that clients connect to directly
- 🔄 Hybrid deployment: Offer both package and remote options for maximum flexibility
Learn more about MCP server architecture in the official docs.
Step 1: Install the Publisher CLI
⬇️ macOS/Linux/WSL: Pre-built binaries
curl -L "https://github.com/modelcontextprotocol/registry/releases/download/v1.0.0/mcp-publisher_1.0.0_$(uname -s | tr '[:upper:]' '[:lower:]')_$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/').tar.gz" | tar xz mcp-publisher && sudo mv mcp-publisher /usr/local/bin/
🏗️ macOS/Linux/WSL: From source
Requires Git, Make and Go 1.24+:
# Clone the registry repository
git clone https://github.com/modelcontextprotocol/registry
cd registry
make publisher
# The binary will be at bin/mcp-publisher
export PATH=$PATH:$(pwd)/bin
🪟 Windows PowerShell: Pre-built binaries
$arch = if ([System.Runtime.InteropServices.RuntimeInformation]::ProcessArchitecture -eq "Arm64") { "arm64" } else { "amd64" }; Invoke-WebRequest -Uri "https://github.com/modelcontextprotocol/registry/releases/download/v1.0.0/mcp-publisher_1.0.0_windows_$arch.tar.gz" -OutFile "mcp-publisher.tar.gz"; tar xf mcp-publisher.tar.gz mcp-publisher.exe; rm mcp-publisher.tar.gz
# Move mcp-publisher.exe to a directory in your PATH
Step 2: Initialize Your server.json
Navigate to your server's directory and create a template:
cd /path/to/your/mcp-server
mcp-publisher init
This creates a server.json with auto-detected values. You'll see something like:
{
"$schema": "https://static.modelcontextprotocol.io/schemas/2025-07-09/server.schema.json",
"name": "io.github.yourname/your-server",
"description": "A description of your MCP server",
"version": "1.0.0",
"packages": [
{
"registry_type": "npm",
"identifier": "your-package-name",
"version": "1.0.0"
}
]
}
Step 3: Configure Your Server Details
Edit the generated server.json:
Choose Your Namespace
The name field determines authentication requirements:
io.github.yourname/*- Requires GitHub authenticationcom.yourcompany/*- Requires DNS or HTTP domain verification
Configure Deployment Methods
Configure your server to support packages, remotes, or both:
Package Deployment
Add package validation metadata to prove ownership of your packages.
📦 NPM Packages
Requirements
Add an mcpName field to your package.json:
{
"name": "your-npm-package",
"version": "1.0.0",
"mcpName": "io.github.username/server-name"
}
How It Works
- Registry fetches
https://registry.npmjs.org/your-npm-package - Checks that
mcpNamefield matches your server name - Fails if field is missing or doesn't match
Example server.json
{
"name": "io.github.username/server-name",
"packages": [
{
"registry_type": "npm",
"identifier": "your-npm-package",
"version": "1.0.0"
}
]
}
The official MCP registry currently only supports the NPM public registry (https://registry.npmjs.org).
🐍 PyPI Packages
Requirements
Include your server name in your package README file using this format:
MCP name format: mcp-name: io.github.username/server-name
Add it to your README.md file (which becomes the package description on PyPI). This can be in a comment if you want to hide it from display elsewhere.
How It Works
- Registry fetches
https://pypi.org/pypi/your-package/json - Passes if
mcp-name: server-nameis in the README content
Example server.json
{
"name": "io.github.username/server-name",
"packages": [
{
"registry_type": "pypi",
"identifier": "your-pypi-package",
"version": "1.0.0"
}
]
}
The official MCP registry currently only supports the official PyPI registry (https://pypi.org).
📋 NuGet Packages
Requirements
Include your server name in your package's README using this format:
MCP name format: mcp-name: io.github.username/server-name
Add a README file to your NuGet package that includes the server name. This can be in a comment if you want to hide it from display elsewhere.
How It Works
- Registry fetches README from
https://api.nuget.org/v3-flatcontainer/{id}/{version}/readme - Passes if
mcp-name: server-nameis found in the README content
Example server.json
{
"name": "io.github.username/server-name",
"packages": [
{
"registry_type": "nuget",
"identifier": "Your.NuGet.Package",
"version": "1.0.0"
}
]
}
The official MCP registry currently only supports the official NuGet registry (https://api.nuget.org).
🐳 Docker/OCI Images
Requirements
Add an annotation to your Docker image:
LABEL io.modelcontextprotocol.server.name="io.github.username/server-name"
How It Works
- Registry authenticates with container registries using token-based authentication:
- Docker Hub: Uses
auth.docker.iotoken service - GitHub Container Registry: Uses
ghcr.iotoken service
- Docker Hub: Uses
- Fetches image manifest using Docker Registry v2 API
- Checks that
io.modelcontextprotocol.server.nameannotation matches your server name - Fails if annotation is missing or doesn't match
Example server.json (Docker Hub)
{
"name": "io.github.username/server-name",
"packages": [
{
"registry_type": "oci",
"registry_base_url": "https://docker.io",
"identifier": "yourusername/your-mcp-server",
"version": "1.0.0"
}
]
}
Example server.json (GitHub Container Registry)
{
"name": "io.github.username/server-name",
"packages": [
{
"registry_type": "oci",
"registry_base_url": "https://ghcr.io",
"identifier": "yourusername/your-mcp-server",
"version": "1.0.0"
}
]
}
The identifier is namespace/repository, and version is the tag and optionally digest.
The official MCP registry currently supports Docker Hub (https://docker.io) and GitHub Container Registry (https://ghcr.io).
📁 MCPB Packages
Requirements
MCP reference - MCPB package URLs must contain "mcp" somewhere within them, to ensure the correct artifact has been uploaded. This may be with the .mcpb extension or in the name of your repository.
File integrity - MCPB packages must include a SHA-256 hash for file integrity verification. This is required at publish time and MCP clients will validate this hash before installation.
How to Generate File Hashes
Calculate the SHA-256 hash of your MCPB file:
openssl dgst -sha256 server.mcpb
Example server.json
{
"name": "io.github.username/server-name",
"packages": [
{
"registry_type": "mcpb",
"identifier": "https://github.com/you/your-repo/releases/download/v1.0.0/server.mcpb",
"file_sha256": "fe333e598595000ae021bd27117db32ec69af6987f507ba7a63c90638ff633ce"
}
]
}
File Hash Validation
- Authors are responsible for generating correct SHA-256 hashes when creating server.json
- MCP clients validate the hash before installing packages to ensure file integrity
- The official registry stores hashes but does not validate them
- Subregistries may choose to implement their own validation. This enables them to perform security scanning on MCPB files, and ensure clients get the same security scanned content.
The official MCP registry currently only supports artifacts hosted on GitHub or GitLab releases.
Remote Deployment
Add the remotes field to your server.json (can coexist with packages):
🌐 Remote Server Configuration
Requirements
- Service endpoint: Your MCP server must be accessible at the specified URL
- Transport protocol: Choose from
sse(Server-Sent Events) orstreamable-http - URL validation: For domain namespaces only (see URL requirements below)
Example server.json
{
"$schema": "https://static.modelcontextprotocol.io/schemas/2025-07-09/server.schema.json",
"name": "com.yourcompany/api-server",
"description": "Cloud-hosted MCP server for API operations",
"version": "2.0.0",
"remotes": [
{
"type": "sse",
"url": "https://mcp.yourcompany.com/sse"
}
]
}
Multiple Transport Options
You can offer multiple connection methods:
{
"remotes": [
{
"type": "sse",
"url": "https://mcp.yourcompany.com/sse"
},
{
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/http"
}
]
}
URL Validation Requirements
- For
com.yourcompany/*namespaces: URLs must be onyourcompany.comor its subdomains - For
io.github.username/*namespaces: No URL restrictions (but you must authenticate via GitHub)
Authentication Headers (Optional)
Configure headers that clients should send when connecting:
{
"remotes": [
{
"type": "sse",
"url": "https://mcp.yourcompany.com/sse",
"headers": [
{
"name": "X-API-Key",
"description": "API key for authentication",
"is_required": true,
"is_secret": true
}
]
}
]
}
Step 4: Authenticate
Choose your authentication method based on your namespace:
GitHub Authentication (for io.github.* namespaces)
mcp-publisher login github
This opens your browser for OAuth authentication.
DNS Authentication (for custom domains)
# Generate keypair
openssl genpkey -algorithm Ed25519 -out key.pem
# Get public key for DNS record
echo "yourcompany.com. IN TXT \"v=MCPv1; k=ed25519; p=$(openssl pkey -in key.pem -pubout -outform DER | tail -c 32 | base64)\""
# Add the TXT record to your DNS, then login
mcp-publisher login dns --domain yourcompany.com --private-key $(openssl pkey -in key.pem -noout -text | grep -A3 "priv:" | tail -n +2 | tr -d ' :\n')
Step 5: Publish Your Server
With authentication complete, publish your server:
mcp-publisher publish
You'll see output like:
✓ Successfully published
Step 6: Verify Publication
Check that your server appears in the registry by searching for it:
curl "https://registry.modelcontextprotocol.io/v0/servers?search=io.github.yourname/weather-server"
You should see your server metadata returned in the JSON response.
Troubleshooting
"Package validation failed" - Ensure your package includes the required validation metadata (mcpName field, README mention, or Docker label).
"Authentication failed" - Verify you've correctly set up DNS records or are logged into the right GitHub account.
"Namespace not authorized" - Your authentication method doesn't match your chosen namespace format.
Examples
See these real-world examples of published servers:
Next Steps
- Update your server: Publish new versions with updated server.json files
- Set up CI/CD: Automate publishing with GitHub Actions
- Learn more: Understand server.json format in depth
- More examples: See remote server configurations and hybrid deployments in the schema documentation
What You've Accomplished
You've successfully published your first MCP server to the registry! Your server is now discoverable by MCP clients and can be installed by users worldwide.