Uber's MCP Gateway governs 800 MCP servers, 5,000 tools

Uber's gateway arrives as agent adoption spreads across the company, and the stated problem is a familiar one at scale: fragmented integrations, duplicated infrastructure, and inconsistent security practices. The architecture treats MCP less as a new protocol and more as another surface to govern, splitting control from execution so that tool definitions, schemas, ownership, and enablement settings live in a registry while a proxy handles runtime translation into HTTP, gRPC, or TChannel calls.

The discovery layer is where much of the operational detail sits. AutoCrawler scans internal interface definition language registries and extracts API definitions from Protocol Buffers and Thrift schemas, then generates MCP-compatible schemas and uses a large language model to produce tool descriptions. Newly found tools stay disabled until their owning teams review and enable them, and configuration changes reach the data plane without service restarts or redeployments.

As the catalog grows, loading thousands of tool definitions into an agent's context becomes inefficient. Uber's Omni MCP supports incremental discovery, and Response Projection lets agents request specific response fields rather than complete payloads. Outside observers quoted in the coverage, including Ajay Sharma of Microsoft CoreAI and Kelly Goetsch of Pipe17, compared the design to established API gateway patterns, suggesting the governance questions around agent tools may resemble those teams already know from APIs and GraphQL.