Pinterest's MCP Ecosystem: How a Top-10 App Runs 66K Agent Invocations per Month in Production

Most MCP content focuses on setup tutorials and toy demos. Pinterest’s engineering team went further: they built a production MCP ecosystem that automates real engineering work — incident investigation, data pipeline management, code change proposals — at a scale of 66,000 monthly invocations across 844 engineers. Their engineering blog post, published in March 2026, is one of the most detailed enterprise MCP case studies available.

This guide breaks down Pinterest’s architecture, security model, governance framework, and the design decisions that made it work. Our analysis draws on Pinterest’s published engineering blog post, InfoQ’s coverage, and related industry sources — we research and analyze rather than testing implementations hands-on.

Why Pinterest Chose MCP

Before MCP, Pinterest’s AI integrations were ad hoc. Each team built its own wrappers around internal tools — Presto for queries, Spark for data processing, Airflow for workflow orchestration. The result was duplicated effort, inconsistent security models, and fragile integrations that broke when underlying tools changed.

MCP offered a standardized substrate: define tools once, expose them through a consistent protocol, and let any authorized AI client discover and call them. Pinterest’s engineering team framed the decision explicitly:

“By explicitly choosing an architecture of internal cloud-hosted, multiple domain-specific MCP servers connected via a central registry, we have built a flexible and secure substrate for AI agents.”

The key word is “substrate.” Pinterest isn’t treating MCP as a product feature — it’s infrastructure, the same way they treat their service mesh or data pipeline.

Architecture: Domain-Specific Servers, Not a Monolith

Pinterest’s most important architectural decision was to deploy multiple small MCP servers, each owning a narrow domain, rather than a single monolithic server exposing all tools.

Why Multiple Servers Matter

Concern	Monolith Problem	Pinterest’s Approach
Context bloat	LLM sees hundreds of tools, picks poorly	Each server exposes a small, coherent toolset
Access control	All-or-nothing permissions	Per-server authorization, team-gated
Blast radius	One bad tool affects everything	Failures isolated to one domain
Ownership	No clear team owns the integration	Domain teams own their server
Scaling	One bottleneck for all traffic	Independent scaling per workload

Known MCP Servers

Pinterest has built domain-specific MCP servers for at least:

Presto — SQL query execution against Pinterest’s data warehouse
Spark — large-scale data processing jobs
Airflow — workflow orchestration and DAG management

Each server exposes only the tools relevant to its domain. The Presto server handles query execution and result retrieval. The Airflow server manages DAG runs and monitoring. This separation means an AI agent working on a data pipeline issue only sees Airflow and Spark tools — not every tool in the company.

The Central Registry

The MCP registry is the architectural centerpiece. It serves as the single source of truth for:

Which MCP servers exist and are approved for production use
How to connect to each server (endpoints, transport)
Which users and teams are authorized to use which servers
Server health, status, and available tools

Registry Components

Web UI — A human-facing interface where engineers can:

Browse available MCP servers
See the owning team and support channels for each server
View security posture and compliance status
Check live server status and visible tools

API — A machine-facing interface that AI clients use to:

Discover available servers at runtime
Validate server identity and approval status
Check “Is this user allowed to use server X?” before any tool invocation
Retrieve connection metadata for approved servers

This two-interface approach is significant. The web UI solves the discoverability problem — engineers can find what’s available without reading Slack threads. The API solves the authorization problem — AI agents can’t call tools on servers they haven’t been pre-approved for.

How Discovery Works

When an AI client (IDE plugin, chat integration, or autonomous agent) starts a session:

It queries the registry API for available servers
The registry returns only servers the current user is authorized to access
The client connects to those servers and discovers their tools
Before each tool invocation, the client can re-verify authorization

This is different from the open MCP ecosystem where clients connect directly to servers. Pinterest adds a mandatory authorization layer between discovery and connection.

Security Model: Two-Layer Authentication

Pinterest’s security model uses two distinct identity layers, reflecting the reality that some MCP calls are human-initiated and others are fully automated.

Layer 1: End-User JWTs

When a human engineer triggers an MCP tool call — through an IDE integration or chat interface — the request carries a JSON Web Token (JWT) identifying the user. This JWT:

Proves the user’s identity to the MCP server
Carries group membership for authorization decisions
Enables audit trails back to a specific person
Integrates with Pinterest’s existing OAuth authentication

Layer 2: Service Mesh Identities

For fully automated agent flows (no human in the loop), MCP servers authenticate using mesh-based identities — the same infrastructure Pinterest uses for service-to-service communication. This means:

Agents running as services have cryptographic identities
MCP server-to-server calls use mutual TLS
Authorization can be based on service identity rather than user identity

Fine-Grained Access Controls

Beyond authentication, Pinterest implements authorization decorators on individual tools:

High-privilege actions (e.g., modifying production DAGs) are restricted to approved teams
Business-group gating limits server access to relevant engineering groups
Some tools require additional approval even from authorized users

This is notably more sophisticated than most MCP deployments, which rely on server-level access control at best.

Human-in-the-Loop: Mandatory for Sensitive Operations

Pinterest doesn’t fully trust AI agents for high-risk operations. Their system implements a mandatory human approval flow for sensitive tool calls:

An AI agent proposes an action (e.g., “restart this Airflow DAG”)
The system flags it as sensitive based on tool annotations
The human user reviews the proposed action
Only after explicit approval does the action execute

