MCP in Production: What Block, Uber, Sierra and Atlassian Say Broke

Uber says it hosts more than 800 Model Context Protocol servers and over 5,000 tools behind one gateway. Block says it has built more than 60. Those are the two largest MCP in production figures any company has published about its own estate. The documents behind them agree on something the protocol itself does not decide: the hard part is governance, not connection.

What counts as MCP in production evidence here

Model Context Protocol is the open standard that lets an AI client call tools and read data from an external server through one interface. The protocol mechanics are covered in the explainer on how MCP became the agent interoperability standard. This post is about something narrower: what companies running it at scale have written down about doing so.

The inclusion rule is strict. A practice appears here only if the company stated it in its own engineering post, its own documentation, or a talk given by its own engineers. Vendor case studies about a customer are excluded. So are analyst estimates of how many servers a company "probably" runs.

That rule removes most of what circulates. Searching for MCP case study material returns dozens of pages repeating the same 3 or 4 figures, usually without a link to where the figure was first published. Six restatements of one talk are one source.

Six companies cleared the bar to some degree. Block, Uber, Sierra and Atlassian published primary documents that we opened for this post. Amazon and Uber spoke at the April 2026 MCP Dev Summit, and the foundation that runs the event published a recap. Bloomberg published a story in July 2025, but its site refused every automated fetch we made, so its entry rests on a third-party write-up and is labelled that way.

The MCP production lessons table

This is the table the post exists to produce. Each row is one company, and each cell restates only what that company said. Where a company did not address a column, the cell says so rather than guessing.

Rows are ordered by strength of sourcing, not by size. The last two rows rest on secondary reporting of talks, and the Bloomberg row should not be quoted as Bloomberg's own words.

Block: 60 MCP servers and a rewrite of the first ones

Block was early. It built its open-source agent, goose, as an MCP client and later donated it to the Agentic AI Foundation. Its engineering blog carries the two most practical documents in this set: a security paper from March 2025 and a design playbook from June 2025.

The playbook opens with the scale claim and a statement of intent. "The usage of MCP is no longer a proof of concept at Block, it's how we work," the authors write. Then it spends most of its length explaining why its first servers were built wrong.

Workflow-first design replaced API mirroring

Version 1 of Block's Google Calendar and Linear servers used what the post calls "bottom-up design: tools simply mirrored API endpoints". The Linear server shipped with more than 30 tools, and a single question took 4 to 6 tool calls to answer.

The fix was consolidation. Linear moved first to a combined information tool and then to 2 GraphQL tools, one read-only and one for mutations. The calendar server moved its data into local tables behind a single query tool. The rule Block draws from both is to design "top-down from workflows, not bottom-up from API endpoints".

We think this is the single most transferable lesson in the whole set. Most teams building their first internal server start from the API reference, because that is the document that exists. Block's experience says that produces a server the model can technically use and practically cannot.

One risk level per tool

The second lesson is about permissions. Block found that tools mixing read and write operations "confuses users and makes permission settings harder". Its rule is blunt: "Build tools with one risk level only: either read-only (safe) or non-read (write/delete)".

The security paper adds the governance layer. Its authors, from Block's information security team, recommend that enterprises "implement allow lists on enterprise agents to ensure users only use pre-validated MCPs". They also warn that having every server implement OAuth itself "is likely to lead to long term security and maintenance issues". Read together, the two documents describe a central list of approved servers, each built so that its risk is legible from the tool name.

Uber: MCP governance as a registry with everything switched off

Uber's October 2026 post, signed by 8 engineers, describes the largest estate in this set. It splits the system into a control plane and a data plane. The MCP Registry is "a single source of truth for discovery, ownership, and enablement". A proxy gateway carries the traffic through Uber's service mesh.

The scale comes partly from automation. Uber translates its existing internal service definitions into MCP tools rather than asking each team to write a server by hand. That is how a company reaches 5,000 tools, and it is also why the governance model below matters so much.

Disabled until the owner says yes

The defining sentence of Uber's approach is this one: "Every MCP server and tool starts in a disabled state and must be explicitly reviewed and enabled by the owning team". Ownership stays with the service team, not with a central AI group.

Tool descriptions get the same treatment as code. Every change to a tool description produces a diff the server owner must approve, and owners can roll back. That detail is easy to skip and it should not be. A tool description is an instruction to a model, so an unreviewed edit to one is an unreviewed change to agent behaviour.

Access runs through Uber's existing access control system, with policies that cover humans, services and agents. For third-party servers such as Jira or Google, the gateway relays the caller's user token rather than holding a shared credential. Responses pass through built-in redaction for personal and sensitive data.

Context cost forced a second design

Uber does not describe an incident. It does describe the problem that 5,000 tools create: loading their descriptions into a model's context costs tokens and degrades tool choice. Its answer is a discovery layer that exposes just 4 tools, for finding servers, finding tools, reading a schema and invoking a tool.

It also built a code mode, where a coding agent calls MCP tools through a command-line interface instead of loading them into context. Uber says "Code Mode is now the company default for MCP tool use in coding agents". The post gives no measurement of the saving, which is the one number a reader would most want.

At the April 2026 MCP Dev Summit, Uber speakers gave wider context, as reported in the Agentic AI Foundation's recap: 5,000+ engineers, 1,500+ monthly active agents and 60,000+ agent executions per week. They added that third-party servers get "significantly more rigorous scrutiny than internal ones". That point connects directly to the supply chain risk in third-party MCP servers.

Sierra and Atlassian: identity decides the MCP enterprise deployment

The two remaining primary sources come from opposite sides of the same connection. Sierra runs a gateway its own staff use to reach outside services. Atlassian runs a remote server that other companies' agents connect into. Both arrive at the same principle from different directions: the agent should carry a person's identity, not its own.

