What Is the MCP Registry?

The MCP Registry is the official centralized metadata repository for publicly accessible Model Context Protocol servers. It standardizes names, versions, packages, remote endpoints, installation instructions, and configuration data, then exposes that metadata through a REST API.

The Registry solves a distribution problem: clients need one predictable way to locate an MCP server, determine whether it is a package or remote endpoint, and learn which configuration values are required. It does not replace the MCP protocol handshake, the server's runtime tool list, or your own security review.

Do not treat the Registry as npm for MCP code. npm, PyPI, NuGet, Docker Hub, and other package registries host artifacts; the MCP Registry hosts metadata that points to those artifacts. Remote servers can instead publish a public Streamable HTTP endpoint in the same metadata contract.

The official Registry is designed primarily as an upstream source for clients and downstream aggregators. A downstream directory can enrich the source metadata with search, rankings, usage signals, organizational policy, or security scanning. QVeris can add task-oriented capability discovery, but the selected server's current contract and permissions still require inspection.

How the MCP Server Directory Works

The MCP Registry works through three contracts: versioned server.json metadata, namespace and package ownership checks, and a REST API consumed by clients and downstream registries. These boundaries matter because publishing metadata is not the same as approving a server for production use.

Registry role and ecosystem boundaries

The official Registry is an open, centralized metadata service in the Model Context Protocol ecosystem. It is supported by major ecosystem contributors and documented at the official MCP Registry site. Its role is deliberately narrow: authenticate namespaces, host standardized metadata, and expose an API. Artifact hosting, installation security, and production approval remain separate concerns.

The server.json Schema

Every published version uses a server.json manifest that identifies the server, version, package or remote endpoint, transport, and required configuration. It is a distribution contract; runtime tools, resources, and prompts are discovered from the MCP server after connection.

// server.json - package-backed MCP server
{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "io.github.example/market-data",
  "title": "Market Data",
  "description": "Historical and real-time market data",
  "repository": {
    "url": "https://github.com/example/mcp-market-data",
    "source": "github"
  },
  "version": "1.0.0",
  "packages": [{
    "registryType": "npm",
    "identifier": "@example/mcp-market-data",
    "version": "1.0.0",
    "transport": {
      "type": "stdio"
    },
    "environmentVariables": [{
      "name": "MARKET_DATA_API_KEY",
      "description": "Provider API key",
      "isRequired": true,
      "isSecret": true
    }]
  }],
  "_meta": { "category": "finance" }
}

The manifest answers deployment questions: where the package or remote server lives, how a client starts or connects to it, and which environment variables or URL variables are required. Tool input schemas do not belong in this publication manifest; the client discovers them from the running MCP server.

Validation, ownership, and moderation

Publishing validates the manifest and checks that the publisher controls the declared namespace and underlying package metadata. That is not a manual security audit. The official moderation policy says the Registry largely relies on upstream package registries and downstream registries for deeper moderation.

The official Registry may remove malware, spam, illegal content, or non-functioning servers, but it generally does not remove a server merely for low quality, bugs, duplication, or known vulnerabilities. Consumers must still inspect provenance, pin a version, review requested secrets and permissions, and sandbox untrusted local servers.

How to Use the MCP Registry: Discover and Publish

The Registry supports two distinct workflows: consumers query versioned installation metadata, while publishers register a public package or remote endpoint. Keep discovery, installation, runtime inspection, and trust evaluation as separate steps.

Discovering MCP Servers

Use one of these three paths depending on whether you need source metadata, enriched discovery, or production approval:

Path 1: Official Registry API

Visit registry.modelcontextprotocol.io to search the official source or call its REST API. Results expose names, versions, package or remote locations, repository metadata, transports, and required configuration. They do not replace a live MCP connection for discovering current tools, resources, and prompts.

Path 2: Community Directories

Community directories like Smithery.ai and Glama.ai can ingest official metadata and add filters, rankings, reviews, policy, security signals, or additional sources. Treat each directory's enrichment as a separate claim: verify freshness, provenance, and moderation rather than assuming broader coverage means safer results.

Path 3: Task-oriented capability discovery

When an agent starts with a task rather than a server name, use a capability discovery layer such as QVeris to identify candidates. Then inspect the selected capability's current contract, provider, cost signals, secrets, and permissions before calling it. The official Registry remains the source for MCP publication metadata:

