Building a Production Model Context Protocol (MCP) Ecosystem for AI Agents

pinterest · Tech · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Production MCP ecosystem for internal engineering agents

Pinterest needed a standardized, secure, observable way for AI agents in chats, IDEs, and internal workflows to call real engineering tools and data systems without creating one-off integrations, silently expanding data access, or letting automated actions mutate sensitive systems without governance.

Constraints:

• AI agents needed to automate engineering tasks rather than only answer questions
• bespoke integrations for every model and tool would not scale
• MCP servers can touch real systems and sensitive internal data such as Presto-backed data
• tool discovery and invocation needed user-level attribution, access control, and least privilege
• sensitive or expensive automated actions required human approval
• the ecosystem needed observable invocation, error, tool, server, and time-savings metrics

Architecture

Pinterest built a cloud-hosted MCP ecosystem with many small domain-specific MCP servers, a central registry, unified deployment pipeline, security review, JWT and mesh-identity authorization, business-group access gating, channel/tool restrictions, human-in-the-loop approval for sensitive actions, and built-in telemetry. Internal chat, IDE, AI bot, and agent surfaces discover approved servers through the registry API, authenticate through Pinterest's internal auth stack, and bind authorized MCP tools into their agent toolsets.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  ai-work-surfaces[AI work surfaces] --> internal-auth-stack[Internal auth stack]
  ai-work-surfaces --> mcp-registry[MCP registry]
  ai-work-surfaces --> mcp-toolset-binding[MCP toolset binding]
  internal-auth-stack --> envoy-gateway[Envoy gateway]
  mcp-registry --> mcp-server-fleet[MCP server fleet]
  mcp-toolset-binding --> mcp-server-fleet
  unified-deployment-pipeline[Unified deployment pipeline] --> mcp-server-fleet
  security-review-workflow[Security review workflow] --> mcp-registry
  envoy-gateway --> mcp-server-fleet
  envoy-gateway --> policy-decorators[Policy decorators]
  policy-decorators --> mcp-server-fleet
  mcp-server-fleet --> presto-mcp-server[Presto MCP server]
  mcp-server-fleet --> spark-mcp-server[Spark MCP server]
  mcp-server-fleet --> knowledge-mcp-server[Knowledge MCP server]
  mcp-server-fleet --> human-approval-layer[Human approval layer]
  mcp-server-fleet --> telemetry-library[Telemetry library]
  telemetry-library --> impact-metrics[Impact metrics]

Components

Data flow

A team defines tools for a domain-specific MCP server and deploys it through Pinterest's unified pipeline. The server appears in the internal MCP registry after review, with owner, support, status, security posture, visible tools, and production approval. When a user in web chat, an IDE plugin, or an AI bot invokes an agent, the client performs OAuth against internal auth, sends a JWT to the registry and target server, Envoy maps user/group headers, policy decorators enforce fine-grained tool access, and telemetry records inputs, outputs, invocations, exceptions, and estimated time saved.

Why this architecture

Pinterest optimized MCP for production governance rather than local experimentation. Cloud-hosted servers let internal routing and security logic apply consistently; multiple domain-specific servers kept contexts small and access controls precise; the registry became the production approval and discovery backbone; and a unified deployment pipeline reduced the operational burden that would otherwise block domain teams from building useful tools.

Models used: LLMs via internal AI chat · AI agents using MCP tools

Scale

• As of January 2025, Pinterest reported 66,000 MCP invocations per month.
  “As of January 2025, MCP servers have ramped up to 66,000 invocations per month across 844 monthly active users. Using these estimates, MCP tools are saving on the order of 7,000 hours per month.”article, stated
• The ecosystem had 844 monthly active users.
  “As of January 2025, MCP servers have ramped up to 66,000 invocations per month across 844 monthly active users. Using these estimates, MCP tools are saving on the order of 7,000 hours per month.”article, stated
• Pinterest estimated MCP tools saved about 7,000 hours per month.
  “As of January 2025, MCP servers have ramped up to 66,000 invocations per month across 844 monthly active users. Using these estimates, MCP tools are saving on the order of 7,000 hours per month.”article, stated
• The internal LLM web chat interface is used by the majority of Pinterest employees daily.
  “Our internal LLM web chat interface is used by the majority of Pinterest employees daily. The frontend automatically performs OAuth flows where required, and returns a list of usable tools for the current user, scoped to respect security policies.”article, stated
• Pinterest's MCP ecosystem evolved over one year from exploration to production integrations.
  “Over the last year, Pinterest has gone from “MCP sounds interesting” to running a growing ecosystem of Model Context Protocol (MCP) servers, a central registry, and production integrations in our IDEs, internal chat surfaces, and AI agents.”article, stated

Alternatives considered (roads not taken)

Use local MCP servers as the production paved path

Rejected because: Pinterest wanted centralized routing, security logic, and operational consistency for production use.

Build one monolithic MCP server

Rejected because: A monolith would crowd the model context and make access controls less precise than domain-specific servers.

Make each team build full server infrastructure before writing tools

Rejected because: Early feedback showed the deployment and service setup burden was too high.

