Delivered-To: tjphuhs@gmail.com Received: by 2002:a05:622a:2b4e:b0:50f:b801:ff26 with SMTP id hb14csp1895849qtb; Mon, 11 May 2026 08:43:11 -0700 (PDT) X-Received: by 2002:a05:620a:17a4:b0:8ea:aa10:7b3f with SMTP id af79cd13be357-9090dfffcecmr1480787885a.1.1778514190755; Mon, 11 May 2026 08:43:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1778514190; cv=none; d=google.com; s=arc-20240605; b=Gw2qDZiXSX+dSs9RC2MfThaijNFOCyFWWwVwNivMrmdL1lVupE87FO26dNyrGIUNvW fKcdX9jhImED7OjIUqhzN2SrKKlIzIlPKuMOpqA/jezZDqYnIeG2gYCPTWOHW6JZKGOy 3Y3ga829XTrS3oc1tGe7N2NBjJ4DtsOnBlKyPMk0QOJwRNeOfa/+OOQgcd3yD/h9xBa3 DWGa1BR6BHBFvYx8YCHbVKuC4apGYq0MvKqJ/+d5wduYFkYEZ/Wfrvy6AeI39BPv4H7e wBXcGBxnZRpakRbaW2bkHJahyH39JmSZ+SC5WjGJSftr537E9EVTZuZBRL7sybgMe8pK qsrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe-post:list-unsubscribe:list-post:list-id :list-archive:list-url:list-owner:reply-to:in-reply-to:references :sender:feedback-id:date:message-id:to:from:subject:mime-version :dkim-signature:dkim-signature; bh=SrK9E/5cftiEHqvsDnHSAqkamnRy4tz3ilPf2F8m5ew=; fh=9zP21OW67FFZD2VV42mGudo540Qp4aalMWxJB5kMYug=; b=RFiz7E4B/kt8CWrntdCs/eCeWCbd3JlgqxEK4u0cExhtbBitdgdL6sCO+5S9MWeiIB tu1pUbzDst1ar1KCLPsl0sr0y0PCZum3nTUT+nKk4UkxVjA/GrrF717ueDm4BsUcCATe Jwzbg/R/n1ZMYzY34/Bmf8zZlMqYgg/9bA9Wc8Ylwm+bicRBNSsKZdtAz9zDpzO9PvoP BWJtfOlOzZZCTeBKlVWYLSjgwzgIejpAoyte2BPggKtZ93zF6H28JNY1ilLyI1uvUUy+ BPudLLu5Eq/vrCEaFfIpaqbZNCd7zG/2Yy58ItT5CdpQCqZhBlhg3Sc+WR2+XqAx4GBJ W13w==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mg-d0.substack.com header.s=mailo header.b=mFhwI5LV; dkim=pass header.i=@mailgun.org header.s=mg header.b=WzDsfgi8; spf=pass (google.com: domain of bounce+91e48a.63af5d-tjphuhs=gmail.com@mg-d0.substack.com designates 159.112.244.43 as permitted sender) smtp.mailfrom="bounce+91e48a.63af5d-tjphuhs=gmail.com@mg-d0.substack.com"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=substack.com Return-Path: Received: from v543.v5375b7fa.use4.send.mailgun.net (v543.v5375b7fa.use4.send.mailgun.net. [159.112.244.43]) by mx.google.com with UTF8SMTPS id af79cd13be357-9067d25ec65si1376746385a.235.2026.05.11.08.43.10 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2026 08:43:10 -0700 (PDT) Received-SPF: pass (google.com: domain of bounce+91e48a.63af5d-tjphuhs=gmail.com@mg-d0.substack.com designates 159.112.244.43 as permitted sender) client-ip=159.112.244.43; Authentication-Results: mx.google.com; dkim=pass header.i=@mg-d0.substack.com header.s=mailo header.b=mFhwI5LV; dkim=pass header.i=@mailgun.org header.s=mg header.b=WzDsfgi8; spf=pass (google.com: domain of bounce+91e48a.63af5d-tjphuhs=gmail.com@mg-d0.substack.com designates 159.112.244.43 as permitted sender) smtp.mailfrom="bounce+91e48a.63af5d-tjphuhs=gmail.com@mg-d0.substack.com"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=substack.com DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg-d0.substack.com; q=dns/txt; s=mailo; t=1778514190; x=1778521390; h=List-Unsubscribe-Post: List-Unsubscribe: List-Post: List-Id: List-Archive: List-Owner: Reply-To: In-Reply-To: References: Sender: Sender: Date: Message-Id: To: To: From: From: Subject: Subject: Content-Type: Mime-Version: X-Feedback-Id; bh=SrK9E/5cftiEHqvsDnHSAqkamnRy4tz3ilPf2F8m5ew=; b=mFhwI5LVwfhuKu9HFnqMvzzWzP2Y+dFpmwe1waPl2sGklAFMxzLRvL9AEl7fJveWBKZ7WsA0ceMsdDcXHqxsRGhWgHZKUAdwbXOG7INNscu+7MwF2sF9ZS/L4N45+jmpHGa8fiI+DBTEISkif+OoVgjJIoaeP8cvjRq4uKEc4GY= DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mailgun.org; q=dns/txt; s=mg; t=1778514190; x=1778521390; h=List-Unsubscribe-Post: List-Unsubscribe: List-Post: List-Id: List-Archive: List-Owner: Reply-To: In-Reply-To: References: Sender: Sender: Date: Message-Id: To: To: From: From: Subject: Subject: Content-Type: Mime-Version: X-Feedback-Id; bh=SrK9E/5cftiEHqvsDnHSAqkamnRy4tz3ilPf2F8m5ew=; b=WzDsfgi84MUHpjUdfnvnPWVWdxKsaF4tL1Uig740YlQBtwrRMXpUlHDWHlMsl9MyaLqjfN1mQInpmo8Z89VC/YxfHdZS8/aNjy4szC17f8ZfNKEAG+FY+FZoIc8TdQYC2X3oGv/lCo7IXiPx8TvLVbHDvpP3gB38aoIUattnHCY= X-Mailgun-Sid: WyJkZWU4NyIsInRqcGh1aHNAZ21haWwuY29tIiwiNjNhZjVkIl0= X-Feedback-Id: postmaster@mg-d0.substack.com:post:6148c7d8a45790427cda307f:mailgun Received: by 507199e57faecaea2a709abd6899c911d4f6bcbbd935b46fabfc26cd28db7734 with HTTP id 6a01f90e759e38c33701ba63; Mon, 11 May 2026 15:43:10 GMT X-Mailgun-Sending-Ip: 159.112.244.43 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="2fa2c826e187cd8406eadf45e5d0a540ddf45ce63ed0ce7467f1c130a6ae" Subject: How Pinterest Built a Production MCP Ecosystem From: ByteByteGo To: tjphuhs@gmail.com X-Mailgun-Tag: post X-Mailgun-Track-Clicks: false Message-Id: <20260511153117.3.80c4bb1e2aec6be1@mg-d0.substack.com> Date: Mon, 11 May 2026 15:31:17 +0000 Feedback-Id: post-196933670:cat-post:pub-817132:substack Sender: ByteByteGo References: In-Reply-To: Reply-To: ByteByteGo List-Owner: List-Url: List-Archive: List-Id: List-Post: List-Unsubscribe: List-Unsubscribe-Post: List-Unsubscribe=One-Click X-Mailgun-Variables: {"category": "post", "email_generated_at": "1778514190487", "is_freemail": "true", "post_audience": "everyone", "post_id": "196933670", "post_type": "newsletter", "pub_community_enabled": "true", "publication_id": "817132", "subdomain": "bytebytego", "user_id": "273622398"} --2fa2c826e187cd8406eadf45e5d0a540ddf45ce63ed0ce7467f1c130a6ae Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable View this post on the web at https://blog.bytebytego.com/p/how-pinterest-bu= ilt-a-production Agents need context. Ship the integrations that give it to them. (Sponsored= ) [ https://substack.com/redirect/87dc365a-cf87-4640-8889-81a07e071928?j=3D= eyJ1IjoiNGl3b2U2In0.sVDxRtmZ85v8kfdamY0krRXGMy3p768BWtuZifRB-Zs ] The context that actually matters isn't in your database. It's in the tools= your users live in every day. Multi-stage agents stall the moment they hit= a step they can't see. And every missing integration is a different OAuth = flow, a different token lifecycle, weeks of plumbing before the agent reads= a single record. WorkOS Pipes [ https://substack.com/redirect/5919ff9f-bb8d-4af3-9e59-697f2c= 6d3026?j=3DeyJ1IjoiNGl3b2U2In0.sVDxRtmZ85v8kfdamY0krRXGMy3p768BWtuZifRB-Zs = ] connects your agent to the tools your users live in. Pre-built connectors= for GitHub, Slack, Salesforce, Google Drive, and more. Pipes handles OAuth= , token refresh, and credential storage. You call the real provider API wit= h a fresh token, every time. Your agent pulls context at every step, for as= long as the task runs. Engineers at Pinterest work across a sprawling set of internal systems ever= y day. They query data through Presto, debug batch jobs in Spark, manage wo= rkflows in Airflow, search internal documentation, and track bugs in ticket= ing platforms. When Pinterest started building AI agents, they wanted those agents to do m= ore than answer questions. They wanted agents that could reach into these s= ystems directly, pulling logs, investigating bug tickets, querying database= s, and proposing fixes, all within the surfaces engineers already use. The challenge was driven by standard maths. If you have five AI-powered sur= faces (an internal chat app, IDE plugins, chatbots, CLI agents, and other a= utonomous agents) and ten internal tools, you=E2=80=99d need fifty bespoke = integrations without a shared protocol. In other words, every new surface o= r tool multiplies the work. The Model Context Protocol (MCP) promised to collapse that multiplication i= nto addition. Build one MCP client per surface and one MCP server per tool,= and they all speak the same language. Pinterest adopted MCP as the foundation for this vision. However, implement= ing the protocol turned out to be the easy part. The real engineering effor= t went into everything around it, such as a central registry, a two-layer a= uth system, a unified deployment pipeline, and observability baked in from = day one. In this article, we look at how Pinterest designed that ecosystem and what = they had to get right beyond the protocol itself. Disclaimer: This post is based on publicly shared details from the Pinteres= t Engineering Team. Please comment if you notice any inaccuracies. What is MCP Model Context Protocol (MCP) is an open-source standard that gives large la= nguage models a unified way to talk to external tools and data sources. Instead of writing custom glue code between every AI application and every = tool it needs to access, MCP defines a shared client-server protocol. An AI= surface acts as the client, an MCP server wraps a tool or data source, and= they communicate using a standardized format for discovering tools, invoki= ng them, and returning structured results. Before MCP, connecting AI surfaces to internal tools was an N x M problem. = Five surfaces times ten tools equals fifty custom integrations to build and= maintain. MCP turns that into an N+M problem. You build five clients and t= en servers, and any client can talk to any server. That is fifteen pieces o= f work instead of fifty, and the gap widens as you add more surfaces or too= ls. But MCP only defines the communication protocol. It does not handle authent= ication, authorization, deployment, service discovery, or governance. Those are the problems Pinterest had to solve on its own. In other words, t= he MCP spec provides the grammar, and Pinterest had to build the entire sch= ool system around it. Pinterest=E2=80=99s Three Architectural Bets When Pinterest decided to adopt MCP, three early decisions shaped the entir= e ecosystem. Each involved a genuine tradeoff, and understanding those trad= eoffs helps us make sense of why the architecture looks the way it does. See the diagram below that shows the overall architecture: Bet 1: Cloud-hosted servers, not local ones. MCP supports local servers that run on a developer=E2=80=99s laptop and com= municate over standard input/output. Many individual developers use MCP thi= s way with tools like Claude or Cursor. Pinterest went the opposite direction. They explicitly optimized for internal cloud-hosted MCP servers, where thei= r routing and security infrastructure could be applied consistently. Local = servers are still allowed for experimentation, but the so-called paved path= at Pinterest is to write a server, deploy it to their cloud compute enviro= nment, and register it in their central catalog. Every tool call becomes a = network request, which adds latency compared to a local server. However, centralizing servers in the cloud meant that Pinterest could apply= consistent authentication, authorization, logging, and monitoring across e= very server without relying on individual developers to configure those thi= ngs correctly on their own machines. Bet 2: Many small servers, not one giant one Pinterest debated building a single monolithic MCP server that exposed ever= y tool versus building multiple domain-specific servers. They chose the lat= ter. For example, the Presto MCP server handles data queries. The Spark MCP serv= er handles job debugging. The Knowledge MCP server handles documentation an= d institutional Q&A. Each server owns a small, coherent set of tools. Two forces drove this decision. First, different servers need different access controls. The Presto server = touches sensitive business data and requires strict group-based gating. A d= ocumentation server is lower risk and can be more broadly accessible. Bundl= ing them into one server would force a single access policy across tools wi= th very different sensitivity levels. Second, every tool description consumes tokens in the AI model=E2=80=99s co= ntext window, which is the limited amount of text the model can process in = a single interaction. A monolithic server with fifty tools would stuff the = model=E2=80=99s prompt with tool descriptions it does not need for the curr= ent task, crowding out space for the actual conversation. Domain-specific servers keep the tool list small and relevant. This context= window constraint is uniquely AI-specific because in a traditional microse= rvices setup, you would not worry about your service catalog consuming toke= ns. The tradeoff here is more operational overhead per server, since each one n= eeds deployment, monitoring, and ownership. This cost led directly to the t= hird bet. Bet 3: A unified deployment pipeline Early feedback from teams was clear. Spinning up a new MCP server required = too much boilerplate, including deployment pipelines, service configuration= , and operational setup, all before anyone could write a single line of bus= iness logic. The Pinterest engineering team responded by building a unified deployment p= ipeline. Teams define their tools, and the platform handles deployment, sca= ling, and infrastructure. This turned what had been a multi-day setup proce= ss into something where domain experts could focus entirely on their busine= ss logic. Without this investment, the bet around many small servers would = have collapsed under its own operational weight. Sitting beneath all of this is the MCP registry, a central catalog that ser= ves as the source of truth for which servers exist, who owns them, and how = to connect to them. It has two faces. A web UI lets humans browse available servers, see their live status, find = the owning team and support channels, and inspect visible tools. An API lets AI clients programmatically discover servers, validate them, an= d check whether a given user is authorized to access a given server. Only servers registered here count as approved for production use. In other= words, the registry is not just a phone book, but the governance backbone = of the entire ecosystem. Two Layers of Auth Giving AI agents access to tools that touch real production systems and sen= sitive data raises immediate security concerns. Pinterest treated MCP as a joint project with their security team from day = one, and the result is a two-layer authorization model that deserves carefu= l attention. See the diagram below: Consider what happens when an engineer opens Pinterest=E2=80=99s internal A= I chat and asks the agent to query revenue data from the data warehouse. Th= at single request crosses multiple systems as mentioned below: The chat frontend talks to the MCP registry to find available servers. The request gets routed to the Presto MCP server, which runs a query agains= t a real database containing business-sensitive information. At every hop, the system needs to answer two questions. Who is this person?= And are they allowed to do this specific thing? Layer 1 handles coarse-grained checks at the network edge. When an engineer opens any AI surface at Pinterest, they go through an OAut= h flow, which is the standard process for logging in with a company account= and granting the application permission to act on the user=E2=80=99s behal= f. This produces a JWT (JSON Web Token), a small signed token that encodes = the user=E2=80=99s identity and group memberships. That JWT travels with ev= ery subsequent request. Before a request reaches any MCP server, it passes through Envoy, a network= proxy that sits in front of every service in Pinterest=E2=80=99s infrastru= cture. Envoy validates the JWT by checking the signature and expiration, th= en converts it into standard headers like X-Forwarded-User and X-Forwarded-= Groups. Envoy also enforces coarse-grained access policies. These are broad rules l= ike =E2=80=9Cthe production AI chat application may talk to the Presto MCP = server, but experimental servers running in the dev namespace are off-limit= s.=E2=80=9D If the request violates these rules, it gets rejected before th= e MCP server ever sees it. Think of Envoy as the building security desk. It= checks your badge and makes sure you are supposed to be in the building at= all. Layer 2 handles fine-grained checks inside each server. Even if Envoy lets a request through, the MCP server applies a second layer= of authorization at the individual tool level. Pinterest uses a decorator = pattern on tool functions (@authorize_tool(policy=3D=E2=80=99...=E2=80=99))= that checks whether the specific user is allowed to invoke that specific t= ool. For example, the Presto MCP server might be reachable by many teams, but on= ly the Ads engineering group can call a tool like get_revenue_metrics. This= is like the difference between being allowed into the building and being a= llowed into a specific room. For servers that handle particularly sensitive data, Pinterest adds busines= s-group gating. The server extracts the user=E2=80=99s business group membe= rship from their JWT and checks it against an approved list before even est= ablishing a session. This list of approved groups is set during the initial= security review when the server is first registered. For example, even though the Presto MCP server is technically reachable fro= m Pinterest=E2=80=99s broadly used AI chat interface, only specific groups = like Ads, Finance, or certain infrastructure teams can actually connect and= run queries. This means that turning on a powerful, data-heavy server in a= popular surface does not silently expand who can see sensitive data. Why two layers instead of one? Envoy=E2=80=99s policies are fast, network-level checks that block obviousl= y unauthorized traffic before it reaches any application code. The tool-lev= el decorators handle nuanced, business-logic-specific permissions that a ne= twork proxy is not equipped to reason about. Together, they provide defense= in depth. Even if one layer has a misconfiguration, the other still catche= s unauthorized access. The official MCP specification defines an OAuth 2.0 authorization flow wher= e users authenticate with each MCP server individually, typically involving= consent screens and per-server token management. Pinterest skipped this en= tirely. Since they control the entire internal environment, they piggyback = on the auth session the user already has when they open an AI surface. Ther= e is no additional login prompt or consent dialog when a user invokes an MC= P tool. This is simpler for end users, but only works because Pinterest owns every = piece of the stack. A company relying on third-party MCP servers would like= ly need the per-server OAuth approach described in the spec. Lastly, for automated service-to-service calls where there is no human in t= he loop, Pinterest uses SPIFFE-based authentication. In this pattern, the c= alling service proves its identity through a cryptographic certificate issu= ed by the service mesh rather than presenting a human=E2=80=99s JWT. Pinter= est reserves this for low-risk, read-only scenarios where the blast radius = is tightly constrained. Meeting Engineers Where They Already Work Pinterest was deliberate about one thing. MCP could not be a science projec= t that lived in its own separate interface. It had to show up in the tools = that engineers already use every day. The diagram below shows how the MCP integration has been done across variou= s surfaces at Pinterest. Pinterest=E2=80=99s internal AI chat interface is used by the majority of e= mployees daily. The frontend automatically handles OAuth flows and returns = a list of usable MCP tools scoped to the current user=E2=80=99s permissions= =2E Once connected, the AI agent binds=20= MCP tools directly into its toolset, s= o invoking an MCP tool feels identical to calling any other built-in capabi= lity. From the user=E2=80=99s perspective, they are just asking the AI to d= o something, and the MCP plumbing is invisible. Pinterest also embeds AI bots in its internal communication platform, and t= hese bots expose MCP tools as well. Auth is handled through the registry AP= I, just like the web interface. These bots support context-aware tool scopi= ng, meaning certain MCP tools are restricted to certain channels. Spark MCP= tools, for example, only appear in Airflow support channels. This keeps to= ol lists relevant to the conversation and prevents users from accidentally = invoking tools that do not make sense in a given context. AI-enabled IDEs can pull data through the Presto MCP server on demand, so a= gents bring data directly into coding workflows instead of requiring engine= ers to switch to a separate dashboard. CLI agents provide similar capabilit= ies for terminal-based workflows. The servers that see the heaviest usage reflect the most common engineering= pain points. The Presto MCP server is consistently the highest-traffic server because da= ta access is a universal need across teams. The Spark MCP server underpins Pinterest=E2=80=99s AI-assisted debugging ex= perience, where agents diagnose job failures, summarize logs, and help reco= rd structured root-cause analyses, turning noisy operational threads into r= eusable knowledge. The Knowledge MCP server acts as a general-purpose endpoint for institution= al knowledge, giving agents the ability to search documentation and answer = questions across internal sources. Since MCP servers enable automated actions, the blast radius of a mistake i= s larger than if a human manually performed the same steps. Pinterest=E2=80=99s agent guidance mandates human-in-the-loop approval befo= re any sensitive or expensive action. Agents propose actions, humans approv= e or reject (optionally in batches) before execution. Pinterest also uses e= licitation for dangerous operations, where the AI explicitly asks the user = to confirm before performing something like overwriting data in a table. Th= is is a governance decision. Measurements Pinterest built observability into the MCP ecosystem from the start rather = than treating it as an afterthought. All MCP servers use a set of shared li= brary functions that provide logging for inputs and outputs, invocation cou= nts, exception tracing, and other telemetry out of the box. This is part of= the server framework itself, so teams get observability for free when they= use the unified deployment pipeline. At the ecosystem level, Pinterest tracks the number of registered servers a= nd tools, invocation counts across all servers, and a north-star metric tha= t rolls everything up into a single number. That number is the time saved. = For each tool, server owners provide a =E2=80=9Cminutes saved per invocatio= n=E2=80=9D estimate, based on lightweight user feedback and comparison to t= he prior manual workflow. Multiplied by invocation counts, this gives an or= der-of-magnitude view of impact. As of January 2025, MCP servers at Pinterest were handling 66,000 invocatio= ns per month across 844 monthly active users. Using the owner-provided esti= mates, MCP tools were saving on the order of approximately 7,000 hours per = month. Conclusion Pinterest=E2=80=99s MCP ecosystem offers a clear blueprint for organization= s building AI agents that need to act on internal systems. The pattern they= established, a standard protocol, a central registry, layered auth, a unif= ied deployment pipeline, and built-in observability, is transferable well b= eyond Pinterest=E2=80=99s specific context. The most important lesson is where the effort actually went. The MCP protoc= ol gave Pinterest a shared language between AI surfaces and tools. That was= necessary but far from sufficient. The registry, auth layers, deployment p= ipeline, and measurement framework are what turned a promising protocol int= o a production system handling tens of thousands of invocations per month. To conclude, Pinterest=E2=80=99s approach suggests a practical starting poi= nt of seeding a small set of high-leverage MCP servers that solve real pain= points, then invest in the platform work, especially the deployment pipeli= ne, that makes it easy for other teams to build on top. Pinterest=E2=80=99s= unified pipeline was the unlock that turned a platform team project into a= n org-wide ecosystem. References: Building an MCP Ecosystem at Pinterest [ https://substack.com/redirect/e46a= 8d27-0b00-4caf-b9ea-4773ca672cfc?j=3DeyJ1IjoiNGl3b2U2In0.sVDxRtmZ85v8kfdamY= 0krRXGMy3p768BWtuZifRB-Zs ] Introducing the Model Context Protocol [ https://substack.com/redirect/b910= 3e86-78bb-4524-bf65-6aa0cba6565c?j=3DeyJ1IjoiNGl3b2U2In0.sVDxRtmZ85v8kfdamY= 0krRXGMy3p768BWtuZifRB-Zs ] Unsubscribe https://substack.com/redirect/2/eyJlIjoiaHR0cHM6Ly9ibG9nLmJ5dGV= ieXRlZ28uY29tL2FjdGlvbi9kaXNhYmxlX2VtYWlsP3Rva2VuPWV5SjFjMlZ5WDJsa0lqb3lOek= 0yTWpJek9UZ3NJbkJ2YzNSZmFXUWlPakU1Tmprek16WTNNQ3dpYVdGMElqb3hOemM0TlRFME1Ua= 3dMQ0psZUhBaU9qRTRNVEF3TlRBeE9UQXNJbWx6Y3lJNkluQjFZaTA0TVRjeE16SWlMQ0p6ZFdJ= aU9pSmthWE5oWW14bFgyVnRZV2xzSW4wLjVGcTBWUW1WSGJwbmxVOWhFQkhwX2xqbno2blJ6djc= zU1N2S3M3cGp3OEUiLCJwIjoxOTY5MzM2NzAsInMiOjgxNzEzMiwiZiI6dHJ1ZSwidSI6MjczNj= IyMzk4LCJpYXQiOjE3Nzg1MTQxOTAsImV4cCI6MjA5NDA5MDE5MCwiaXNzIjoicHViLTAiLCJzd= WIiOiJsaW5rLXJlZGlyZWN0In0.22vKqP1CqIoxnNlh92EuhM03JMsqTc9Qo-QlHWveOps? --2fa2c826e187cd8406eadf45e5d0a540ddf45ce63ed0ce7467f1c130a6ae Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable = How Pinterest Built a Production MCP Ecosystem=3D""
In this article, we look at how Pinterest desi= gned that ecosystem and what they had to get right beyond the protocol itse= lf.
͏     ­͏     ­͏   =   ­͏     ­͏     ­͏= ;     ­͏     ­͏     &#= 173;͏     ­͏     ­͏   &= #8199; ­͏     ­͏     ­͏=     ­͏     ­͏     = 73;͏     ­͏     ­͏   &#= 8199; ­͏     ­͏     ­͏ =     ­͏     ­͏     = 3;͏     ­͏     ­͏   = 199; ­͏     ­͏     ­͏ &= nbsp;   ­͏     ­͏     ­= ;͏     ­͏     ­͏   Q= 99; ­͏     ­͏     ­͏ &n= bsp;   ­͏     ­͏     ­= ͏     ­͏     ­͏   ̳= 9; ­͏     ­͏     ­͏ &nb= sp;   ­͏     ­͏     ­&= #847;     ­͏     ­͏    = ; ­͏     ­͏     ­͏ &nbs= p;   ­͏     ­͏     ­&#= 847;     ­͏     ­͏    = ­͏     ­͏     ­͏  = ;   ­͏     ­͏     ­= 47;     ­͏     ­͏     = ­͏     ­͏     ­͏  =   ­͏     ­͏     ­T= 7;     ­͏     ­͏     &= #173;͏     ­͏     ­͏   =   ­͏     ­͏     ­͏= ;     ­͏     ­͏     &#= 173;͏     ­͏     ­͏   &= #8199; ­͏     ­͏     ­͏=     ­͏     ­͏     = 73;͏     ­͏     ­͏   &#= 8199; ­͏     ­͏     ­͏ =     ­͏     ­͏     = 3;͏     ­͏     ­͏   = 199; ­͏     ­͏     ­͏ &= nbsp;   ­͏     ­͏     ­= ;͏     ­͏     ­͏   Q= 99; ­͏     ­͏     ­͏ &n= bsp;   ­͏     ­͏     ­= ͏     ­͏     ­͏   ̳= 9; ­͏     ­͏     ­͏ &nb= sp;   ­͏     ­͏     ­&= #847;     ­͏     ­͏    = ; ­͏     ­͏     ­͏ &nbs= p;   ­͏     ­͏     ­&#= 847;     ­͏     ­͏    = ­͏     ­͏     ­͏  = ;   ­͏     ­͏     ­= 47;     ­͏     ­͏     = ­͏     ­͏     ­͏  =   ­͏     ­͏     ­T= 7;     ­͏     ­͏     &= #173;͏     ­͏     ­͏   =   ­͏     ­͏     ­͏= ;     ­͏     ­͏     &#= 173;͏     ­͏     ­͏   &= #8199; ­͏     ­͏     ­͏=     ­͏     ­͏     = 73;͏     ­͏     ­͏   &#= 8199; ­͏     ­͏     ­͏ =     ­͏     ­͏     = 3;͏     ­͏     ­͏   = 199; ­͏     ­͏     ­͏ &= nbsp;   ­͏     ­͏     ­= ;͏     ­͏     ­͏   Q= 99; ­͏     ­͏     ­͏ &n= bsp;   ­͏     ­͏     ­= ͏     ­͏     ­͏   ̳= 9; ­͏     ­͏     ­͏ &nb= sp;   ­͏     ­͏     ­&= #847;     ­͏     ­
<= /tbody>
Forwarded this email? Subscribe= here for more