# Search the official Registry API
curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=market%20data"

# Inspect one server version before installation
curl "https://registry.modelcontextprotocol.io/v0.1/servers/io.github.example%2Fmarket-data/versions/1.0.0"

# Publisher workflow from the server project
mcp-publisher init
# Authenticate the matching namespace
mcp-publisher login github
# Publish the current server.json version
mcp-publisher publish

# Verify the published metadata through the API
curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.example%2Fmarket-data"
# Expected result includes the exact server name
"name": "io.github.example/market-data"
{ ... }

QVeris and the official Registry solve different layers of the workflow. QVeris can help an agent discover a capability by task; the Registry describes how a published MCP server version is located and configured. Neither layer removes the need to validate the actual runtime response and enforce least privilege.

How to Publish Your MCP Server: Step-by-Step

Publishing requires a public artifact or remote endpoint, a valid server.json, ownership evidence, and an authenticated namespace. The official quickstart uses this four-step production sequence:

There is no documented 1–3 day manual approval queue in the official quickstart. Publication succeeds after authentication and validation, or returns a concrete error such as package validation failure, expired credentials, or a namespace permission mismatch.

MCP Registry vs Sub-Registries: When to Use Which

The official Registry is an upstream metadata service. Downstream registries and directories consume that source and may add search, moderation, security signals, organizational policy, or task-level routing. Choose the layer that matches the decision you are making.

The Architecture Distinction

The official MCP Registry is a metadata repository — it stores versioned server.json records and exposes names, package or remote locations, transports, repository information, and configuration requirements. Package registries still host the actual artifacts.

Sub-registries like QVeris are capability routing layers — they can ingest source metadata, add their own evidence and policy, and expose a task-level interface to agents. Their rankings, reviews, tests, and coverage are downstream claims and should be evaluated independently.

A useful mental model is software supply-chain layers: the package registry stores an artifact, the official MCP Registry publishes a standardized pointer and configuration contract, and a downstream directory helps decide whether that server is relevant or acceptable.

Which Should You Use?

Use the official Registry when publishing, querying exact source metadata, or implementing the Registry API. Use a downstream layer when your primary problem is relevance, security enrichment, enterprise policy, or dynamic task-to-capability matching.

Many production systems use both layers: source metadata from the official API, enrichment from one or more downstream services, and an internal approval gate before installation or execution. QVeris can support capability discovery, while your application remains responsible for trust and runtime controls.

Top MCP Server Directories Compared

Compare ecosystem layers by responsibility rather than volatile server counts. A larger index is not automatically safer, fresher, or more useful for a particular agent.

The layers complement one another. Publish the artifact first, publish MCP metadata second, enrich or approve the record third, and only then allow an agent to install or call the server under explicit permissions and observability.

How We Evaluated These Directories

We evaluate Registry workflows across six production dimensions. Source authority: Does the record come from the official API, an upstream package registry, or another index? Version integrity: Can the exact server and artifact version be pinned and reproduced? Ownership evidence: Does the namespace match the authenticated publisher and package metadata? Discovery quality: Are search results explainable, fresh, and traceable to source metadata? Runtime fit: Does the actual server expose the expected tools, transport, authentication, and error behavior? Security controls: Can the application sandbox execution, restrict secrets and permissions, and revoke access?

This comparison uses official Registry documentation reviewed August 3, 2026. The service remains in preview, so API behavior, schema versions, supported package types, and moderation rules can change. Verify the current official contract before deployment.

Production Evaluation: Three Questions to Ask

Before production use, answer three questions. First: Can we verify and reproduce this exact version? Trace server.json to the package or remote endpoint, repository, publisher namespace, and immutable version. Second: What authority will the server receive? Review every secret, filesystem path, network destination, OAuth scope, and user-confirmation boundary. Third: What happens when it fails or changes? Test startup, authentication, timeouts, rate limits, malformed responses, concurrency, rollback, and revocation before enabling agent access.

A Registry listing is the start of evaluation, not the final approval. Keep an internal allowlist that records the approved version, evidence, permissions, owner, review date, and rollback path. If QVeris is used for discovery, preserve the selected provider and inspection result in the execution audit trail.

FAQ: MCP Registry