Use the MCP OAuth standard with per-server consent prompts

Rejected because: Pinterest piggybacked on existing internal auth sessions and handled authorization transparently through Envoy and policy decorators.

Grant all authenticated employees access to sensitive MCP servers

Rejected because: Data-heavy tools such as Presto required business-group gating so broad surfaces would not silently expand sensitive data access.

Patterns

tool-use-orchestration (mcp-integration)

Pinterest uses MCP as a unified protocol for agents to call Presto, Spark, Knowledge, Airflow, and other internal tools from chat, IDE, and agent surfaces.

safety-policy-enforcement (governance)

Production MCP servers require security review, owning teams, registry approval, JWT/mesh authorization, business-group gates, and policy decorators.

human-in-the-loop-gate (action-safety)

Agents can propose sensitive or expensive MCP-powered actions, but humans approve or reject before execution and elicitation confirms dangerous actions.

observability-tracing (mcp-operations)

All MCP servers use shared logging/telemetry libraries for inputs, outputs, invocation counts, exceptions, and impact analysis.

privacy-preserving-processing (data-access)

Business-group access gating and user-level attribution prevent broad AI surfaces from expanding access to sensitive internal data.

rag-retrieval (knowledge-access)

The Knowledge MCP server gives agents a company knowledge endpoint for internal Q&A, documentation, and debugging across internal sources.

Tradeoffs

Standardize on cloud-hosted MCP servers for production

Chose internal cloud-hosted MCP servers over local stdio servers as the paved production path.

Rationale: Centralized hosting lets Pinterest apply routing, security, governance, and operational controls consistently.

Use many domain-specific MCP servers

Chose Presto, Spark, Airflow, Knowledge, and other focused servers over one giant MCP server.

Rationale: Focused servers reduce context clutter, allow domain ownership, and enable different access controls by tool domain.

Use existing internal auth rather than per-server OAuth UX

Chose JWTs from internal auth plus Envoy and policy decorators over extra login prompts and per-server consent screens.

Rationale: Pinterest could preserve fine-grained authorization without exposing per-server auth complexity to end users.

Require human approval for sensitive automated actions

Chose human-in-the-loop and elicitation over fully autonomous execution of expensive or sensitive tool actions.

Rationale: Automation speed increases risk when tools can overwrite data or touch real systems.

Use time saved as the north-star metric

Chose estimated minutes saved per invocation times invocation counts over only raw invocation or server counts.

Rationale: Time saved gives a value-oriented view of impact, while still being treated as directional because estimates are owner-provided.

Gotchas (what bit them)

MCP tool access can silently expand sensitive data reach.

Root cause: A popular surface like web chat can reach data-heavy MCP servers such as Presto unless access is gated beyond authentication.

Resolution: Pinterest uses business-group access gating, user JWTs, Envoy policies, and per-tool decorators.

New MCP server creation initially had too much operational overhead.

Root cause: Teams had to handle deployment pipelines, service configuration, and operations before writing business logic.

Resolution: Pinterest built a unified deployment pipeline so teams define tools while the platform handles deployment and scaling.

A monolithic MCP server would overload context and governance.

Root cause: Putting all tools behind one server would expose irrelevant tools together and make access control less granular.

Resolution: Pinterest uses multiple small domain-specific servers with separate ownership and access controls.

Automated agents increase the blast radius of tool actions.

Root cause: MCP servers enable agents to call tools that affect real systems and data at automation speed.

Resolution: Sensitive or expensive actions require human-in-the-loop approval and elicitation confirmation.

Impact metrics are useful but only directional.

Root cause: Minutes saved per invocation are owner-provided estimates based on lightweight feedback and prior manual workflows.

Resolution: Pinterest treats time saved as an order-of-magnitude signal rather than rigorous causal measurement.

Evaluation

Pinterest evaluates the MCP ecosystem through operational telemetry and impact metadata: registered server/tool counts, invocation counts, inputs/outputs, exceptions, user-level attribution, monthly active users, directional minutes saved per invocation, and estimated total hours saved.

Metrics: number of MCP servers registered · number of tools registered · invocations across all servers · inputs and outputs logged · exception traces · monthly active users · estimated minutes saved per invocation · estimated hours saved per month

Outcomes

• Pinterest moved from MCP exploration to a production ecosystem of cloud-hosted MCP servers, a central registry, and integrations across IDEs, internal chat surfaces, and AI agents.
• Presto became the highest-traffic MCP server, Spark powered AI debugging, and Knowledge served company knowledge/Q&A use cases.
• The registry became the production approval and discovery backbone for humans, AI clients, and services.
• Security controls include MCP Security Standard review, end-user JWTs, mesh identities, Envoy policies, business-group gating, and per-tool authorization decorators.
• Human-in-the-loop and elicitation controls govern sensitive or expensive automated actions.
• As of January 2025, Pinterest reported 66,000 monthly invocations, 844 monthly active users, and about 7,000 hours saved per month.

The ecosystem is used by majority-daily internal LLM web chat users and reported 66,000 MCP invocations per month across 844 monthly active users, with directional estimates of 7,000 engineering hours saved per month.