Building an MCP Ecosystem at Pinterest

Over the past year, Pinterest has moved beyond "MCP is interesting" to build an operational system complete with Model Context Protocol (MCP) servers, a central registry, and integrations with IDEs, internal chat, and AI agents. The core purpose is to let LLMs handle tools and data safely through a standardized protocol, so they can take on real engineering work—log analysis, bug investigation, proposing PRs—rather than just answering questions.

The initial design prioritized internally hosted cloud servers over local servers, since deployment and security controls are easier to apply through internal routing. Rather than one giant server, the team chose to run multiple small, domain-specific servers.

• Presto MCP server: the highest-traffic server, letting IDEs and agents pull database results instantly and use them within workflows.
• Spark MCP server: used for diagnosing Spark job failures, summarizing logs, and recording structured RCAs.
• Knowledge MCP server: a general-purpose knowledge endpoint for internal documentation and Q&A.

To make it easy to spin up new servers, the team also built a unified deployment pipeline so that teams can focus solely on defining tools while the platform handles the rest of the infrastructure, deployment, and scaling. On top of this, an MCP registry serves as the single source of truth for approved servers. The registry's web UI lets humans check a server's owning team, support channel, security status, live status, and visible tools, while its API lets AI clients discover and verify servers and determine "can this user use server X?"

The actual consumption points are clearly defined. The internal LLM web chat, internal AI bot, and IDE plugin all go through the registry API to authenticate and check permissions, and once connected, they call MCP tools the same way as any regular agent tool. Policies can also restrict tools per channel—for example, Spark tools can be opened only in specific support channels.

Security and governance were treated as a distinct concern from the start. Every non-experimental server must have a designated owning team, be registered in the internal registry, and pass Security / Legal·Privacy / GenAI review approval, and this process determines the server's access policy and allowed groups. At runtime, nearly all MCP calls enforce dual authentication via end-user JWT and mesh identity.

• JWT-based user flow: when a user logs into the internal auth stack via OAuth, a JWT is issued; Envoy validates it and sets headers like X-Forwarded-User and X-Forwarded-Groups, then applies coarse-grained policy.
• Inside the server, finer-grained permissions are enforced with decorators such as @authorize_tool(policy=...).
• Business-group-based gating ensures sensitive servers like Presto can only have sessions opened by approved groups, not all employees.
• Some servers require a JWT even at the tool discovery stage, leaving a user-level audit trail.

Conversely, for low-risk, read-only cases, Pinterest also runs a service-only flow that relies solely on SPIFFE-based auth. Unlike the per-server OAuth consent flow suggested by the MCP standard, Pinterest leverages the fact that user authentication is already completed at the internal surface level, handling authorization transparently without a separate login window or consent dialog.

Since agents can touch real systems, human-in-the-loop is also essential. Sensitive or costly actions are proposed by the agent and executed only after a human approves or rejects them, with risky actions requiring an additional elicitation confirmation.

Observability was built in from the start as well. Every server is provided with telemetry—input/output logging, invocation count, exception tracing—through a shared common library. Metrics are aggregated into a north-star metric called time saved, combining the number of servers, number of tools, total invocation count, and time saved per invocation as assigned by each tool owner.

In the end, what Pinterest built is not a single-server demo but an internal MCP platform connecting registration-permissions-deployment-audit-observability. By layering security and operations on top of a standard protocol, they've expanded it into an environment where agents can take on real work.