Dora NodaPinterest's engineering team spent a year building a fleet of MCP servers for its data infrastructure, and in April 2026 they published the numbers: 66,000 tool calls a month, 844 active users, roughly 7,000 engineering hours saved. Those are good headline stats, and most of the coverage stopped there. But if you're building a PaaS where an AI agent can type deploy or rollback into a chat window and have it actually happen, the total call volume isn't the number that matters. What matters is what Pinterest put between a chat client asking for something and a production system doing it — and what their real traffic shape implies about how tightly you should size that gate on day one, not after the first incident.
The architecture behind the headline numbers
Pinterest didn't build one MCP server that does everything. They built a fleet of domain-specific servers — one for Presto queries, one for Spark jobs, one for Airflow pipeline orchestration — each owning a small, coherent set of tools tied to a single infrastructure domain. That's a deliberate constraint, not an accident of org chart: a monolithic MCP server means every tool shares one blast radius, one set of scopes, one place where a bad call can reach anything the server is credentialed for. Splitting by domain means a Presto-query tool physically cannot reach the Airflow scheduler, no matter what an agent is tricked into asking for.
The piece that makes a fleet of servers governable, instead of just a scattered pile of them, is a central registry. It's the single source of truth for which servers are approved for production use, with a human-friendly UI and an API that internal AI clients and IDEs consult before a tool call goes anywhere. A server that isn't in the registry isn't callable — full stop. That single rule is what turns "any engineer can spin up an MCP server" from a governance nightmare into a catalog with an owner behind every entry.
Getting into that registry isn't automatic, either. Pinterest runs a dedicated MCP Security Standard: any server that isn't a one-off experiment needs an owning team, and it needs to clear Security, Legal/Privacy, and — where relevant — GenAI compliance review before it's allowed into production. Those reviews are what decide the server's actual security policy: which user groups can reach it, what its tools are allowed to touch. And on top of the registry sits a two-layer authorization model — end-user JWTs govern the human-in-the-loop calls a person's chat session makes, while service-to-service calls run under mesh identities instead. A person asking an agent to do something and a background job doing something on a schedule are authenticated through two different paths, deliberately.
Put the whole thing in order and the request path looks like this: a chat client wants to call a tool → it checks the registry to confirm the server is approved and resolve how to reach it → the call lands at the right domain-specific server → if the tool is tagged as sensitive, a human-in-the-loop approval gate holds it before it executes → only then does it touch Presto, Spark, or Airflow. Registry first, gate second, execution last. That ordering is the actual pattern worth copying — not "Pinterest uses MCP," which by itself says nothing about how the calls are being caught.
Where the same shape sits in front of a deploy tool
Map that path onto a PaaS's own MCP server — the one fronting deploy, rollback, scale, and destroy — and the registry and the gate land in two different, specific places, not one blended "security layer."
The registry sits between the chat client and the platform's MCP server, and it does exactly one job: confirm the tool being called is a registered, approved tool and that the caller's JWT scope actually includes it. This is the same check Pinterest runs before a call ever reaches Presto — it's a lookup, not a judgment call, and it should reject anything not in the catalog before the platform API sees the request at all.
The approval gate is a second, later check, and it isn't keyed to "is this an MCP call" — it's keyed to what the specific tool can do if it's wrong. That gives a natural tiering, the same shape recognizable from any blast-radius-based access model, applied to deploy verbs specifically:
| Tier | Example tools | Gate behavior | What gets logged |
|---|---|---|---|
| 0 — read-only | list_services, get_deploy_status, tail_logs | No gate — full audit only | Tool, caller identity, timestamp |
| 1 — reversible state change | deploy, scale_up, restart | Auto-approved, rate-limited, async notify | + arguments, result, latency |
| 2 — destructive or hard-to-reverse | rollback, scale_to_zero, set_env_var, destroy_app | Synchronous human approval required | + approver identity, approval timestamp |
That table is the concrete artifact a "registry-plus-gate" architecture actually cashes out to: two independent checkpoints, one that confirms a tool is allowed to exist in this conversation at all, and one that confirms a specific risky call gets a human's sign-off before it runs. Skip the registry check and an agent could invoke a tool nobody approved for production. Skip the tier-2 gate and an agent could roll back a production release because a tool description told it to, with no human in the loop at all.
Sizing the gate from Pinterest's own traffic, not a guess
Here's the part usage numbers are actually good for: sizing the policy before you've seen your own production traffic. Pinterest's 66,000 monthly invocations across 844 active users works out to about 78 calls per user per month — roughly 2.6 calls per active user per day. That's not a hypothetical; it's what a chat-ops MCP surface looks like in practice once real engineers have adopted it for real work, at one company, over a year.
Two adjustments turn that baseline into a day-one starter policy instead of a Pinterest-specific artifact:
- The traffic mix is different, and the limit should follow the mix, not the total. Pinterest's 78 calls/user/month are overwhelmingly Tier-0-equivalent — Presto queries, log reads, pipeline status checks. A deploy-from-chat surface's Tier 2 calls (rollback, destroy, env-var changes) will be a much smaller slice of an operator's daily activity than their Tier 0 reads are. That argues for not applying one rate limit uniformly across all tools, but binding tightest on Tier 2 specifically: a starting policy of roughly 8 Tier-1 calls per user per day (about 3x the Pinterest-observed baseline, to leave headroom for CI-triggered redeploys and iterative debugging) makes sense as a ceiling before requiring step-up re-authentication — while Tier 2 calls get no volume-based limit at all, because the gate there is per-call human approval, not a quota.
- The audit window should outlast the incident window, not the billing cycle. A 90-day rolling audit trail — the retention window that shows up repeatedly across enterprise MCP gateway deployments — covers the realistic gap between a bad rollback happening and someone noticing the pattern in a post-incident review, which is usually weeks, not days. Every logged call should carry the tool name, the server it hit, the exact arguments, the result, the latency, the caller's identity, and (for Tier 2) the approver's identity — the same field set Pinterest's own registry-backed authorization model implies, since JWT identity is already flowing through every call.
Neither number is exact — they're a starting policy sized from the one large-scale production data point publicly available, not a law of physics. But "8 Tier-1 calls per user per day, 90-day retention, human sign-off on every Tier 2 call" is a policy you can write into a config file today. "Add rate limiting eventually" is not.
Why this has to be day-one, not a hardening pass
The reason to build the registry and the tiered gate before the first deploy tool call ever runs, rather than after, is that the two orderings produce structurally different audit trails. Retrofit the gate later, and every call the agent made before the retrofit landed is unaudited by construction — there's no policy to check it against, because none existed yet. Build the gate first, and the agent's action space is provably bounded from the very first tool call: nothing runs that isn't in the registry, nothing destructive runs without a human's sign-off, and every call — approved or not — lands in a log with 90 days of retention behind it.
That's also the order Pinterest actually enforced: security, legal, and GenAI review gate a server's entry into the registry, not a scan that runs after it's already been fielding production traffic. Governance came before launch, not after adoption. For a self-hosted PaaS letting an agent operate deploy and rollback directly, that's the one piece of Pinterest's year of production data worth copying exactly as-is.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with a Render-compatible API and agents as first-class operators through an MCP server built around exactly this registry-and-gate shape. Star the repo on GitHub or deploy your first app today.
Sources
- Pinterest Engineering: Building an MCP Ecosystem at Pinterest
- InfoQ: Pinterest Deploys Production-Scale Model Context Protocol Ecosystem for AI Agent Workflows
- ByteByteGo: How Pinterest Built a Production MCP Ecosystem
- AgentMarketCap: Pinterest's MCP Ecosystem — 66,000 Monthly Invocations, 844 Users, and 7,000 Hours Saved
- WorkOS: MCP authorization patterns — Per-tool scopes, consent, and least privilege
- MintMCP: Internal MCP Registry — How Platform Teams Govern AI Tool Access at Scale
- MintMCP: How to Build Audit Trails for AI Coding Agents — MCP Gateway Approach
