Skip to main content
The MCP Registry is currently in preview. Breaking changes or data resets may occur before general availability. If you encounter any issues, please report them on GitHub.

Package Types

The MCP Registry supports several different package types, and each package type has its own verification method.

npm Packages

For npm packages, the MCP Registry currently supports the npm public registry (https://registry.npmjs.org) only. npm packages use "registryType": "npm" in server.json. For example:
server.json

Ownership Verification

The MCP Registry verifies ownership of npm packages by checking mcpName in package.json. The mcpName property MUST match the server name from server.json. For example:
package.json

PyPI Packages

For PyPI packages, the MCP Registry currently supports the official PyPI registry (https://pypi.org) only. PyPI packages use "registryType": "pypi" in server.json. For example:
server.json

Ownership Verification

The MCP Registry verifies ownership of PyPI packages by checking for the existence of an mcp-name: $SERVER_NAME string in the package README (which becomes the package description on PyPI). The string may be hidden in a comment, but the $SERVER_NAME portion MUST match the server name from server.json. For example:
README.md

NuGet Packages

For NuGet packages, the MCP Registry currently supports the official NuGet registry (https://api.nuget.org/v3/index.json) only. NuGet packages use "registryType": "nuget" in server.json. For example:
server.json

Ownership Verification

The MCP Registry verifies ownership of NuGet packages by checking for the existence of an mcp-name: $SERVER_NAME string in the package README. The string may be hidden in a comment, but the $SERVER_NAME portion MUST match the server name from server.json. For example:
README.md

Cargo (Rust) Packages

For Cargo packages, the MCP Registry currently supports the official crates.io registry (https://crates.io) only. Cargo packages use "registryType": "cargo" in server.json. For example:
server.json

Runtime Model

Cargo’s runtime model differs from npm/PyPI/NuGet. cargo install <crate> places the compiled binary on PATH at ~/.cargo/bin, after which MCP clients invoke it directly by name. There is no per-invocation runner equivalent to npx (npm), uvx (PyPI), or dnx (NuGet, .NET 10 SDK Preview 6+) — install is one-time, execution is by binary name. The Cargo example above intentionally omits runtimeHint for this reason. Rust MCP authors have two first-class distribution paths:
  • Cargo (registryType: cargo) — source-distributed via crates.io. End users need the Rust toolchain (rustup) to run cargo install. Idiomatic for the Rust ecosystem and consistent with how Rust CLIs are typically published.
  • MCPB (registryType: mcpb) — prebuilt binary distributed via GitHub or GitLab Releases. End users need no toolchain. Right choice if the priority is “no Rust toolchain required.”
Both paths are supported; the choice is the author’s. Cargo native support exists so Rust authors who prefer source distribution are not forced into the MCPB binary-packaging workaround.

Ownership Verification

The MCP Registry verifies ownership of Cargo packages by checking for the existence of an mcp-name: $SERVER_NAME string in the package README (which is rendered to HTML and served by crates.io’s static CDN). The $SERVER_NAME portion MUST match the server name from server.json. For example:
README.md
Cargo-specific gotcha: Unlike PyPI and NuGet (which preserve HTML comments in their README rendering), crates.io strips HTML comments during markdown→HTML conversion. The <!-- mcp-name: ... --> hidden-comment form that works for PyPI/NuGet does not work for cargo — the token will not appear in the rendered HTML the validator inspects. Cargo authors must include the mcp-name: token as visible markdown text. A simple bullet in the Links section is the recommended pattern.

Docker/OCI Images

For Docker/OCI images, the MCP Registry currently supports:
  • Docker Hub (docker.io)
  • GitHub Container Registry (ghcr.io)
  • Google Artifact Registry (any *.pkg.dev domain)
  • Azure Container Registry (*.azurecr.io)
  • Microsoft Container Registry (mcr.microsoft.com)
Docker/OCI images use "registryType": "oci" in server.json. For example:
server.json
The format of identifier is registry/namespace/repository:tag. For example, docker.io/user/app:1.0.0 or ghcr.io/user/app:1.0.0. The tag can also be specified as a digest.

Ownership Verification

The MCP Registry verifies ownership of Docker/OCI images by checking for an io.modelcontextprotocol.server.name annotation. The value of the io.modelcontextprotocol.server.name annotation MUST match the server name from server.json. For example:
Dockerfile

MCPB Packages

For MCPB packages, the MCP Registry currently supports MCPB artifacts hosted via GitHub or GitLab releases. MCPB packages use "registryType": "mcpb" in server.json. For example:
server.json

Verification

The MCPB package URL (identifier in server.json) MUST contain the string “mcp”. That can be as part of the .mcpb file extension or in the name of the repository. The package metadata in server.json MUST include a fileSha256 property with a SHA-256 hash of the MCPB artifact, which can be computed using the openssl command:
The MCP Registry does not validate this hash; however, MCP clients do validate the hash before installation to ensure file integrity. Downstream registries may also implement their own validation.