Registry

Registry model

A lightweight way to publish trusted MCP servers, issuers, and revocations — without inventing a new protocol.

Typical endpoints (illustrative)

Implementations may vary, but most registries expose a predictable set of endpoints for discovery, lookups, and revocation status. 

GET /mcp/servers
GET /mcp/servers/{did}
GET /mcp/search?capability=...&tag=...&org=...

GET /mcp/issuers
GET /mcp/revocations
Policy-first discovery

The registry exists to support policy decisions: “only allow servers attested by issuer X”, “minimum assurance level Y”, “block servers with write access unless explicitly approved”, and similar guardrails.

Federation friendly

You can run a local registry for internal tools, consume public registries, or federate across partners.

Recommended operational practices
  • Keep a “default deny” posture for new servers.
  • Use revocation lists and deprecation markers.
  • Prefer stable identifiers (DIDs) over URLs.
  • Audit capability drift (manifest changes) regularly.
Explore registry reference work Join discussions