MCP Registry Documentation

The MCP Registry (registry.modelcontextprotocol.io) follows a permissive moderation policy. It primarily removes illegal content, malware, spam, and non-functioning servers. Consumers should assume minimal-to-no moderation and treat scraped data accordingly, as the registry relies heavily on upstream registries (NPM, PyPI, Docker) for in-depth moderation.

Key Moderation Principles:

• What is removed: Illegal content (obscene content, copyright violations, hacking tools), malware, spam (mass-created servers, marketing-only servers, description stuffing), and non-functioning servers.
• What is NOT removed: Low-quality or buggy servers, servers with security vulnerabilities, duplicate functionality, or adult content.
• Removal mechanism: When a server is removed, its status is set to "deleted". The metadata remains accessible via the API unless the metadata itself is unlawful, in which case it may be erased.

The MCP Registry is designed around several core principles that govern how server metadata is managed and consumed. When building tools or integrations that interact with the registry, keep these constraints in mind:

• Single Source of Truth: The registry is the authoritative repository for MCP server metadata. Server creators publish once, and all consumers (clients, aggregators) reference this canonical data.
• Minimal Operational Burden: The system is designed for low maintenance. It delegates complexity to existing services (like GitHub for auth or npm/PyPI for packages) and assumes a reasonable downtime tolerance (up to 24h), meaning consumers should implement caching.
• Vendor Neutrality: The registry does not provide ranking, curation, or quality judgments. Curation decisions are left to the individual MCP clients and aggregators.
• Security Standards: Security relies on existing package registries for source code and uses DNS verification and OAuth for authentication. The registry implements rate limiting, field validation, and blacklisting to prevent abuse.
• Reusable Shapes over Infrastructure: The registry focuses on interface compatibility using reusable API shapes (like OpenAPI and server.json) rather than mandating specific infrastructure. This allows the same formats to be used for private or internal registries.
• Progressive Enhancement: The project follows an MVP-first approach, ensuring each milestone provides independent value without over-engineering for hypothetical future needs.

To apply changes across all versions of a server (e.g., marking an entire server as deleted or performing content scrubbing), you must iterate through all available versions.

1. List Versions: Fetch the list of all versions for the server.
2. Extract Versions: Use jq to pull the version strings into a text file.
3. Apply Changes: Loop through the version list and send a PUT request to each version's endpoint. For example, to mark all versions as deleted, append ?status=deleted to the URL.

export SERVER_NAME="com.example/my-server"
ENCODED_SERVER_NAME=$(echo "$SERVER_NAME" | sed 's|/|%2F|g')

# Step 1: List All Versions
curl -s "https://registry.modelcontextprotocol.io/v0/servers/${ENCODED_SERVER_NAME}/versions" > all_versions.json

# Step 2: Extract Versions
jq -r '.servers[].server.version' all_versions.json > versions.txt

# Step 3: Apply Changes to All Versions
while read VERSION; do
  echo "Processing version: $VERSION"
  curl -X PUT "https://registry.modelcontextprotocol.io/v0/servers/${ENCODED_SERVER_NAME}/versions/${VERSION}?status=deleted" \
    -H "Authorization: Bearer ${REGISTRY_TOKEN}" \
    -H "Content-Type: application/json"
done < versions.txt

rm versions.txt all_versions.json

You can use Google Cloud KMS for asymmetric signing. This requires the gcloud CLI and setting up Application Default Credentials (ADC).

1. Create a keyring and an Ed25519 signing key in your project.
2. Run mcp-publisher login http google-kms to retrieve the expected public key.
3. Copy the 'Expected proof record' to a file named mcp-registry-auth and host it at /.well-known/mcp-registry-auth on your domain.
4. Complete the login using the mcp-publisher login http google-kms command with the full resource path.

MY_DOMAIN="example.com"
MY_PROJECT="myproject"
MY_KEYRING="mykeyring"
MY_KEY_NAME="mykey"

# Setup Google KMS
gcloud auth login
gcloud config set project "${MY_PROJECT}"
gcloud kms keyrings create "${MY_KEYRING}" --location global
gcloud kms keys create "${MY_KEY_NAME}" --default-algorithm=ec-sign-ed25519 --purpose=asymmetric-signing --keyring="${MY_KEYRING}" --location=global
gcloud auth application-default login

# Retrieve public key for mcp-registry-auth
mcp-publisher login http google-kms --domain="${MY_DOMAIN}" --resource="projects/${MY_PROJECT}/locations/global/keyRings/${MY_KEYRING}/cryptoKeys/${MY_KEY_NAME}/cryptoKeyVersions/1"

# Final login command
mcp-publisher login http google-kms --domain="${MY_DOMAIN}" --resource="projects/${MY_PROJECT}/locations/global/keyRings/${MY_KEYRING}/cryptoKeys/${MY_KEY_NAME}/cryptoKeyVersions/1"