Watch

adam jones 32b37e71f8

Add registry authorization specification (#756 )

Add a standardized OAuth 2.1-based authentication specification for MCP
sub-registries, aligned with the MCP Authorization Specification.

This enables:
- Private registry entries with access control
- Permission-based server visibility
- Client code reuse (clients can use their existing MCP auth
implementation)

The spec is intended for downstream sub-registries. The official
registry remains public for reading.

Fixes #751

---------

Co-authored-by: Claude <noreply@anthropic.com>

2025-11-17 19:11:07 +00:00

2.7 KiB

Raw Blame History

Generic Registry API Specification

A standardized RESTful HTTP API for MCP registries to provide consistent endpoints for discovering and retrieving MCP servers.

Also see:

For guidance consuming the API, see the consuming guide.
For authentication and authorization, see the registry authorization specification.

Browse the Complete API Specification

📋 View the full API specification interactively: Open openapi.yaml in an OpenAPI viewer like Stoplight Elements.

The official registry has some more endpoints and restrictions on top of this. See the official registry API spec for details.

Quick Reference

Core Endpoints

GET /v0/servers - List all servers with pagination
GET /v0/servers/{serverName}/versions - List all versions of a server
GET /v0/servers/{serverName}/versions/{version} - Get specific version of server. Use the special version latest to get the latest version.
POST /v0/publish - Publish new server (optional, registry-specific authentication)

Server names and version strings should be URL-encoded in paths.

Authentication

No authentication required by default. Subregistries may optionally require authentication following the registry authorization specification.

Content Type

All requests and responses use application/json

Pagination

List endpoints use cursor-based pagination for efficient, stable results.

Usage

Initial request: Omit the cursor parameter
Subsequent requests: Use the nextCursor value from the previous response
End of results: When nextCursor is null or empty, there are no more results

Important: Always treat cursors as opaque strings. Never manually construct or modify cursor values.

Basic Example: List Servers

curl https://registry.example.com/v0/servers?limit=10

{
  "servers": [
    {
      "server": {
        "name": "io.modelcontextprotocol/filesystem",
        "description": "Filesystem operations server",
        "version": "1.0.2"
      },
      "_meta": {
        "io.modelcontextprotocol.registry/official": {
          "status": "active",
          "publishedAt": "2025-01-01T10:30:00Z",
          "isLatest": true
        }
      }
    }
  ],
  "metadata": {
    "count": 10,
    "nextCursor": "com.example/my-server:1.0.0"
  }
}

For complete endpoint documentation, view the OpenAPI specification in a schema viewer.

2.7 KiB Raw Blame History