Skip to content

SYSTEM Cited by 1 source

Pinterest MCP Registry

Definition

The Pinterest MCP Registry is Pinterest's internal source of truth for which MCP servers are approved for production use across the company. It sits at the centre of Pinterest's hosted-MCP ecosystem (Source: sources/2026-03-19-pinterest-building-an-mcp-ecosystem-at-pinterest) and serves two distinct audiences with two distinct surfaces.

Two surfaces

Web UI (for humans)

"lets humans discover servers, the owning team, corresponding support channels, and security posture. The Web UI also shows the MCP server's live status and visible tools."

Human-facing fields:

  • Server name / description.
  • Owning team + support channels.
  • Security posture summary (reviews passed, approved user groups).
  • Live status (healthy / unhealthy).
  • Visible tools + their schemas.

API (for AI clients)

"lets AI clients (e.g., our internal AI chat platform, AI agents on our internal communications platform, IDE integrations) discover and validate servers, and lets internal services ask 'Is this user allowed to use server X?' before letting an agent call into it."

AI-client operations:

  • Discover the set of approved MCP servers.
  • Validate a server (is it still in the registry, is the endpoint correct).
  • Pre-flight authorize a user against a server before an agent makes the call.

Governance backbone

"This is also the backbone for governance: only servers registered here count as 'approved for use in production.'"

Unregistered MCP servers can exist (experimental / local / sandbox) but are not approved for production traffic. Every production MCP server at Pinterest:

  1. Must be tied to an owning team.
  2. Must appear in the registry.
  3. Must have gone through Security, Legal/Privacy, and (where applicable) GenAI review — all three must be approved before production use.
  4. Has per-server access policies (which user groups can reach it) determined during review and enforced in Envoy.

Relationship to the MCP Server Card standard

The MCP Server Card is a draft public standard for a server to advertise itself at /.well-known/mcp/server-card.json so agents can do pre-connect discovery without authenticating. Pinterest's MCP Registry is the organisation-internal sibling:

  • MCP Server Card — public, per-server, unauthenticated, agent-facing. One server, one card.
  • Pinterest MCP Registry — internal, cross-server, authentication-required (for both humans and AI clients in many flows), catalog-surface. N servers, one catalog + policy layer.

Both answer "which MCP servers exist and can I use them?" at different altitudes. Card is the per-server static-catalog shape; Registry is the org-level policy + discovery shape. They compose cleanly — a Pinterest MCP server could theoretically publish a public MCP Server Card while still requiring Registry-mediated pre-flight authorization for internal access.

Composition with auth + mesh

Pinterest's auth layering runs around the Registry, not inside it:

  • Client → OAuth against Pinterest's internal auth stack → JWT issued.
  • Client connects to Registry with JWT → Registry resolves MCP-server endpoint + metadata + pre-flight authorization decision.
  • Client connects to target MCP server with same JWT → Envoy validates JWT, maps to X-Forwarded-User + X-Forwarded-Groups headers, enforces coarse per-server policy.
  • Server-side @authorize_tool(policy='…') decorator (patterns/per-tool-authorization-decorator) enforces fine-grained per-tool authorization.

The Registry is the discovery + approval surface; Envoy is the enforcement surface; the in-server decorator is the per-tool-granularity enforcement surface. All three talk to the same underlying JWT + business-group claims.

Seen in

Last updated · 319 distilled / 1,201 read