Skip to content

PATTERN Cited by 1 source

Hosted MCP ecosystem

Pattern

Hosted MCP ecosystem is the organisation-scale shape for deploying MCP at an enterprise: many small domain-specific MCP servers, all cloud-hosted (not local-on-laptop), all cataloged in a central registry, all gated by a shared auth + mesh substrate, all observably instrumented, all seeded with high-leverage servers before proliferation.

Canonical wiki instance: Pinterest's MCP ecosystem (Source: sources/2026-03-19-pinterest-building-an-mcp-ecosystem-at-pinterest), operating at 66,000 invocations/month across 844 MAUs and saving an estimated ~7,000 engineer-hours/month as of January 2025.

The six architectural choices

Pinterest's post makes six deliberate architectural choices, each with an explicit justification, that together constitute the pattern:

  1. Hosted over local. Cloud-deployed HTTP MCP servers; local stdio servers reserved for experimentation. Central execution is the only place internal routing + security + logging can be applied. See concepts/hosted-vs-local-mcp-server.

  2. Multiple small servers over one monolith. Domain-specific servers (Presto, Spark, Airflow, Knowledge) each own a coherent tool set. Per-server access control + context-window hygiene are the named reasons. patterns/tool-surface-minimization applied at the server-decomposition axis.

  3. Unified deployment pipeline. The platform handles infrastructure so MCP-server authoring collapses to business-logic-only. See patterns/unified-mcp-deployment-pipeline.

  4. Central registry as source of truth. "Only servers registered here count as 'approved for use in production.'" Two surfaces: human Web UI + AI-client API with pre-flight authorization. See systems/pinterest-mcp-registry + concepts/mcp-registry.

  5. Layered JWT + mesh auth. End-user JWTs validated at Envoy (coarse-grained: who reaches which server) + in-process @authorize_tool(policy='…') decorator (fine-grained: who calls which tool) + SPIFFE mesh identity for service-only flows. See patterns/layered-jwt-plus-mesh-auth + patterns/per-tool-authorization-decorator.

  6. Human-in-the-loop for mutations. Agent guidance mandates explicit user approval before sensitive / expensive actions. MCP elicitation primitive for dangerous-action confirmation ("overwrite data in a table"). See concepts/elicitation-gate.

Security-review as per-server-policy-generation

Each MCP server (that is not a one-off experiment) must clear three review gates before production:

  1. Security review.
  2. Legal / Privacy review.
  3. GenAI review (where applicable).

The review output determines the per-server access policies — which user groups can reach the server, which are enforced in Envoy. Reviews are not just approval/deny binary; they produce policy artefacts that drive enforcement.

Observability baked in

"All MCP servers at Pinterest use a set of library functions that provide logging for inputs/outputs, invocation counts, exception tracing, and other telemetry for impact analysis out of the box."

Ecosystem-level metrics: server count, tool count, invocation count, owner-supplied minutes-saved-per-invocation.

The north-star metric: time saved. Directional ("order-of-magnitude view") rather than precise. Owner-attested rather than independently measured. Trade-off made explicit in the post.

Seed-then-proliferate

"We started by seeding a small set of high-leverage MCP servers that solved real pain points, then let other teams build on top of that."

Seed set (Pinterest): Presto (data access), Spark (debugging), Knowledge (institutional Q&A). Each solves a concrete recurring pain point. Once the seed servers demonstrate value, other teams build their own domain servers onto the same registry + auth + deployment substrate.

Surface integrations

The hosted MCP ecosystem is load-bearing only if it's integrated into the surfaces where employees already work. Pinterest integrates into:

  • Internal LLM web chat — used daily by majority of employees; OAuth-backed, registry-driven tool discovery.
  • AI bots on internal chat platform — supports per-channel tool visibility ("Spark MCP tools are only available in Airflow support channels").
  • IDE plugins — agents in Cursor / Claude / etc. discover + call Pinterest MCP servers.

Each surface does OAuth once (employee already logged in) and binds MCP tools into the agent toolset transparently.

Contrast with the MCP OAuth spec

Pinterest explicitly rejects per-server OAuth consent flows:

"The MCP specification defines an OAuth 2.0 authorization flow where users explicitly authenticate with each MCP server, typically involving consent screens and per-server token management. Our approach is different: users already authenticate against our internal auth stack when they open a surface like the AI chat interface, so we piggyback on that existing session. There is no additional login prompt or consent dialog when a user invokes an MCP tool."

Enterprise-SSO piggybacking is the pragmatic enterprise counterpart to the protocol's per-server-OAuth shape. Shifts the complexity from user-facing consent dialogs to internal Envoy policy + decorator policies + registry allowlists.

Seen in

Last updated · 319 distilled / 1,201 read