How Pinterest Built a Production MCP Ecosystem<= /h1>
<= table role=3D"presentation" width=3D"auto" border=3D"0" cellspacing=3D"0" c= ellpadding=3D"0">
ByteByteGo
=
=
 
=
<= img class=3D"icon" src=3D"https://substackcdn.com/image/fetch/$s_!_L14!,w_3= 6,c_scale,f_png,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack.com= %2Ficon%2FLucideShare2%3Fv%3D4%26height%3D36%26fill%3Dnone%26stroke%3D%2523= 808080%26strokeWidth%3D2" width=3D"18" height=3D"18" style=3D"border: none;= vertical-align: middle;max-width: 18px" alt=3D"">
3D""
READ IN APP=3D""
 

Agents need context. Ship the integrations that give it to them.= (Sponsored)

3D""

The contex= t that actually matters isn't in your database. It's in the tools your user= s live in every day. Multi-stage agents stall the moment they hit a step th= ey can't see. And every missing integration is a different OAuth flow, a di= fferent token lifecycle, weeks of plumbing before the agent reads a single = record.

WorkOS P= ipes connects your agent to the tools your users live in. Pre-bui= lt connectors for GitHub, Slack, Salesforce, Google Drive, and more. Pipes = handles OAuth, token refresh, and credential storage. You call the real pro= vider API with a fresh token, every time. Your agent pulls context at every= step, for as long as the task runs.

