The official MCP Registry is a centralized metadata service for publicly accessible MCP servers. Publishers submit a standardized `server.json` record that identifies the server, version, packages or remote endpoints, and installation information. Clients and downstream catalogs can discover that metadata through a REST API.
The Registry is in preview, so its schemas and data may change before general availability. It is not a security endorsement, code review, package mirror, or private enterprise registry.
Publishing creates a supply-chain boundary. Users need to know who controls the namespace, which package or endpoint they will run, what version is immutable, and what permissions the server requests after installation.
The official Registry stores metadata for public servers. It can describe open-source or closed-source offerings when the installation method is public or the remote server is publicly reachable. It does not accept servers available only on private networks or private package registries.
Downstream aggregators and marketplaces are expected to consume Registry data and may add curation, reputation, policy, or installation UX. A listing in one catalog should be traced back to the exact upstream metadata and version rather than accepted by display name alone.
`server.json` provides a unique name, title, description, version, and one or more package or remote transport records. Package entries identify a public package location and transport configuration; remote entries identify a reachable server endpoint.
Metadata should describe what users are installing without exposing secrets, internal hosts, private registry URLs, or environment values. Keep the human description aligned with the actual capability surface and permission requirements.
Validate against the official schema for the Registry revision being used. A locally valid JSON file may still fail publication because namespace, package, version, or verification rules are not satisfied.
Namespaces prevent unrelated publishers from presenting servers under another organization’s identity. The Registry supports verification mechanisms such as DNS-based ownership for qualifying names. Choose a namespace the project can continue to control through maintainership changes.
A package name, repository owner, Registry namespace, display title, and remote domain may all differ. Document their relationship so users can verify that the metadata points to the intended publisher and artifact.
Do not solve a namespace conflict by adding lookalike punctuation or a misleading display title. Select an honest identity and publish migration guidance if ownership changes.
Each published server version must be unique, and published metadata cannot be edited in place. Correct a mistake by publishing a new version rather than mutating what an installer may already have resolved.
The Registry recommends semantic versioning but can store other unique version strings. Consistent semantic versions make sorting and upgrade policy easier; mixing formats can produce surprising “latest” behavior.
The server metadata version should identify the distribution record and align with the package or deployment it describes. Do not label one metadata version while silently moving its package tag or remote behavior to an incompatible implementation.
Package-based servers may be distributed through public ecosystems such as npm, PyPI, NuGet, or OCI-compatible registries when supported by the metadata schema. Installation frequently executes code on the user’s machine, so package ownership and integrity matter as much as MCP schema quality.
Pin dependencies, enable account protection for maintainers, sign releases where the ecosystem supports it, publish checksums or provenance, and avoid install scripts that perform unrelated network or filesystem actions. A host should show the exact package and version before installation.
Test the clean installation path on each supported platform. Documentation should list required runtime versions, environment variables, filesystem access, and network destinations without embedding secrets.
A remote listing points clients to a network service rather than a local package. The endpoint needs HTTPS, current authorization discovery, tenant isolation, rate limits, incident response, and stable ownership of the advertised domain.
Registry metadata cannot prove that the endpoint continues to serve the same implementation after publication. Monitor certificate, DNS, metadata, authorization, and capability changes, and require user review when a remote server materially expands permissions.
Keep test and production endpoints distinct. Do not publish an internal staging host or rely on a redirect that can later route installers to an unrelated domain.
Organizations with internal servers need a private inventory or registry. It can reuse the public metadata shape where useful, but it should integrate with enterprise identity, approval, package mirrors, vulnerability scanning, ownership records, and revocation.
A private catalog should answer who owns the server, which data classifications it can access, approved hosts, installation source, last security review, incident contact, and retirement status. Discovery without governance only makes unsafe software easier to find.
Before publication, compare metadata with the actual package or endpoint, install from scratch, inspect requested credentials and filesystem access, run capability discovery, verify license and support links, and test uninstall or disconnect behavior.
After publication, watch namespace and package accounts, dependency alerts, endpoint health, authorization changes, user reports, and unexpected capability expansion. Treat metadata updates as releases with review and provenance, not as marketing edits.
A Registry record is discovery metadata, not an approval badge. Before installation, trace the namespace owner, repository, package publisher or remote domain, immutable version, requested runtime, and expected permissions. Any unexplained identity transition is a reason to stop and verify.
Downstream catalogs may add ratings or policy, but users still need the exact upstream server name and version. Preserve that identity through install, update, connection, and incident records so a friendly title cannot hide a package or endpoint change.
This simplified example shows the relationship among identity, version, and one public package. Validate against the current official schema before publishing.
{
"$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
"name": "io.github.example/reporting-server",
"title": "Reporting MCP Server",
"description": "Read approved reporting datasets through bounded tools and resources.",
"version": "1.2.0",
"packages": [
{
"registryType": "npm",
"identifier": "@example/reporting-mcp",
"version": "1.2.0",
"transport": { "type": "stdio" }
}
]
}A small validator catches identity and artifact mismatches before the official schema and Registry checks run.
metadata = {
"name": "io.github.example/reporting-server",
"version": "1.2.0",
"packages": [{
"identifier": "@example/reporting-mcp",
"version": "1.2.0",
}],
}
errors = []
if "/" not in metadata["name"]:
errors.append("Server name must include a namespace")
for package in metadata["packages"]:
if package["version"] != metadata["version"]:
errors.append("Package and metadata versions differ")
print("PREFLIGHT PASS" if not errors else "PREFLIGHT FAIL")
for error in errors:
print("-", error)PREFLIGHT PASSThis does not replace official schema validation, namespace verification, or package-existence checks.
0 of 2 checked
Try this next
0 of 3 completed
No. It stores standardized metadata that points to public packages or remote servers. Package registries and server operators host the actual artifacts and services.
Yes, when the remote service is publicly accessible and its metadata meets Registry rules. Publication still does not disclose or certify the implementation.
Explore 500+ free tutorials across 20+ languages and frameworks.