Pinterest uses MCP’s elicitation mechanism to implement this — the server can request additional input from the user before completing a tool call. For sensitive operations, that “additional input” is an explicit yes/no approval.

This pattern is critical for enterprise MCP adoption. It lets teams get the productivity benefits of AI-assisted tooling while maintaining the safety guarantees that compliance and security teams require.

Unified Deployment Pipeline

One of Pinterest’s most practical innovations is their unified deployment pipeline for MCP servers. Rather than requiring each team to figure out infrastructure independently, the platform provides:

Standardized deployment: Teams define their tools and business logic; the pipeline handles containerization, deployment, and infrastructure
Automatic scaling: MCP servers scale based on invocation volume without manual intervention
Consistent monitoring: All servers emit standardized metrics and logs
Compliance automation: Security and privacy reviews are built into the deployment process

This dramatically lowers the barrier for teams to create new MCP servers. A domain expert who understands Presto internals doesn’t need to become a DevOps expert to deploy an MCP server — they define their tools, and the pipeline does the rest.

Integration Points

Pinterest’s MCP ecosystem integrates with multiple AI surfaces:

IDE Integration

Engineers can invoke MCP tools directly from their development environment. This is the most common entry point for individual productivity tasks like running queries or checking pipeline status.

Internal Chat Platform

MCP tools are accessible through Pinterest’s internal communications platform, enabling collaborative AI-assisted workflows. An engineer investigating an incident can ask an AI agent to check Airflow DAG status, run diagnostic queries, and propose fixes — all within the chat thread.

Autonomous Agents

The most advanced integration: autonomous AI agents that can investigate incidents and propose code changes. These agents use multiple MCP servers in sequence — querying data sources, checking system status, and drafting pull requests — with human approval gates at critical steps.

Production Metrics

As of January 2025 (the most recent published data):

Metric	Value
Monthly invocations	66,000
Active users	844
Estimated hours saved per month	~7,000

The hours-saved estimate comes from user feedback comparing MCP-assisted workflows against manual approaches. At 844 active users, that’s roughly 8.3 hours saved per user per month — about two hours per week of engineering time reclaimed.

For a company of Pinterest’s scale (approximately 5,000 employees), 844 active users represents meaningful but not yet universal adoption. The numbers suggest MCP is past the early-adopter phase and moving toward mainstream internal use.

Design Decisions and Trade-offs

What Pinterest Got Right

Domain isolation over convenience. Multiple small servers are harder to set up than one big server, but the benefits — access control, context management, team ownership — compound as the ecosystem grows.

Registry-first architecture. Making discovery and authorization a centralized concern prevents the sprawl of unauthorized or forgotten MCP servers. Every server must be registered, reviewed, and approved.

Platform-level deployment. By providing a unified pipeline, Pinterest removed the biggest friction for new server creation — infrastructure setup — while maintaining consistent security and monitoring standards.

Human-in-the-loop by default. Rather than making safety an opt-in feature, Pinterest requires human approval for sensitive operations. This builds trust with security and compliance teams.

Open Questions

Scale of server fleet. Pinterest hasn’t disclosed how many MCP servers they operate. The three named servers (Presto, Spark, Airflow) likely represent a fraction of the total.

Agent autonomy boundaries. The blog post emphasizes human-in-the-loop, but doesn’t detail where the line is between actions agents can take autonomously and those requiring approval.

Cross-server workflows. When an agent needs tools from multiple servers (e.g., Airflow + Presto for pipeline debugging), how is the multi-server session managed? The published architecture doesn’t elaborate.

Cost tracking. At 66,000 invocations per month, the LLM inference costs are non-trivial. Pinterest hasn’t discussed how they track or allocate these costs across teams.

Lessons for Enterprise MCP Adoption

Pinterest’s experience offers concrete guidance for other organizations building production MCP ecosystems:

1. Start with Domain-Specific Servers

Don’t build one server that does everything. Start with one high-value domain (your most-used data tool, your incident management system) and expand.

2. Build the Registry Early

A central registry becomes more valuable as the server fleet grows, but it’s much harder to retrofit than to build from the start. Even with two or three servers, a registry establishes the pattern.

3. Integrate with Existing Auth

Pinterest’s JWT + mesh identity approach works because it builds on infrastructure they already had. Don’t invent a new auth system for MCP — extend your existing one.

4. Provide a Deployment Platform

If you want teams to create MCP servers, make it easy. A standardized deployment pipeline removes the biggest barrier to adoption.

5. Default to Human-in-the-Loop

Start with human approval for everything, then selectively remove approval gates for low-risk operations as you build confidence. The reverse — starting open and adding gates — is much harder.

6. Measure Impact

Pinterest’s 7,000-hours-per-month metric makes the business case tangible. Track time savings from the start, even with rough estimates.

How This Compares to Other Enterprise MCP Deployments

Pinterest is among the first companies to publish a detailed MCP production case study, but they’re not alone in building enterprise MCP ecosystems:

Block (formerly Square) is a Platinum AAIF member and has invested heavily in MCP integration
Bloomberg is exploring MCP for financial data access across their terminal and data products
Cloudflare offers MCP server hosting as a platform service
Microsoft’s Agent Governance Toolkit provides governance infrastructure that complements approaches like Pinterest’s

What makes Pinterest’s case study distinctive is the level of architectural detail and the concrete metrics. Most enterprise MCP discussions stay at the “we’re exploring it” level — Pinterest shows what production actually looks like.