Give your agent con= text →

Engineers at Pinte= rest work across a sprawling set of internal systems every day. They query = data through Presto, debug batch jobs in Spark, manage workflows in Airflow= , search internal documentation, and track bugs in ticketing platforms.

=

When Pinterest started building AI agents, = they wanted those agents to do more than answer questions. They wanted agen= ts that could reach into these systems directly, pulling logs, investigatin= g bug tickets, querying databases, and proposing fixes, all within the surf= aces engineers already use.

The challeng= e was driven by standard maths. If you have five AI-powered surfaces (an in= ternal chat app, IDE plugins, chatbots, CLI agents, and other autonomous ag= ents) and ten internal tools, you’d need fifty bespoke integrations w= ithout a shared protocol. In other words, every new surface or tool multipl= ies the work.

The Model Context Protocol= (MCP) promised to collapse that multiplication into addition. Build one MC= P client per surface and one MCP server per tool, and they all speak the sa= me language.

Pinterest adopted MCP as th= e foundation for this vision. However, implementing the protocol turned out= to be the easy part. The real engineering effort went into everything arou= nd it, such as a central registry, a two-layer auth system, a unified deplo= yment pipeline, and observability baked in from day one.

In this article, we look at how Pinterest designed that ec= osystem and what they had to get right beyond the protocol itself.

