Uber's MCP Gateway: Taming 800+ AI Agent Tool Servers
Uber has built an internal MCP Gateway to standardize how its AI agents discover and call internal services. The platform now supports more than 800 MCP servers and over 5,000 tools, giving the company a single layer for discovery, protocol translation, authorization, and execution of agent requests. For any organization watching its own agent experiments grow past the pilot stage, the details of how Uber got here are worth a close look.
What Uber built and why
MCP, or Model Context Protocol, is a standard that lets AI agents discover and invoke external tools and services in a consistent way, rather than each integration being built from scratch. Uber adopted this standard internally because fragmented integrations, duplicated infrastructure, and inconsistent security practices were becoming harder to manage as agent adoption spread across its engineering teams. The scale here is the telling part: once you are coordinating 800 servers and 5,000 tools, manual wiring simply stops being an option.
The architecture splits responsibilities between two components. The MCP Registry acts as the control plane, storing tool definitions, schemas, ownership information, and enablement settings. The Proxy Gateway handles runtime execution, translating MCP requests into HTTP, gRPC, or TChannel calls and converting the responses back into MCP-compatible output. This design exposes Uber's existing internal APIs as MCP tools without requiring changes to the underlying services themselves, which matters because rewriting hundreds of services just to make them agent-accessible would have been its own multi-year project.
Industry commentators have pointed out that this pattern is not entirely new. Ajay Sharma, a principal software engineer at Microsoft CoreAI, compared it to existing API gateway practices, describing it as a recipe for order amid the chaos that large language models tend to introduce. Kelly Goetsch, president at Pipe17, made a similar point, noting that Uber's gateway resembles the API and GraphQL gateways companies have built for decades. The underlying idea is familiar; what's new is applying it specifically to how autonomous agents discover and call tools.
Why this matters now for agent-heavy organizations
The timing reflects a broader shift happening across engineering organizations that are moving from experimental AI agent pilots to production deployments touching many internal systems. Once an agent needs to query dozens or hundreds of services, ad hoc integrations stop scaling. A security model designed for a handful of trusted internal callers simply doesn't fit an environment where autonomous agents, not humans, are making the calls.
Uber's approach also addresses a practical discovery problem. The company built AutoCrawler, which automates tool discovery using Cadence, a workflow orchestration system. It scans internal interface definition language registries, extracts API definitions from Protocol Buffers and Thrift schemas, generates MCP-compatible schemas, and uses a large language model to draft tool descriptions. Newly discovered tools stay disabled until their owning teams explicitly review and enable them, which keeps automated discovery from silently exposing sensitive internal functionality to agents that shouldn't have access yet.
Who this affects and how
Two groups stand to be affected most directly by this pattern. Platform and security teams at large organizations running many internal services will recognize the governance problem Uber describes: once agents can call APIs on behalf of users, authorization, data redaction, and auditability all need to be enforced centrally rather than per-service.
Uber's gateway enforces authorization at both the server and tool level through its internal access control system, and it supports redaction of personally identifiable information and other sensitive data in tool responses. For third-party integrations such as Jira and Google, a separate service exchanges internal user tokens for the corresponding external authentication tokens. That keeps credential handling centralized rather than scattered across dozens of individual agent integrations, each managing its own secrets.
The second group affected is engineering teams building agent-facing tooling itself. As the tool catalog grows, loading definitions for thousands of tools into an agent's context window becomes inefficient and, at some point, simply impossible within token limits. Uber's response was Omni MCP, which supports incremental discovery: agents search for relevant servers, retrieve individual schemas, and invoke only the tools they need rather than loading everything upfront. A feature called Response Projection lets agents request specific fields from a response instead of receiving the full payload, cutting down the amount of data an agent has to process and, by extension, the cost of each call.
What's sensible to do now, and what to watch
For organizations earlier in their AI agent rollout, the lesson from Uber's build is less about replicating the exact architecture and more about recognizing when a centralized gateway becomes necessary. A handful of agent integrations can be managed case by case. Once the number of internal services an agent might touch grows into the hundreds, the governance, discovery, and context-size problems Uber describes tend to appear regardless of company size or industry.
It isn't clear from the available reporting whether Uber plans to open-source any part of this gateway, nor how it measures the gateway's impact on developer velocity or security incidents. Organizations evaluating similar architectures should treat MCP as one implementation path among several, and weigh the governance benefits against the engineering investment required to build and maintain a registry, a proxy layer, and an automated discovery pipeline comparable to AutoCrawler. Building that stack from scratch is a real commitment: it needs dedicated platform engineers, ongoing schema maintenance, and a security review process that doesn't bottleneck every new integration.
Teams building or scaling agent infrastructure today would do well to track how authorization, data redaction, and incremental tool discovery are handled in their own stack, since these are the areas where ad hoc approaches tend to break down first as agent usage expands. In our own work on AI solutions and process automation projects, we see this same pattern show up at a smaller scale well before a company reaches Uber's size: a handful of internal tools connected to an agent without a shared access policy, and no clear owner once something goes wrong. Businesses weighing whether to build this kind of infrastructure internally versus relying on existing platforms may also want to consult software consulting expertise to assess the right level of investment for their scale.
If your team is already running several AI agent pilots and starting to feel the strain of managing access and integrations one by one, it may be worth mapping out the problem before it grows further. You can reach out through our contact page to talk through where your current setup stands and what a reasonable next step looks like.
