Uber Engineering has unveiled a sophisticated solution to the chaos of connecting AI agents to enterprise infrastructure: the MCP Gateway. As of October 2026, the platform hosts over 800 Model Context Protocol (MCP) servers and exposes 5,000 distinct tools. This isn't just about adding another API layer; it's a strategic move to decouple agent capabilities from the underlying service architecture, allowing hundreds of internal teams to share resources without breaking protocol compatibility or ownership boundaries.

The Control Plane vs. Data Plane Split

The architecture cleanly separates concerns into an MCP Registry (control plane) and a Proxy Gateway (data plane). The registry handles the heavy lifting of storing tool definitions, ownership metadata, and enablement settings, while the proxy translates requests between MCP and Uber’s existing HTTP, gRPC, and TChannel protocols. By exposing a standardized //mcp endpoint for each virtual server, Uber allows teams to keep their downstream services untouched. This 'API reuse' model means engineers don’t need to rewrite their backends to support AI agents; they just need to register them.

Automated Discovery via AutoCrawler

Manually maintaining thousands of tool definitions is a nightmare for any platform team. Uber solved this with AutoCrawler, a discovery system built on Cadence workflows. For services defined with Protobuf or Thrift, AutoCrawler reads interface definitions to extract methods and schemas, then uses an LLM to generate human-readable descriptions. For native MCP servers, the system detects heartbeat signals and calls listTools to retrieve schemas automatically. This automation is critical for scale, but Uber enforces a strict safety net: every discovered tool starts disabled. Owners must explicitly review configuration diffs and approve enablement, ensuring that no rogue agent suddenly gains access to sensitive production endpoints.

Progressive Discovery and Context Management

At the scale of 5,000 tools, context window bloat is a real threat to agent performance. Uber addresses this with Omni MCP, a single proxy server that supports progressive discovery through four specific tools: discover_server, discover_tools, get_tool_schema, and invoke_tool. This allows an agent to search for relevant servers and inspect schemas only when needed, rather than loading the entire catalog into memory. Additionally, the gateway supports response projection, letting callers specify exactly which fields they need so the gateway can trim responses before they hit the model’s context. For coding agents, Uber’s aifx CLI offers 'Code Mode,' which lets agents write results to files and inspect them selectively, a method Uber reports as their default for MCP integration in development workflows.

Key Takeaways

  • Uber’s MCP Gateway handles over 800 servers and 5,000 tools, proving MCP can scale in enterprise environments.
  • The system separates control (registry) and data (proxy) planes to allow protocol translation without backend changes.
  • AutoCrawler uses LLMs to generate tool descriptions from code contracts, but requires manual owner approval to enable tools.
  • Omni MCP prevents context bloat by using progressive discovery and response projection to limit data sent to agents.
  • Security is enforced at the gateway level with tool-specific authorization and data redaction, not just at the service level.

The Bottom Line

Uber isn't just adopting MCP; they're industrializing it. By treating tool definitions as version-controlled, owner-approved artifacts and automating their discovery, they've solved the 'integration hell' that plagues most enterprise AI deployments. If you're building agents for a large org, steal their pattern: automate discovery, but never automate trust.