Disclaimer: This post is based on publicly s= hared details from the Pinterest Engineering Team. Please comment if you no= tice any inaccuracies.

= What is MCP

Model Context Protocol (MCP= ) is an open-source standard that gives large language models a unified way= to talk to external tools and data sources.

3D""<= /td>

Instead of writing custom glue code bet= ween every AI application and every tool it needs to access, MCP defines a = shared client-server protocol. An AI surface acts as the client, an MCP ser= ver wraps a tool or data source, and they communicate using a standardized = format for discovering tools, invoking them, and returning structured resul= ts.

<= /td>

Bef= ore MCP, connecting AI surfaces to internal tools was an N x M problem. Fiv= e surfaces times ten tools equals fifty custom integrations to build and ma= intain. MCP turns that into an N+M problem. You build five clients and ten = servers, and any client can talk to any server. That is fifteen pieces of w= ork instead of fifty, and the gap widens as you add more surfaces or tools.=

= 3D"=

But MCP o= nly defines the communication protocol. It does not handle authentication, = authorization, deployment, service discovery, or governance.

Those are the problems Pinterest had to solve on its o= wn. In other words, the MCP spec provides the grammar, and Pinterest had to= build the entire school system around it.

Pinterest’s Three Architectural Bets

When Pinterest decided to adopt MCP, three early decisio= ns shaped the entire ecosystem. Each involved a genuine tradeoff, and under= standing those tradeoffs helps us make sense of why the architecture looks = the way it does.