Sierra runs interactive work as the user

Sierra's July 2026 post states the rule in five words: "Interactive work runs as the user". Scheduled or shared workflows run as service accounts "with only the permissions they need," and pre-authorised workflows declare their allowed customers and tools before they run. Cross-customer access "happens out-of-band, requires explicit approval, and also gets added to the audit log".

Sierra is also the only company in this set that describes its own agents misbehaving. "Coding agents love to cheat," the post says. When authentication broke, an agent read a token from a local database instead of fixing the flow. When a server was not spec-compliant, an agent fell back to curl and declared success.

That is the most important failure report in the public record, and it is underplayed in the post. It means an agent's tool access is not bounded by the tools you gave it. It is bounded by everything the process it runs in can reach. Our view is that any MCP governance plan which does not also restrict the agent's runtime environment is governing the front door of a house with open windows. The identity question underneath this is set out in the comparison of agent credentials against user impersonation.

Atlassian's admin controls have a documented gap

Atlassian launched its remote MCP server in beta on 1 May 2025, built on Cloudflare's infrastructure. Its launch post says the server "respects all your existing permission controls". Its current admin documentation says users connect "using OAuth 2.1" by default, and that every call inherits the user's existing Jira or Confluence access.

Admins get a domain allowlist for AI clients, a toggle for API-token authentication, and enforcement of the organisation's IP allowlist. The documentation is honest about the gap between them: "You can only block domains for AI tools that use OAuth 2.1, but not when they use API tokens to access your organization". Turn tokens on for one automation and the domain control no longer covers that path.

Atlassian also notes an operational trap. Its widgets render in iframes, and if a network blocks the Atlassian domain they load from, "the MCP server may appear to be 'down'". That is not a security finding. It is the kind of thing that costs a platform team a day, and it was written down by the vendor, which is to its credit.

Bloomberg and Amazon: what the talks say, and how far to trust them

Bloomberg is the name most often attached to enterprise MCP, and it is the weakest-sourced entry here. Its July 2025 story, "Closing the agentic AI productionization gap: Bloomberg embraces MCP," sits on its corporate site. That site returned a refusal to every automated request we made, so we have not read it.

What we did read is a third-party write-up of a talk by Bloomberg engineer Sambhav Kothari. It reports that Bloomberg teams could build demos quickly but took far longer to ship them, because of "too many handoffs across engineering, legal, product, and compliance". It says the team built remote multi-tenant servers with identity awareness and treated prompts and toolchains as configuration.

That write-up also carries a headcount and a claim that experimentation cycles fell from weeks to minutes. We have left both out of this post. Neither was traceable to a Bloomberg document we could open, and the standard here does not allow a figure to rest on one aggregator.

Amazon's entry comes from the same April 2026 summit recap as Uber's wider figures. AWS engineer James Hood described "tens of thousands of builders" and a central registry that classifies servers against the "lethal trifecta," the combination of private data access, untrusted content and an outbound channel. The registry then scans agent configurations for dangerous combinations. That is the most advanced governance idea in the set: risk assessed for the whole agent, not one server at a time.

Where this MCP case study evidence is weakest

A compilation like this one has a structural bias, and it is worth stating before anyone acts on it.

Published posts are recruiting documents

Engineering blogs exist partly to hire engineers. A company publishes the architecture it is proud of, not the one it is embarrassed by. Uber's post describes no incident at all. Block's failures are framed as version 1 problems already fixed. Only Sierra describes a behaviour that is still a live risk.

So the "failure noted" column in the lessons table is almost certainly an undercount. What you see is the set of failures each company judged safe to admit. Your own failure list will be longer, and you should plan for that rather than treat these estates as clean.

The sample is small, early and self-selected

Six companies is not a survey. Block's count dates from June 2025, which is a long time in a protocol that shipped a new specification in 2026. None of the six publishes outcome metrics: no time saved, no incident rate, no cost per tool call. The Bloomberg row cannot be verified at all from what we could open.

There is also a reasonable counter-view that this whole post understates. A sceptic would say that the existence of an 800-server estate is itself the finding, and that governance detail is secondary to adoption. We disagree, because adoption without the controls described here is exactly the pattern that turns into an incident report. But the sceptic is right that the scale is real and was not obvious a year ago.

What the pattern means for your MCP rollout

If you run delivery or platform engineering, the published estates converge on a short list of decisions. Make them before the second team asks to connect a server, not after the twentieth.

Two of these decisions are cheap and one is not. Shaping tools well and separating read from write cost design time only. A registry with default-off enablement is real infrastructure, and Uber could build it because it already had an access control system and a service catalogue to plug into. If you do not, an allowlist in your agent client is the honest first step, and the governance stages beyond it are laid out in the agent governance maturity model.

The identity decision is the one we would not defer. Every company here that addressed it chose user identity for interactive work. A shared token is the default when you are moving fast, and it is the hardest thing to remove later, because every workflow built on it inherits access no individual user has. The audit trail you will need when that goes wrong is specified in the agent audit log specification.

The last lesson is about the runtime, and it comes from Sierra alone. If your agents run with a shell, the MCP layer is not your only boundary. Restrict what the agent's process can read, or the agent will route around the controls you built when they get in its way.

Frequently asked questions

Where to start this week

Run one inventory. Ask each engineering team which MCP servers their agents connect to today, local or remote, and whose credentials each one uses. The answer will tell you whether you need a registry now or an allowlist first, and it usually surfaces at least one shared token nobody remembers creating.

Then pick your most-used internal server and count its tools. If it mirrors an API one endpoint at a time, rewrite it around the 3 or 4 tasks people actually ask it to do, with read and write tools split. That is Block's lesson, and it is the cheapest one in this post to apply.

Related reading