Consuming Registry Data

The MCP Registry is currently in preview. Breaking changes or data resets may occur before general availability. If you run into issues, please report them on GitHub.

Aggregators are downstream consumers of the MCP Registry that provide additional value. For example, a server marketplace that provides user ratings and security scanning.

The MCP Registry provides an unauthenticated, read-only REST API that aggregators can use to populate their data stores. Aggregators are expected to scrape data on a regular but infrequent basis (for example, once per hour) and persist the data in their own data store. The MCP Registry does not provide uptime or data durability guarantees.

Consuming the MCP Registry REST API

The base URL for the MCP Registry REST API is https://registry.modelcontextprotocol.io. It supports the following endpoints:

URL path parameters such as serverName and version must be URL-encoded. For example, io.modelcontextprotocol/everything must be encoded as io.modelcontextprotocol%2Feverything.

Aggregators will most likely scrape the GET /v0.1/servers endpoint.

Pagination

The GET /v0.1/servers endpoint supports cursor-based pagination.

The first page can be fetched with a limit query parameter:

curl "https://registry.modelcontextprotocol.io/v0.1/servers?limit=100"
{
  "servers": [
    "..."
  ],
  "metadata": {
    "count": 100,
    "nextCursor": "com.example/my-server:1.0.0"
  }
}

Subsequent pages can be fetched by passing the nextCursor value as the cursor query parameter:

curl "https://registry.modelcontextprotocol.io/v0.1/servers?limit=100&cursor=com.example/my-server:1.0.0"

Filtering since

The GET /v0.1/servers endpoint supports filtering servers that have been updated since a given timestamp.

For example, servers updated since October 23, 2025 can be fetched using the updated_since query parameter in RFC 3339 date-time format:

curl "https://registry.modelcontextprotocol.io/v0.1/servers?updated_since=2025-10-23T00:00:00.000Z"

Server status

Server metadata is generally immutable, except for the status field which may be updated to values like "deprecated" or "deleted". We recommend that aggregators keep their copy of each server’s status up to date.

The "deleted" status typically indicates that a server has violated the permissive moderation policy, suggesting the server might be spam, malware, or illegal. Aggregators may prefer to remove these servers from their index.

Moderation policy: https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/moderation-policy.mdx

Acting as a subregistry

A subregistry is an aggregator that also implements the OpenAPI spec defined by the MCP Registry. This allows clients (for example, MCP host applications) to consume server metadata via a standardized interface.

The subregistry OpenAPI spec allows subregistries to inject custom metadata via the _meta field. For example, a subregistry could inject user ratings, download counts, and security scan results:

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "io.github.username/email-integration-mcp",
  "title": "Email Integration",
  "description": "Send emails and manage email accounts",
  "version": "1.0.0",
  "packages": [
    {
      "registryType": "npm",
      "identifier": "@username/email-integration-mcp",
      "version": "1.0.0",
      "transport": {
        "type": "stdio"
      }
    }
  ],
  "_meta": {
    "com.example.subregistry/custom": {
      "user_rating": 4.5,
      "download_count": 12345,
      "security_scan": {
        "last_scanned": "2025-10-23T12:00:00Z",
        "vulnerabilities_found": 0
      }
    }
  }
}

We recommend placing custom metadata under a key that reflects the subregistry (for example, "com.example.subregistry/custom" in the example above).