See the diagram below t= hat shows the overall architecture:

=
3D""

Bet 1: Cloud-hosted servers, not lo= cal ones.

MCP supports local servers th= at run on a developer’s laptop and communicate over standard input/ou= tput. Many individual developers use MCP this way with tools like Claude or= Cursor.

Pinterest went the opposite dir= ection.

They explicitly optimized for in= ternal cloud-hosted MCP servers, where their routing and security infrastru= cture could be applied consistently. Local servers are still allowed for ex= perimentation, but the so-called paved path at Pinterest is to write a serv= er, deploy it to their cloud compute environment, and register it in their = central catalog. Every tool call becomes a network request, which adds late= ncy compared to a local server.

However,= centralizing servers in the cloud meant that Pinterest could apply consist= ent authentication, authorization, logging, and monitoring across every ser= ver without relying on individual developers to configure those things corr= ectly on their own machines.

Bet 2: Many small servers, not one giant one

Pinterest debated building a single monolithic MCP server that expos= ed every tool versus building multiple domain-specific servers. They chose = the latter.

For example, the Presto MCP = server handles data queries. The Spark MCP server handles job debugging. Th= e Knowledge MCP server handles documentation and institutional Q&A. Eac= h server owns a small, coherent set of tools.

Two forces drove this decision.

  • = First, different servers need different access controls. The Presto server = touches sensitive business data and requires strict group-based gating. A d= ocumentation server is lower risk and can be more broadly accessible. Bundl= ing them into one server would force a single access policy across tools wi= th very different sensitivity levels.

  • Second, every tool description cons= umes tokens in the AI model’s context window, which is the limited am= ount of text the model can process in a single interaction. A monolithic se= rver with fifty tools would stuff the model’s prompt with tool descri= ptions it does not need for the current task, crowding out space for the ac= tual conversation.

