Dora NodaIn November 2024, the Model Context Protocol launched to roughly 2 million monthly SDK downloads. By March 2026 it was doing 97 million SDK downloads a month across Python and TypeScript — a 48-fold climb in about sixteen months — with more than 10,000 active servers in production and governance donated to the Linux Foundation's Agentic AI Foundation. Every major model provider now speaks it. The protocol war for agent-to-tool connectivity is over, and MCP won the way USB-C won: by being the port everything plugs into.
But winning the protocol war only moved the hard problem one layer up. The moment your second team wants agent access to a different system, you face the question Pinterest's Agent Foundations team answered in production: one giant MCP server exposing everything, or a fleet of small domain servers behind a central registry — and who decides which agents may call what? Pinterest chose the fleet. Their March 2026 engineering writeup reports the results: more than 66,000 tool invocations a month across 844 active users, worth an estimated 7,000 engineering hours saved monthly. This post distills their registry-plus-domain-servers pattern into a blueprint you can steal for your own MCP surface — including where the monolith stops paying, how discovery and auth actually work at scale, and what it implies concretely for a deploy/rollback/logs toolset.
| Signal | Number | Source |
|---|---|---|
| MCP SDK downloads | ~2M/mo (Nov 2024) → 97M/mo (Mar 2026) | Ecosystem briefings, Mar–Apr 2026 |
| Active MCP servers | 10,000+ (10x year over year) | Ecosystem briefings, Feb–Apr 2026 |
| Pinterest monthly invocations | 66,000+ | Pinterest Engineering, Mar 2026 |
| Pinterest monthly active users | 844 | Pinterest Engineering, Mar 2026 |
| Pinterest estimated time saved | ~7,000 hrs/mo | Pinterest Engineering, Mar 2026 |
The protocol won. The hard part is everything around it.
Pinterest's starting arithmetic is worth restating, because it is the same arithmetic behind every internal platform: five agent surfaces (an internal chat app, IDE plugins, chatbots, CLI agents, autonomous agents) times ten internal tools is fifty bespoke integrations without a shared protocol. MCP collapses the multiplication into addition — one client per surface, one server per tool — as ByteByteGo's recap of the Pinterest build puts it. That was the easy part.
The real engineering, Pinterest says, went into everything around the protocol: a central registry, a two-layer auth system, a unified deployment pipeline, and observability baked in from day one. That sentence is the thesis of this post. If you are running an MCP surface that has grown past a demo — or planning a deploy/rollback/logs surface for agents that will touch production — the registry, the auth model, and the measurement loop are the product. The protocol is just the wire.
Many small servers, not one giant one — and where the crossover sits
Pinterest debated a single monolithic MCP server versus multiple domain-specific servers and chose the fleet: a Presto server for data querying, a Spark server for job debugging, an Airflow server for workflow orchestration, a Knowledge server for company Q&A, each owning a small, coherent toolset. Three concrete reasons drove the call:
- Different access controls per server. Presto tools can query sensitive business data; Knowledge tools answer documentation questions. Separate servers let each carry its own authorization policy instead of one server trying to enforce fifty different rules internally. (More on the mechanism in the auth section.)
- No context crowding. Every tool definition an agent can see rides along in its context on every call. One server exposing everything forces every session to carry every definition; scoped servers mean each session binds only the tools it may actually use.
- One owning team per server. Each server has a team that knows its domain's pain, ships its tools, and answers for its reliability — instead of a shared monolith with diffused ownership.
So when does the fleet beat the monolith? The honest answer is that below a handful of tools on one team, the monolith wins on simplicity — one deploy, one config, no registry to run. The crossover arrives with the second owning team, the second sensitivity level, or the tool count where flat definitions start eating context you would rather spend on the task. The token math makes the bands concrete:
| Avg tool-definition size | 10 tools | 25 tools | 100 tools |
|---|---|---|---|
| Small (~200 tokens: name, short description, tight schema) | ~2K tokens | ~5K tokens | ~20K tokens |
| Large (~800 tokens: rich description, big JSON schema) | ~8K tokens | ~20K tokens | ~80K tokens |
On a 200K-token context window, 100 large tool definitions consume 40% of the window before the conversation starts — and the cost is not just fit, it is per-request price and tool-selection accuracy, both of which degrade as the list grows. Pinterest's scoping keeps each session near the left column of that table no matter how big the fleet gets. If your surface is heading past roughly 15–25 tools, or needs different access rules for different tools, you have crossed over: that is the point where "just add another tool to the server" starts taxing every agent session, and per-server scoping starts paying for itself.
Pinterest also removed the main reason teams resist splitting: they built a unified deployment pipeline after early feedback that spinning up a new server cost too much yak-shaving. The paved path became "write a server, deploy it to our cloud compute environment, list it in the registry" — with infrastructure handled for the server author. A fleet architecture without a paved path is just toil distribution; the pipeline is what makes "many small servers" a strategy instead of a burden.
The registry is the governance backbone, not a phone book
The centerpiece is Pinterest's internal MCP registry: the source of truth for which servers are approved and how to connect to them. It serves two audiences — a web UI where humans discover servers, their owning teams, and support channels, and an API where clients and bots look servers up programmatically. And it carries a governance rule with teeth: only servers registered here count as approved for production.
The discovery flow is what a flat tool list cannot do. Walk through it from an agent's side: the client authenticates, queries the registry API, and gets back the approved servers for this user — with versions, connection info, and the policy scope attached. It binds only those servers' tools into the session. A Spark-debugging agent in an Airflow support channel sees Spark tools; it never loads the Presto revenue-query definitions it may not call anyway. Contrast the flat alternative: every definition for every system dumped into one session, where the model's tool selection degrades, the request costs more, and "which version of the deploy tool is this agent calling" has no authoritative answer.
Two sentences on security, because the registry earns its keep here too: every non-experimental server must be tied to an owning team, appear in the registry, and pass Security, Legal/Privacy, and GenAI review before it counts as production. That review gate is the choke point where poisoned or over-privileged tool definitions get caught — which matters more with every server added, since each new tool is a new instruction source the model will obey.
Two-layer auth built for agents, not consent screens
Letting agents call tools that touch real systems raises the auth question, and Pinterest's answer is the most directly reusable part of the whole design. Almost every MCP call is governed by two layers:
| Flow | Identity | Enforcement | Used for |
|---|---|---|---|
| End-user (JWT) | User's JWT from the internal auth stack | Envoy validates the JWT, maps it to forwarded user/group headers, enforces coarse policy (e.g. prod chat may reach the Presto server but not experimental dev-namespace servers); inside the server, an @authorize_tool decorator enforces fine-grained rules (e.g. only Ads-eng groups may call revenue metrics) | Anything a human asked for |
| Service-only (SPIFFE) | Calling service's mesh identity | Mesh policy plus server-side authorization on the service identity | Low-risk, read-only scenarios with no human in the loop |
On top of the JWT flow sits business-group gating for sensitive servers: the Presto server extracts group membership from the JWT and only admits approved groups (Ads, Finance, specific infra teams), selectively enabling higher-privilege tools by role. Some servers require a valid JWT even for tool discovery, which buys user-level attribution on every invocation — "who did what" falls out of the logs for free.
Note what Pinterest deliberately did not do: follow the MCP spec's OAuth flow of per-server consent screens and per-server token management. Their users already authenticate against the internal stack, so the registry and servers ride that identity instead of minting a consent ceremony per server. Internal platforms with an existing identity system should copy this posture: one login, registry-mediated scoping, no N-server OAuth sprawl.
And the backstop for everything above: human-in-the-loop before any sensitive or expensive action. Agents propose via MCP tools; humans approve or reject. Auth decides what an agent may call; the approval step decides what actually executes when the blast radius is real.
Measure it or it is a black box — with honest error bars
Pinterest refused to let the ecosystem become unmeasurable. Every server uses shared library functions providing input/output logging, invocation counts, and exception tracing out of the box, and those roll up into a single north-star metric: time saved. Each tool owner supplies a directional "minutes saved per invocation" estimate from user feedback and comparison with the prior manual workflow; multiplied by invocation counts, that yields the order-of-magnitude impact view — the 7,000-hours figure.
Take the headline apart before quoting it, because Pinterest itself labels the inputs directional. 7,000 hours over 66,000 invocations implies an average of about 6.4 minutes saved per call — plausible for "query the data without context-switching into a dashboard," but an average over tools that surely range from seconds to half-hours. The sensitivity table shows how much the headline moves with that assumption:
| Assumed avg minutes saved per invocation | Implied monthly hours saved |
|---|---|
| 3 min | ~3,300 hrs |
| 6.4 min (Pinterest's implied average) | ~7,000 hrs |
| 10 min | ~11,000 hrs |
Even the pessimistic row is a serious return, and that is the point of showing the range: the program clears its bar under any defensible assumption, which is exactly what "order-of-magnitude view" means. The reusable lesson is the instrumentation pattern, not the number — shared telemetry from day one, per-tool savings estimates owned by tool owners, one north-star metric. Adopt the loop; compute your own average.
What this means for a deploy/rollback/logs MCP surface
Everything above maps directly onto the MCP surface a deployment platform needs as it grows past a handful of tools. Pinterest ran Presto, Spark, Airflow, and Knowledge servers; a PaaS runs deploy, rollback, logs, and status servers. The translation is nearly one-to-one:
| Pinterest pattern | Deploy-surface translation |
|---|---|
| Domain servers (Presto / Spark / Airflow) | Split deploy, rollback, logs, and config into domain servers so each carries its own policy — rollback tools get stricter rules than log-tail tools without special-casing inside one server |
| Registry as approved-for-production source of truth | Run the registry from day one: approved server versions, owning teams, connection info in one place, so "which deploy tool did the agent call" is always answerable |
| JWT + decorator + business-group gating | End-user identity on every mutating call; coarse mesh policy plus fine-grained per-tool rules (only release-eng may call prod rollback); read-only logs over the lighter service-identity flow |
| Human-in-the-loop for sensitive actions | Agents propose deploys and rollbacks; a human approves before anything touches production — auth scopes the proposal, approval gates the execution |
| Shared telemetry + time-saved north star | Log every tool call with user attribution from the first server; track minutes saved per deploy/debug cycle so the surface justifies its own expansion |
Two sequencing notes. First, start the registry before you feel the pain: migrating a flat tool list that agents already depend on is harder than registering server number one. Second, keep the paved path paved — if adding a server means hand-rolling pipelines and config, teams will bolt tools onto the nearest existing server and you will have a monolith with extra steps. Pinterest learned that early enough to fix it with the unified pipeline; it is cheaper to build the pipeline when the fleet is small.
The fleet is the product
MCP's 48-fold download growth settled which protocol agents use to reach tools. Pinterest's 66,000 monthly invocations settle the next question: the teams getting value treat the ecosystem — registry, auth, deployment path, measurement — as the product, not the protocol client. Many small servers with one owner each, a registry that doubles as the governance gate, identity-aware auth that skips consent-screen sprawl, and a time-saved metric with honest error bars: that is a complete operating pattern, and it transfers whole to any platform whose agents touch production systems.
The gap to close is smaller than it looks. A registry, a paved deploy path, and per-tool telemetry are a week's honest work for a platform team — and every tool added after them inherits discovery, access control, and measurement for free. Build those three before your tool count crosses the crossover band, and your tenth server will be as governable as your first.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. As agents become first-class operators, the deploy surface they drive needs registry-grade discovery and access control — exactly the pattern above. Star the repo on GitHub or deploy your first app today.
