Skip to content

CONCEPT Cited by 1 source

MCP registry

Definition

An MCP registry is an organisation-internal authoritative catalog of approved MCP servers — the source of truth for which servers are allowed to serve production traffic at a given organisation, plus the metadata that humans and AI clients need to discover + validate + authorize against them.

"The MCP registry is the source of truth for which MCP servers are approved and how to connect to them. … This is also the backbone for governance: only servers registered here count as 'approved for use in production.'" (Source: sources/2026-03-19-pinterest-building-an-mcp-ecosystem-at-pinterest)

Two surfaces, two audiences

Pinterest's canonical shape has two distinct consumer surfaces:

  • Web UI for humans — discover servers, see owning team + support channels + security posture + live status + visible tools.
  • API for AI clients — AI agents + chat platforms + IDE integrations discover + validate servers + ask "Is this user allowed to use server X?" pre-flight.

The asymmetry is load-bearing: humans want discoverability (browsing), agents want machine-readable pre-flight authorization. One data model, two rendering surfaces.

What the registry authoritatively answers

  1. "Which MCP servers exist in production?" — enumeration.
  2. "Who owns server X?" — attribution + support routing.
  3. "What's the security posture of server X?" — which reviews passed, which user groups approved.
  4. "Is user Y allowed to use server X?" — pre-flight authorization.
  5. "What's the live status of server X?" — health + reachability.
  6. "What tools does server X expose?" — tool list + schemas.

Relationship to MCP Server Card + API Catalog

  • MCP Server Card (draft public standard, /.well-known/mcp/server-card.json) — per-server, public, static JSON. One server publishes its own card; agents do pre-connect discovery without auth.
  • API Catalog (RFC 9727) — per-service, public, static JSON at /.well-known/api-catalog. Classical HTTP-API sibling.
  • MCP registry — organisation-internal, multi-server, policy-layer. N servers, one catalog + one authorization API.

These compose rather than compete: a Pinterest MCP server could theoretically publish a public MCP Server Card and be listed in the internal MCP registry. The card handles "I exist and here's my tool schema"; the registry handles "I'm approved at Pinterest, here's who can use me."

Why organisation-internal registries emerge

Public per-server cards + RFC-9727 catalogs solve discovery in an open-web setting. Inside a company, three needs the public primitives don't cover drive the registry pattern:

  1. Production-approval as a gate. "Only servers registered here count as 'approved for use in production.'" The registry is where Security / Legal / GenAI review outcomes become enforcement.
  2. Per-user authorization. The registry's API answers "Is this user allowed to use server X?" before the agent makes the call — critical for business-group-gated servers like Pinterest's Presto MCP.
  3. Organisational metadata. Owning team, support channels, and security posture are Pinterest-internal entities that don't belong in a public per-server card.

Seen in

Last updated · 319 distilled / 1,201 read