Domain-spec= ific servers keep the tool list small and relevant. This context window con= straint is uniquely AI-specific because in a traditional microservices setu= p, you would not worry about your service catalog consuming tokens.

The tradeoff here is more operational overhead = per server, since each one needs deployment, monitoring, and ownership. Thi= s cost led directly to the third bet.

Bet 3: A unified deployment pipeline

Early feedback from teams was clear. Spinning up a new MCP server r= equired too much boilerplate, including deployment pipelines, service confi= guration, and operational setup, all before anyone could write a single lin= e of business logic.

The Pinterest engin= eering team responded by building a unified deployment pipeline. Teams defi= ne their tools, and the platform handles deployment, scaling, and infrastru= cture. This turned what had been a multi-day setup process into something w= here domain experts could focus entirely on their business logic. Without t= his investment, the bet around many small servers would have collapsed unde= r its own operational weight.

Sitting be= neath all of this is the MCP registry, a central catalog that serves as the= source of truth for which servers exist, who owns them, and how to connect= to them. It has two faces.

  • A web UI l= ets humans browse available servers, see their live status, find the owning= team and support channels, and inspect visible tools.

  • An API lets AI cli= ents programmatically discover servers, validate them, and check whether a = given user is authorized to access a given server.

Only servers registered here count as approved for pro= duction use. In other words, the registry is not just a phone book, but the= governance backbone of the entire ecosystem.

