Uber's MCP gateway architecture

--- title: "What Uber had to build before it could run 1,500 agents in production" date: 2026-06-06 summary: "Uber's MCP Dev Summit talk got read as a 1,500-agent story. The interesting number is 10,000 — the internal services those agents reach through a centralized MCP gateway that did most of the load-bearing work." slug: uber-1500-agents-gateway author: "Damiën Semler" hero_glyph: grid --- At [the MCP Dev Summit in April 2026](https://aaif.io/blog/mcp-is-now-enterprise-infrastructure-everything-that-happened-at-mcp-dev-summit-north-america-2026/), Uber's Meghana Somasundara opened the company's talk with a line that has been repeated in nearly every recap since: "It takes us humans a lot more effort to break things. But with agents, it's a lot faster, a lot quicker, and the blast radius is a lot higher." Uber [now runs 1,500+ monthly active agents](https://shiftmag.dev/uber-shares-what-happens-when-1-500-ai-agents-hit-production-9430/) that execute 60,000+ tasks per week across the company's 10,000+ internal services. The number that most coverage led with was 1,500. The number that matters is 10,000. What Uber describes isn't a story about deploying agents. It is a story about the infrastructure that had to exist before the agents could be deployed — specifically, a centralized MCP gateway and registry that the agents talk to instead of talking to the underlying services directly. That gateway is the load-bearing piece. The agents are the cargo. ## What Uber actually built [Uber's MCP infrastructure](https://www.zenml.io/llmops-database/scaling-model-context-protocol-mcp-infrastructure-for-enterprise-agentic-ai), as described at the summit, has three components: - A **Gateway Orchestrator** that converts the company's 10,000+ service endpoints into MCP tools by parsing protobuf and thrift IDL files and using an LLM to generate tool descriptions. Service owners stay in control; the gateway does the manual integration work that would otherwise be paid for by every individual team building an MCP integration. - A **Gateway Service** that serves the MCP definitions to consumers and manages updates through version-controlled pull requests. - A **Central Registry** that acts as the single source of truth for tool discovery, with version tracking and conformance metadata attached. Layered onto those three components: authorization services applied at the gateway, PII redaction on responses, periodic code scanning of registered MCPs, and a hard block on mutable endpoints that could damage critical services. The two-tier trust model treats internal MCP servers as standard-vetted and third-party servers as requiring "significantly more rigorous security scrutiny" — Uber's words, not a paraphrase. Notice what is *not* in this picture: the agents themselves. The agents are the consumers of the gateway, not the source of the gateway's guarantees. A researcher pointing at the Uber stack and saying "look, 1,500 agents in production" is pointing at the outputs of the system, not its design. ## Why this is the shape of the answer, not a one-off Three of Uber's stated problems read like a generic enterprise's MCP adoption diary. From [the AAIF summary](https://aaif.io/blog/mcp-is-now-enterprise-infrastructure-everything-that-happened-at-mcp-dev-summit-north-america-2026/) of their talk: 1. Teams independently built custom MCP integrations with no reusability, creating technical debt. 2. Without visibility into call patterns and data access, unauthorized access posed significant risks. 3. Engineers lacked assurance that discovered tools were reliable, performant, and safe. The first is a standards problem. The second is an observability problem. The third is a conformance problem. None of them is solved by adopting MCP the protocol; all of them are solved by adopting MCP *plus* a registry that mediates between agents and services and *plus* governance applied at that mediation point. The protocol is necessary; it is not sufficient. Somasundara's blast-radius quote is the practical case for why mediation matters. A human accidentally querying a wrong table touches one row. An agent that learned to use that table tool through an MCP registration, and that runs in a loop with retries, can touch the table thousands of times before anyone notices. The MCP gateway doesn't prevent the agent from making a mistake. It bounds the consequences of the mistake by enforcing auth, redaction, and write-path policy at a single chokepoint. [The MCP authorization spec](https://modelcontextprotocol.io/specification/draft/basic/authorization) formalized OAuth 2.1 + PKCE for client→server flows in March 2025, and it remains optional. Uber's deployment shows what enterprises actually do with that: they make it non-optional, they enforce it at a gateway they control, and they layer in PII handling and write blocking that the spec does not specify because the spec cannot specify them — those are deployment-specific policies, not protocol-level features. ## The registry layer is where this lives The interesting comparison is between Uber's MCP Central Registry and [AAIF's hosted MCP Registry](https://github.com/modelcontextprotocol/registry), the foundation's public discovery layer for MCP servers. Both are called "registries"; they are not doing the same job. The AAIF registry publishes servers' self-declared metadata. The Uber registry attaches conformance data, version policy, scan results, and authorization configuration to each registered server, and refuses to expose servers that have not cleared the bar. Drawn as a diagram, the difference is the policy layer: | Layer | AAIF MCP Registry | Uber MCP Central Registry | |---|---|---| | Server publication | Self-declared metadata | Self-declared metadata | | Tool descriptions | Author-provided | Author-provided or LLM-generated from IDL | | Conformance signal | None today | Periodic code scan attached | | Authorization | Out of scope | Enforced at gateway | | Write-path policy | Out of scope | Blocked on critical services | | Trust tiering | Single tier | Internal vs third-party | This is not a criticism of the AAIF registry. A public discovery directory *shouldn't* impose deployment-specific policy on third-party servers; that is the job of the operator that consumes them. The observation is that the gap between "publish-and-discover" and "production-ready" is filled by infrastructure that every serious deployment has had to rebuild independently. That gap is the registry-of-registries layer the agent web has not yet standardized. The work Uber describes is a well-defined set of operations: converting IDLs to tools, scanning for safety, attaching auth, tiering trust. It recurs in every large MCP deployment. It is the most obvious candidate for the next foundation-governed primitive after MCP itself: a conformance profile that says "this server, when probed, behaves the way this scan report describes, and these are the policies a consumer should apply to mediate it." [Agenstry's registry](https://agenstry.com) operates one step removed from that — we probe what is published and we publish the probe. Uber's stack is the consumer-side mirror of that probe: they don't just want to know what an MCP server claims; they want to know what their gateway has verified about it before any agent in the building is allowed to call it. Both halves of that workflow are the same shape. One runs at the public registry. The other runs at the enterprise gateway. The protocol is the same. The policy is not. ## What we're watching Three things, observable in the next two quarters: 1. **Whether the [AAIF MCP Registry roadmap](https://aaif.io/blog/mcp-is-now-enterprise-infrastructure-everything-that-happened-at-mcp-dev-summit-north-america-2026/) absorbs a conformance-profile schema** that gateways like Uber's can consume directly, instead of every enterprise reimplementing the scanning and tiering work. If the registry stays publication-only, the gateway pattern will fragment by vendor. 2. **Whether the [MCP authorization spec](https://modelcontextprotocol.io/specification/draft/basic/authorization) moves from optional to required for new server registrations.** Uber's deployment treats it as required; the spec does not. The gap is what distinguishes a hosted directory from a production-ready one. 3. **Whether the next disclosure of a production MCP failure attributes it to a missing gateway, a missing scan, or a missing auth boundary.** The blast-radius quote is the easy version of this argument. The hard version is a concrete post-mortem. Uber has now shipped the framing; the next field report will probably ship the case study. The 1,500-agent number is the headline. What is actually being built is the gateway between those agents and the rest of the company. Most coverage will reverse the figure-ground. Read it the other way around. ## Sources - [MCP Is Now Enterprise Infrastructure: Everything That Happened at MCP Dev Summit North America 2026](https://aaif.io/blog/mcp-is-now-enterprise-infrastructure-everything-that-happened-at-mcp-dev-summit-north-america-2026/) — Agentic AI Foundation, April 13, 2026. - [Uber Shares What Happens When 1,500 AI Agents Hit Production](https://shiftmag.dev/uber-shares-what-happens-when-1-500-ai-agents-hit-production-9430/) — ShiftMag, May 4, 2026. - [Scaling Model Context Protocol (MCP) Infrastructure for Enterprise Agentic AI](https://www.zenml.io/llmops-database/scaling-model-context-protocol-mcp-infrastructure-for-enterprise-agentic-ai) — ZenML LLMOps Database, 2026. - [Authorization — Model Context Protocol](https://modelcontextprotocol.io/specification/draft/basic/authorization) — MCP Specification, accessed May 2026. - [MCP Registry — modelcontextprotocol/registry](https://github.com/modelcontextprotocol/registry) — Model Context Protocol, accessed May 2026.