Uber Builds MCP Gateway to Govern 5,000 AI Agent Tools

On November 2, 2026, Uber published details of an internally built MCP Gateway designed to solve a problem any company scaling AI agents will recognize: fragmented integrations, duplicated infrastructure, and inconsistent security practices. According to the account reported by InfoQ, the platform already supports more than 800 MCP servers and 5,000 tools, functioning as a common layer for discovery, protocol translation, authorization, and execution for all of the company's agents.

The case matters less for the raw number and more for what it reveals: the Model Context Protocol (MCP) has become the de facto standard for connecting agents to corporate systems, but no one had solved, on their own, the problem of governing hundreds of MCP servers growing without control. Uber treated this as an infrastructure problem, not an AI problem.

The problem before the gateway

Before the gateway, each team that wanted to expose a service to agents had to build its own MCP integration, reimplementing authentication, schemas, and execution logic. The result is the same as in any microservices environment without standardization: multiple implementations of the same type of problem, none of them centrally auditable.

Uber's solution was to treat agents as just another type of API client, and apply to that client the same architectural rigor the company already applies to internal REST and gRPC APIs. That meant clearly separating two responsibilities that, in simpler MCP implementations, tend to get mixed together.

Two layers: registry and proxy

The architecture described by Uber's engineers divides the system into two components with distinct responsibilities:

• MCP Registry: functions as the control plane. It holds tool definitions, schemas, ownership information (which team owns which tool), and enablement settings.
• Proxy Gateway: handles real-time execution. It translates MCP requests into HTTP, gRPC, or TChannel calls against the actual services, and converts the responses back into MCP format.

This separation is what makes it possible to expose existing internal APIs as MCP tools without changing the original services' code, a decision that drastically lowers the adoption cost for each team. It's no coincidence that the approach has been compared to already familiar API gateway patterns. Ajay Sharma, Principal Software Engineer at Microsoft CoreAI, summed up the point in a LinkedIn post:

Azure API Gateways has been doing this for a while now. It's a recipe for order to the chaos that LLMs come with.

Ajay Sharma, Principal Software Engineer at Microsoft CoreAI

Kelly Goetsch, President at Pipe17, made a similar observation:

Uber's new MCP gateway looks identical to gateways we've built over the decades for APIs and later GraphQL.

Kelly Goetsch, President at Pipe17

Tamir Dresher, in another post cited by InfoQ, stressed that the design doesn't invent new problems: security, discovery, observability, and governance remain the same long-standing concerns in distributed systems, just now applied to agents.

AutoCrawler: automatic tool discovery

With more than 800 servers, cataloging tools by hand doesn't scale. Uber built AutoCrawler, which runs on top of Cadence (the company's own workflow engine) and automates discovery:

1. It scans the company's internal interface definition language (IDL) registries.
2. It extracts API definitions from Protocol Buffers and Thrift schemas.
3. It generates MCP-compatible schemas from those definitions.
4. It uses a language model to produce the tool descriptions.

One governance detail matters here: newly discovered tools are disabled by default until the owning team reviews them and explicitly enables access. Configuration changes propagate to the data plane without requiring a restart or a new deploy of the services, which keeps the catalog up to date without operational friction for whoever maintains the source services.

Security: authorization, PII, and third-party tokens

The gateway applies authorization at two levels, server and tool, using Uber's internal access control system. This means an agent can have access to an MCP server but not to all the tools it exposes, the kind of granularity that's missing from most hastily built MCP integrations.

The system also supports redacting personal data (PII) and other sensitive information from tool responses before the content reaches the agent. For integrations with third-party services, such as Jira and Google, a separate service exchanges internal user tokens for the corresponding authentication tokens of each third party, preventing internal credentials from leaking outside the company's perimeter.

Omni MCP: the problem of context that grows too large

With the tool catalog numbering in the thousands, loading all definitions into an agent's context stops being viable, both in token cost and latency. Uber responded with Omni MCP, which implements incremental discovery: the agent searches servers, discovers the tools relevant to the task, retrieves the individual schema for each one, and only then invokes the ones it needs, instead of loading the entire catalog at once.

A second mechanism, called Response Projection, lets the agent request only specific fields from the response, instead of receiving the full payload back. For anyone who has dealt with agents blowing through the context window processing a giant JSON from an API just to use three fields, the practical gain is obvious.

Uber also maintains a CLI called aifx, which lets coding agents discover and invoke tools directly, writing the results to files for selective inspection, instead of dumping everything into the conversation context.

What this means for those building with MCP

Uber's case is a sign of maturity for the MCP ecosystem: the first wave of adoption, connecting an agent to an API via an individual MCP server, works at small scale, but breaks down at exactly the same points where any microservices architecture without a central gateway breaks down. Diffuse ownership, inconsistent authorization, no central visibility into who accesses what.

For teams connecting their first agents to internal systems today, the replicable lesson isn't the scale (few companies will have 800 MCP servers), but the principle: separating the control plane (what exists, who owns it, what's enabled) from the execution plane (how the call actually happens) from the start avoids rewriting everything once the number of integrations goes from dozens to hundreds.

What remains open, and InfoQ doesn't detail, is how Uber measures the operational cost of keeping AutoCrawler and Omni MCP running over a catalog that only grows, nor which observability metrics the team uses to decide when a tool turns from useful into risky.