Dora NodaPinterest's AI agents don't answer questions about the data platform. They reach into it — querying Presto, diagnosing Spark jobs, managing Airflow workflows — about 66,000 times a month. That number, published by Pinterest engineering in April 2026 alongside 844 monthly active users and an estimated 7,000 engineering hours saved per month, makes it the most detailed public case study of the Model Context Protocol running at production scale. And the most interesting part isn't the protocol at all.
The motivation was arithmetic. Five AI surfaces (an internal chat app, IDE plugins, chatbots, CLI agents, autonomous agents) times ten internal tools means fifty bespoke integrations without a shared protocol. MCP collapses that multiplication into addition: one client per surface, one server per tool. But as Pinterest's engineers put it, implementing the protocol turned out to be the easy part. The real engineering went into everything around it: a central registry, a two-layer auth system, a unified deployment pipeline, and observability baked in from day one.
The TL;DR for platform teams: if you're building a first-party MCP server that lets agents deploy apps — exposing deploy, rollback, and logs tools instead of data-platform queries — Pinterest's blueprint translates directly, but the risk tiers shift.
Read-only tools (logs, status) can auto-run like Pinterest's queries. Mutating tools (deploy, scale) need the human-approval gate Pinterest puts on sensitive operations. And destructive tools (rollback in production, destroy) need something stricter than anything Pinterest's read-mostly fleet demonstrates: explicit elicitation plus scoped per-action credentials and a full audit trail. The rest of this post is the evidence for that mapping.
Many small servers, not one monolith
Pinterest explicitly rejected the single-giant-MCP-server design. Instead it runs a fleet of cloud-hosted, domain-specific servers — one per system agents need to touch:
| MCP server | What agents do with it | Scope control |
|---|---|---|
| Presto | Query data in natural language instead of hand-writing SQL | Restricted to Ads, Finance, and infra teams |
| Spark | Diagnose job failures, summarize logs into root-cause analyses | Only surfaced in relevant support channels |
| Airflow | Manage and monitor data pipelines | Team-specific access |
| Docs / ticketing | Search internal docs, investigate bug tickets | Broad, low-sensitivity |
Two details here are worth stealing. First, the servers are hosted, not local: agents connect to centrally run servers rather than each engineer running their own stdio subprocess. That single decision is what makes the registry, auth layers, and observability below possible at all — you can't govern what you can't see. Second, tool scoping is context-aware: Spark MCP tools only appear in Airflow support channels, keeping tool lists relevant and preventing users from invoking tools that make no sense in context.
For a deploy-tools server, the parallel is immediate. A deploy tool should not appear with the same prominence in every context, and a fleet of small servers (builds, deploys, logs, incidents) is easier to govern than one god-server with forty tools and one shared credential.
The registry is the governance backbone, not a phone book
Sitting under the whole fleet is Pinterest's internal MCP registry: the source of truth for which servers exist, who owns them, and how to connect. It has two faces — a web UI where humans browse servers, see live status, find owning teams and support channels, and inspect visible tools; and an API that agents and surfaces query programmatically for discovery.
The load-bearing sentence: only servers registered here count as approved for production use. The registry isn't a directory; it's the admission gate. A server gets in after a security review that sets its access policy (including which business groups may use it), and until then it doesn't exist as far as production agents are concerned.
This is the piece most self-hosted MCP efforts skip, and it's the one a deploy-tools server needs most. An agent that discovers deploy/rollback/logs tools through a registry — with ownership, version, and approval status attached — is governable. An agent with hardcoded endpoints and a shared API token is a demo. Pinterest's rule ports verbatim: only registered tools count as deploy-approved.
Two-layer auth in four steps
Pinterest's authorization model has two layers, and the request path is worth tracing end to end:
- OAuth produces a JWT. When an engineer opens any AI surface, they log in with their company account, producing a signed token encoding identity and group memberships. That JWT travels with every request.
- Envoy validates and coarse-gates. Before any request reaches an MCP server, it passes through Envoy, which checks the token signature and expiration, converts it into headers, and enforces broad rules — e.g., the production chat app may talk to the Presto server, but experimental dev-namespace servers are off-limits.
- Business-group gating on sensitive servers. The server extracts group membership from the JWT and checks it against an approved list set during security review. Presto is reachable from the broadly used chat interface, but only Ads, Finance, and certain infra teams can actually connect — turning on a powerful server in a popular surface doesn't silently expand who sees sensitive data.
- SPIFFE for service-to-service. Where no human is in the loop, the calling service proves identity via mesh-issued certificates instead of a user JWT — reserved for low-risk, read-only scenarios with tightly constrained blast radius.
For deploy tools, step 3 is the hinge: a deploy-to-production tool reachable from a general chat surface must still check team membership before doing anything. And step 4 draws the line Pinterest itself respects — unattended service identity is for reads, not for actions with blast radius.
Human-in-the-loop: propose, approve, then execute
Pinterest's agent guidance mandates human approval before any sensitive or expensive action. Agents propose; humans approve or reject — optionally in batches — before anything executes. For genuinely dangerous operations, Pinterest uses elicitation: the agent explicitly asks the user to confirm before doing something like overwriting data in a table.
Note what this implies about where the safety lives. It isn't in the model's judgment — it's in the platform: approval is a mandatory step in the execution path, not a suggestion in a system prompt. The MCP spec's own approval primitives exist precisely so hosts can enforce this structurally.
This is also where a deploy-tools server must go further than Pinterest's fleet. Overwriting a table is bad; rolling back the wrong production service during an incident is worse, and unlike a query it can't be un-run. The three mechanisms Pinterest names — single approval, batch approval, elicitation — map cleanly onto deploy tiers, which is exactly what the translation matrix below does.
Observability: how the 7,000-hours number is actually computed
Pinterest built observability into the ecosystem from the start. All servers share library functions providing input/output logging, invocation counts, and exception tracing out of the box — free for any team shipping through the unified deployment pipeline, which Pinterest calls the unlock that turned a platform-team project into an org-wide ecosystem.
The north-star metric deserves a careful read: for each tool, server owners provide a "minutes saved per invocation" estimate from lightweight user feedback and comparison against the prior manual workflow. Multiplied by invocation counts, that yields the headline — roughly 7,000 hours a month across 66,000 invocations and 844 users. It's an order-of-magnitude view, not a time-and-motion study, and Pinterest presents it honestly as one. The methodology caveat matters because it's also the template: if you ship deploy tools, define minutes-saved-per-invocation per tool up front or you'll never be able to say what the agent fleet is worth.
The PaaS translation: a tier × pattern matrix
Here's the blueprint applied to a deploy-tools MCP server, with Pinterest's four platform patterns as columns and tool-risk tiers as rows:
| Tool tier (examples) | Registry | Auth | Approval | Observability |
|---|---|---|---|---|
Read / auto-run (logs, status, list-deploys) | Registered, broadly discoverable | User JWT + Envoy coarse policy | None — runs immediately | Invocation counts + per-tool minutes-saved |
Mutate / approve (deploy, scale, promote) | Registered + marked mutating at review time | JWT + team-membership gating (only the owning team deploys its service) | Human approve/reject, batchable during rollouts | Full input/output logging + who-approved attribution |
Destructive / elicit (rollback in prod, destroy, delete-data) | Registered + flagged destructive; never in default tool scope | JWT + narrow group + scoped per-action credential minted for this execution | Explicit elicitation ("confirm rollback of api-prod to v1.42?") + audit trail | Everything above + immutable audit log with rollback pointer |
Three things change when the tool mutates infrastructure instead of querying data:
- Blast radius replaces data sensitivity as the gating variable. Pinterest gates Presto by who may see the data. Deploy tools gate by who may break the service — team ownership, environment (staging auto, production approve), and time (freeze windows) all feed the policy.
- Reversibility sets the tier, not the verb. A
deploywith instant rollback is tier 2; arollbackduring a data migration or anything that destroys state is tier 3. Classify tools by what undo costs, not by how dangerous the name sounds. - Credentials must narrow per action. Pinterest's SPIFFE carve-out is read-only for a reason. A deploy agent holding one broad production token violates the same principle — mint short-lived, per-action credentials so a compromised or confused agent can't reuse deploy authority for destroy authority.
The ecosystem tailwinds help: MCP SDK downloads run near 100 million a month, the official registry counts thousands of servers, and the protocol now sits under vendor-neutral governance in the Linux Foundation's Agentic AI Foundation. The protocol half of this matrix is commoditizing fast. The registry, approval, and audit half is still yours to build — which is precisely Pinterest's lesson: the spec was the easy part.
The protocol is table stakes; the platform is the product
Pinterest's fleet works at 66,000 invocations a month because the team invested where the leverage was: a registry that doubles as a governance gate, auth that binds every call to a human identity and team, approvals enforced by the platform rather than requested by the prompt, a deployment pipeline that makes the secure path the easy path, and measurement honest enough to defend. None of that ships inside the MCP spec. All of it is what "production MCP" actually means.
For a self-hosted PaaS, the starting point Pinterest suggests is pragmatic: seed a small set of high-leverage servers that solve real pain (logs and status before deploy, deploy before destroy), then invest in the platform work — especially the deployment pipeline — that lets other teams build on top. Get the tiers right early and the fleet can grow without growing the blast radius.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with agent-operable deploys as a first-class concern. Star the repo on GitHub or deploy your first app today.
