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.
Consuming the MCP Registry REST API
The base URL for the MCP Registry REST API ishttps://registry.modelcontextprotocol.io. It supports the following endpoints:
GET /v0.1/servers— List all servers.GET /v0.1/servers/{serverName}/versions— List all versions of a server.GET /v0.1/servers/{serverName}/versions/{version}— Get a specific version of a server. Use the special versionlatestto get the latest version of the server.
GET /v0.1/servers endpoint.
Pagination
TheGET /v0.1/servers endpoint supports cursor-based pagination.
For example, the first page can be fetched using a limit query parameter:
Output
nextCursor value as the cursor query parameter:
Filtering Since
TheGET /v0.1/servers endpoint supports filtering servers that have been updated since a given timestamp.
For example, servers that have been updated since 2025-10-23 can be fetched using an updated_since query parameter in RFC 3339 date-time format:
Server Status
Server metadata is generally immutable, except for thestatus field which may be updated to, e.g., "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 our permissive moderation policy, suggesting the server might be spam, malware, or illegal. Aggregators may prefer to remove these servers from their index.
Acting as a Subregistry
A subregistry is an aggregator that also implements the OpenAPI spec defined by the MCP Registry. This allows clients, such as 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:
server.json
"com.example.subregistry/custom" in the above example).