Two Layers of Auth

Gi= ving AI agents access to tools that touch real production systems and sensi= tive data raises immediate security concerns.

Pinterest treated MCP as a joint project with their security team fro= m day one, and the result is a two-layer authorization model that deserves = careful attention.

See the diagram below= :

=
3D=

Conside= r what happens when an engineer opens Pinterest’s internal AI chat an= d asks the agent to query revenue data from the data warehouse. That single= request crosses multiple systems as mentioned below:

  • The chat frontend talks to the MCP registry to find availab= le servers.

  • The request gets routed to the Presto MCP server, which runs = a query against a real database containing business-sensitive information.<= /p>

  • Layer 1 handles coarse-grained checks at the network e= dge.

    When an engineer opens any AI surfa= ce at Pinterest, they go through an OAuth flow, which is the standard proce= ss for logging in with a company account and granting the application permi= ssion to act on the user’s behalf. This produces a JWT (JSON Web Toke= n), a small signed token that encodes the user’s identity and group m= emberships. That JWT travels with every subsequent request.

    <= td class=3D"content" align=3D"left" width=3D"1456" style=3D"text-align: cen= ter;">3D""

    Before a request reach= es any MCP server, it passes through Envoy, a network proxy that sits in fr= ont of every service in Pinterest’s infrastructure. Envoy validates t= he JWT by checking the signature and expiration, then converts it into stan= dard headers like X-Forwarded-User and X-Forwarded-Groups.

    Envoy also enforces coarse-grained access policies. Thes= e are broad rules like “the production AI chat application may talk t= o the Presto MCP server, but experimental servers running in the dev namesp= ace are off-limits.” If the request violates these rules, it gets rej= ected before the MCP server ever sees it. Think of Envoy as the building se= curity desk. It checks your badge and makes sure you are supposed to be in = the building at all.

    Layer 2 handles fin= e-grained checks inside each server.

    Eve= n if Envoy lets a request through, the MCP server applies a second layer of= authorization at the individual tool level. Pinterest uses a decorator pat= tern on tool functions (@authorize_tool(policy=3D’...’)) that c= hecks whether the specific user is allowed to invoke that specific tool.

    For example, the Presto MCP server might b= e reachable by many teams, but only the Ads engineering group can call a to= ol like get_revenue_metrics. This is like the difference between being allo= wed into the building and being allowed into a specific room.

    For servers that handle particularly sensitive data= , Pinterest adds business-group gating. The server extracts the user’= s business group membership from their JWT and checks it against an approve= d list before even establishing a session. This list of approved groups is = set during the initial security review when the server is first registered.=

    For example, even though the Presto MCP= server is technically reachable from Pinterest’s broadly used AI cha= t interface, only specific groups like Ads, Finance, or certain infrastruct= ure teams can actually connect and run queries. This means that turning on = a powerful, data-heavy server in a popular surface does not silently expand= who can see sensitive data.

    Why two lay= ers instead of one?

    Envoy’s polici= es are fast, network-level checks that block obviously unauthorized traffic= before it reaches any application code. The tool-level decorators handle n= uanced, business-logic-specific permissions that a network proxy is not equ= ipped to reason about. Together, they provide defense in depth. Even if one= layer has a misconfiguration, the other still catches unauthorized access.=

    The official MCP specification defines = an OAuth 2.0 authorization flow where users authenticate with each MCP serv= er individually, typically involving consent screens and per-server token m= anagement. Pinterest skipped this entirely. Since they control the entire i= nternal environment, they piggyback on the auth session the user already ha= s when they open an AI surface. There is no additional login prompt or cons= ent dialog when a user invokes an MCP tool.

    This is simpler for end users, but only works because Pinterest owns ev= ery piece of the stack. A company relying on third-party MCP servers would = likely need the per-server OAuth approach described in the spec.

    Lastly, for automated service-to-service calls whe= re there is no human in the loop, Pinterest uses SPIFFE-based authenticatio= n. In this pattern, the calling service proves its identity through a crypt= ographic certificate issued by the service mesh rather than presenting a hu= man’s JWT. Pinterest reserves this for low-risk, read-only scenarios = where the blast radius is tightly constrained.

    Meeting Engineers Where They Already Work

    Pinterest was deliberate about one thing. MCP could= not be a science project that lived in its own separate interface. It had = to show up in the tools that engineers already use every day.

    The diagram below shows how the MCP integration has= been done across various surfaces at Pinterest.

    3D""<= /a>
    Source: Pinterest Engineering Blog

    Pinterest’s internal AI chat interface is used by the= majority of employees daily. The frontend automatically handles OAuth flow= s and returns a list of usable MCP tools scoped to the current user’s= permissions. Once connected, the AI agent binds MCP tools directly into it= s toolset, so invoking an MCP tool feels identical to calling any other bui= lt-in capability. From the user’s perspective, they are just asking t= he AI to do something, and the MCP plumbing is invisible.

    Pinterest also embeds AI bots in its internal communicati= on platform, and these bots expose MCP tools as well. Auth is handled throu= gh the registry API, just like the web interface. These bots support contex= t-aware tool scoping, meaning certain MCP tools are restricted to certain c= hannels. Spark MCP tools, for example, only appear in Airflow support chann= els. This keeps tool lists relevant to the conversation and prevents users = from accidentally invoking tools that do not make sense in a given context.=

    AI-enabled IDEs can pull data through t= he Presto MCP server on demand, so agents bring data directly into coding w= orkflows instead of requiring engineers to switch to a separate dashboard. = CLI agents provide similar capabilities for terminal-based workflows.

    The servers that see the heaviest usage refle= ct the most common engineering pain points.

    • =

      The Presto MCP server is consistently the highest-traffic server beca= use data access is a universal need across teams.

    • The Spark MCP server un= derpins Pinterest’s AI-assisted debugging experience, where agents di= agnose job failures, summarize logs, and help record structured root-cause = analyses, turning noisy operational threads into reusable knowledge.

    • Th= e Knowledge MCP server acts as a general-purpose endpoint for institutional= knowledge, giving agents the ability to search documentation and answer qu= estions across internal sources.

    Since MCP servers enable automated actions, the blast radius of a mistak= e is larger than if a human manually performed the same steps.

    Pinterest’s agent guidance mandates human-in-= the-loop approval before any sensitive or expensive action. Agents propose = actions, humans approve or reject (optionally in batches) before execution.= Pinterest also uses elicitation for dangerous operations, where the AI exp= licitly asks the user to confirm before performing something like overwriti= ng data in a table. This is a governance decision.

    Measurements

    Pin= terest built observability into the MCP ecosystem from the start rather tha= n treating it as an afterthought. All MCP servers use a set of shared libra= ry functions that provide logging for inputs and outputs, invocation counts= , exception tracing, and other telemetry out of the box. This is part of th= e server framework itself, so teams get observability for free when they us= e the unified deployment pipeline.

    At th= e ecosystem level, Pinterest tracks the number of registered servers and to= ols, invocation counts across all servers, and a north-star metric that rol= ls everything up into a single number. That number is the time saved. For e= ach tool, server owners provide a “minutes saved per invocation”= ; estimate, based on lightweight user feedback and comparison to the prior = manual workflow. Multiplied by invocation counts, this gives an order-of-ma= gnitude view of impact.

    As of January 20= 25, MCP servers at Pinterest were handling 66,000 invocations per month acr= oss 844 monthly active users. Using the owner-provided estimates, MCP tools= were saving on the order of approximately 7,000 hours per month.

    Conclusion

    Pinterest’s MCP ecosystem offers a clear blueprint for orga= nizations building AI agents that need to act on internal systems. The patt= ern they established, a standard protocol, a central registry, layered auth= , a unified deployment pipeline, and built-in observability, is transferabl= e well beyond Pinterest’s specific context.

    The most important lesson is where the effort actually went. The = MCP protocol gave Pinterest a shared language between AI surfaces and tools= =2E That was necessary but far from suf= ficient. The registry, auth layers, de= ployment pipeline, and measurement framework are what turned a promising pr= otocol into a production system handling tens of thousands of invocations p= er month.

    To conclude, Pinterest’s= approach suggests a practical starting point of seeding a small set of hig= h-leverage MCP servers that solve real pain points, then invest in the plat= form work, especially the deployment pipeline, that makes it easy for other= teams to build on top. Pinterest’s unified pipeline was the unlock t= hat turned a platform team project into an org-wide ecosystem.

    References:

=
 
3D""Share
<= /td>
 
 
=
<= tr>
3D""Like
3D""Comment
=
3D=Restack
 

© 2026 ByteByteGo548 Market Street PMB 72296, San Francisco, CA 94104
Unsubscribe

3D"Start

<= /td>=3D""3D"" --2fa2c826e187cd8406eadf45e5d0a540ddf45ce63ed0ce7467f1c130a6ae--