Dora NodaPinterest's engineers now run 66,000 AI agent tool calls a month against production data infrastructure — Presto queries, Spark job diagnostics, Airflow orchestration — from 844 active engineers, saving an estimated 7,000 hours of engineering time monthly. That's not a demo number. It's what happens when a Model Context Protocol deployment survives contact with a real company's security, legal, and data-governance requirements.
The interesting part isn't the invocation count. It's the architectural choice that made that count survivable: Pinterest didn't build one monolithic MCP server that does everything, and it didn't let every team spin up its own one-off server either. It built several domain-specific servers — one for Presto, one for Spark, one for Airflow, one for general institutional knowledge — sitting behind a single central registry that every client, human or agent, has to go through. That pattern, documented in Pinterest Engineering's account of building its MCP ecosystem, is the most detailed public case study yet of what MCP looks like once it stops being a side project and starts being infrastructure a company depends on. Here's what it actually contains, what it left out, and what it means for any platform — including a git-push PaaS whose own AI-agent tools are just getting started — building the same thing at a tenth the scale.
Why "One Server, or a Server Per Team" Both Break
Before getting into what Pinterest built, it's worth being concrete about the problem a registry solves, because it isn't obvious from the outside. An MCP client discovers what a server can do by calling tools/list, which returns every tool's name, description, and full JSON schema — and all of that gets loaded into the model's context window before a single tool is ever called. That's fine at five tools. It stops being fine once an organization has real tool sprawl.
Cloudflare hit this wall badly enough that it had to build a custom replacement for MCP's default tool-discovery mechanism specifically to stop it from overflowing the context window as its internal tool count grew. And Pinterest's own scale isn't an outlier anymore: the public MCP ecosystem crossed roughly 10,000 tracked servers by May 2026, according to registries including PulseMCP, Smithery, and the official registry.modelcontextprotocol.io. A single company running dozens of internal servers is now a normal shape, not an edge case.
The naive fixes both fail. One monolithic server that exposes every tool for every domain becomes exactly the kind of context-window-crowding, blast-radius-maximizing single point of failure Pinterest was trying to avoid — a bug or a bad access-control decision in the query layer now also affects orchestration and knowledge lookup.
The opposite failure mode is just as bad: every team stands up its own MCP server with no shared discovery, no shared auth pattern, no shared review process. That's what Pinterest's own engineers flagged as early, blocking feedback — spinning up a new MCP server required too much work, repeated per team, with no consistency in how each one handled permissions or observability.
Pinterest split the difference: multiple domain-specific servers (small blast radius, coherent tool sets, independent access policies per domain) unified by one thing every client has to go through before it can use any of them — the registry.
What the Registry Actually Does
Stripped of marketing language, Pinterest's registry is two things: a web UI for humans and an API for AI clients, both reading from the same source of truth about which MCP servers are approved for production use. Concretely, for every server it tracks:
- Team ownership. No server exists without an accountable owner — a direct answer to "who do I page when the Spark tool starts returning garbage."
- Security posture and live health. Whether the server is currently passing its governance review, and whether it's actually up, are both queryable before a client tries to call it.
- The tool listing itself. What tools this specific server exposes, so a client — human developer in the internal chat UI, or an agent operating autonomously — can discover capability without a person hand-pointing it at a URL.
- Connectivity metadata. How to actually reach the server once a client has decided to use it.
None of that is exotic. What makes it load-bearing is that it's the only path to production. Pinterest's MCP Security Standard requires every server to be tied to an owning team, listed in the registry, and to clear Security, Legal/Privacy, and GenAI review before it's usable in production — and business-group-based access gating on top of that, so a server showing up in a broad-audience chat surface doesn't silently expand who can actually query sensitive data through it. The registry isn't just a phone book. It's the enforcement point for governance that would otherwise have to be duplicated, inconsistently, inside every server's own code.
Two Layers of Auth, and a Human Veto on the Dangerous Stuff
The part of Pinterest's writeup that's genuinely worth stealing is the authorization design, because it solves a problem that gets hand-waved in most MCP tutorials: how does a tool call inherit a human's actual permissions instead of running as one shared service credential that can do anything any tool anywhere is allowed to do?
Pinterest's answer is two layers. For end-user-facing tools, an OAuth flow issues a JWT tied to the actual employee, which Envoy validates at the edge and maps into X-Forwarded-User and X-Forwarded-Groups headers before a request ever reaches a tool. Individual tools then declare their own access rules with @authorize_tool(policy=...) decorators — so the Presto MCP server can, in principle, let one group query one set of tables and block another, without every tool author reinventing an auth stack.
Because it piggybacks on the SSO session an employee already has, nobody hits a fresh login prompt per MCP server — a detail Pinterest calls out explicitly, and one every enterprise MCP deployment eventually has to solve or accept endless consent-prompt friction. For lower-risk, service-to-service, read-only paths, Pinterest instead uses SPIFFE mesh identity, since those operations don't need a human identity at all.
Layered on top of both paths is a human-in-the-loop gate for anything destructive: agents propose sensitive actions and use MCP's elicitation mechanism to make a human explicitly confirm before anything irreversible executes. That's the same shape as a "confirm before destroy" flow, generalized to arbitrary tool calls instead of hardcoded into one product's deploy button.
The Gap Pinterest's Own Writeup Leaves Open
Not every piece of "discovery, auth, and versioning solved once instead of per-server" is actually documented in what Pinterest published. Discovery and auth are detailed in depth, as above. Versioning is not — Pinterest's account describes the registry tracking "connectivity metadata" and live health, but says nothing about how it handles a tool's schema changing under agents that already depend on the old shape, or how a deprecated tool gets sunset without breaking whoever's still calling it.
That's a real gap, and it's worth naming instead of papering over, because the broader MCP ecosystem only just closed it at the protocol level. The 2026-07-28 MCP specification release candidate formalizes a feature lifecycle — Active, Deprecated, Removed — with a hard floor: once something is marked Deprecated, it has to stay available for at least twelve months (or a minimum of ninety days under an expedited security-driven removal) before it can be removed. If Pinterest's registry adopts that lifecycle for the tools it fronts, that's the versioning discipline the invocation numbers imply must exist somewhere, even though the public writeup doesn't spell out the mechanism.
What This Means Once a Platform's Own Tool Count Grows
A self-hosted, git-push PaaS built for AI agents to operate — deploy, roll back, check logs, scale a service — starts in the same place Pinterest did: a small, hand-countable set of MCP tools where a shared API key and an ungoverned tool list are tolerable because there's nothing to get lost. Pinterest's writeup is useful precisely because it documents where that stops being true, in concrete, load-bearing detail rather than as a hypothetical:
- Per-tool authorization scoped to identity, not one shared credential. Pinterest's
@authorize_tool(policy=...)pattern maps cleanly onto a deploy platform: a rollback tool and a log-tail tool shouldn't inherit the same blast radius just because they're both "MCP tools this platform exposes." Scoping deploy/rollback permissions to the calling agent's actual git or account identity — the same identity a human already authenticates with — is the direct equivalent of Pinterest piggybacking on existing SSO sessions instead of minting a new credential per tool. - Confirm-before-destroy as a protocol-level pattern, not a UI checkbox. Pinterest's elicitation-based human veto on sensitive actions is the same shape a deploy-from-chat tool needs for anything that isn't trivially reversible — and MCP already ships the primitive to implement it, rather than requiring a bespoke confirmation dialog bolted onto one client.
- A registry entry before a tool count multiplies, not after. Pinterest's own early complaint — new servers took too much effort to stand up consistently — is the failure mode to avoid preemptively. A platform whose MCP surface is still small enough to hold in one person's head is exactly the point at which adding lightweight ownership and status metadata is cheap, and the point at which skipping it is easiest to justify.
- A version-deprecation policy decided before the first breaking tool-schema change, not during the incident that follows one. The MCP spec's own Active/Deprecated/Removed lifecycle, with its twelve-month floor, is a ready-made answer a platform can adopt instead of inventing one under pressure the first time an agent breaks against a schema that changed out from under it.
Two Different Registries, Easy to Conflate
One distinction is worth being explicit about, because "MCP registry" gets used for two genuinely different things. The official public MCP registry — backed by Anthropic, GitHub, PulseMCP, and Microsoft, and holding roughly 9,600 latest server records as of May 2026 — is a metaregistry: it indexes metadata pointing at publicly published server packages on npm, PyPI, or similar, the same way npm itself indexes packages rather than hosting every developer's private code. It answers "what public MCP servers exist and where do I get them."
Pinterest's registry answers a completely different question: "of the servers my own company runs against my own company's data, which ones are actually approved for production, who owns them, and what is any given employee or agent allowed to do through them." Listing a server in the public registry solves discovery for open-source packages. It does nothing for the governance problem Pinterest actually had to solve — that's an internal system, purpose-built, with no public-registry equivalent to just adopt off the shelf. Any platform copying "we need an MCP registry" from Pinterest's example needs to be building the second kind, not assuming the first kind covers it.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with deploy/rollback/logs exposed as MCP tools an agent can call directly. Pinterest's registry pattern is a preview of what that surface needs once it grows past a handful of tools. Star the repo on GitHub or deploy your first app today.