Infra · October 2, 2026 · 10 min read
Uber Engineering’s MCP Gateway now fronts more than 800 MCP servers and 5,000 tools, auto-generating agent-callable surfaces from Protobuf and Thrift IDLs while keeping every discovered tool disabled until the owning service team explicitly enables it.
On October 1, 2026, Uber published Designing MCP Gateway: Uber’s MCP Management Platform, a long architecture post from Alok Srivastava, Deepanshu Mehndiratta, and Gaurav Gill on the Business Platform team. Uber Engineering amplified it on X on October 2, where the thread quickly accumulated hundreds of thousands of views—signal that infrastructure teams far outside San Francisco are hunting for reference designs, not another model leaderboard. The headline numbers are not marketing rounding: the gateway is hosting over 800 MCP servers and over 5,000 tools, acting as the orchestration layer between internal AI agents and everything from legacy HTTP and gRPC services to native MCP servers and third-party integrations such as Jira and Google.
The piece is less about model quality than about the connective tissue enterprise agent rollouts actually need—discovery, protocol translation, authorization, and governance at a scale where ad-hoc MCP wiring collapses under its own weight. Uber frames MCP Gateway as the counterpart to treating every internal API as a would-be tool: rather than rewriting microservices for agents, the gateway meets services where they already are, using Muttley for mesh routing and leaving downstream binaries untouched. That posture matters because Uber’s service count is measured in thousands; any design that requires per-team MCP expertise does not survive contact with the org chart.
Why Uber centralized MCP in the first place
Early MCP experiments inside Uber worked. Agents that could reach live business context—query internal services, inspect operational data, take bounded actions—were visibly more useful than chat-only assistants. The problem was organizational, not technical at the demo level. Teams built their own MCP integrations, duplicated infrastructure, and produced tools that were hard to discover, hard to operate, and tightly coupled to particular agent stacks. That pattern holds for a handful of pilots. It does not hold when hundreds of teams start exploring agentic workflows on top of thousands of internal microservices.
Uber’s answer is MCP Gateway, described as a foundational microservice that powers all MCP interactions at the company. It sits between AI-enabled clients and back-end systems, abstracting HTTP, gRPC, and TChannel behind a consistent MCP execution model. Existing APIs can be exposed as MCP tools without rewriting downstream services; security and observability are supposed to be centralized rather than reimplemented per team. The design thesis Uber states plainly: at production scale, the hard part is not the LLM—it is the discovery, security, and reliability that make agents trustworthy enough to act for real users.
Control plane versus data plane
The platform splits cleanly into two halves. The MCP Registry is the control plane: catalog of servers and tools, ownership, enablement, and configuration history. The Proxy Gateway is the data plane: it executes MCP requests at runtime, translates them to downstream protocols, and converts responses back into MCP-compatible JSON. The registry holds hundreds of virtual MCP servers backed by internal services plus thousands of tool definitions, ranging from no-code API exposures to native MCP implementations built directly against the specification.
At runtime the proxy exposes a per-service entry point—Uber documents a /<service-name>/mcp endpoint for each virtual server—resolved through built-in proxy handlers that are both tool-aware and downstream-aware. Configuration flows from the registry to the data plane on a fixed refresh cadence so enablement changes and tool updates can land without redeploying the gateway itself. That hot-reload detail is easy to skim past but operationally huge: when a tool description changes or an owner disables a risky RPC, agents should see the new world quickly, not after a fleet restart.
Uber lists the gateway’s practical wins as easy discovery and installation, a no-code path for existing APIs, built-in observability and security, and centralized ownership. Those bullets sound generic until paired with the 800/5,000 scale: discovery is not a developer-portal nice-to-have when five thousand tools exist; it is the difference between agents that can act and agents that drown in manifests. Centralized ownership, meanwhile, is how Uber keeps AutoCrawler from becoming an accidental privilege-escalation machine—catalog breadth without enablement would be unusable in a regulated, multi-tenant internal environment.
AutoCrawler and the no-code path from IDL to tool
Manually authoring an MCP server for every internal API would stall agent adoption immediately. Uber runs thousands of services with interfaces defined in Protobuf or Thrift IDLs. AutoCrawler is the discovery engine that keeps the registry aligned with that world. It is a Cadence-powered distributed workflow subscribed to Uber’s IDL registry and internal service signals; on a schedule, a cron triggers workflows that scan for new services, APIs, and schema changes.
For each discovered entity AutoCrawler creates or updates MCP server representations, generates or fetches tool definitions and schemas, and registers tools in the MCP Registry in a disabled-by-default state. For IDL-backed services the pipeline is explicit: upsert a virtual MCP server, parse protobuf or Thrift for methods and request/response shapes, use an LLM to generate agent-friendly tool descriptions from schemas and doc comments, translate types into MCP-compatible JSON-RPC 2.0 schemas, and upsert tools—still disabled until a human owner approves exposure.
Native MCP servers follow a parallel path via MCPFx, Uber’s framework for first-party MCP implementations. Each native server emits a heartbeat metric; AutoCrawler watches those signals, calls listTools on newcomers, and registers a virtual proxy server containing the discovered tools—again disabled until owners enable them. The important governance line Uber repeats: discovery does not imply exposure. Crawling can populate the catalog without putting callable endpoints on the internet inside the company.
Using an LLM to write tool descriptions from IDL comments is a deliberate product choice. Raw protobuf names rarely tell an agent when to call a method or what failure modes look like; enriched descriptions are part of making automated discovery usable. Uber couples that generation with owner review so the model’s wording is not the final security boundary—humans still approve what becomes callable. For readers building similar systems, the lesson is that catalog automation and policy gates are paired features, not alternatives.
Authoring, enablement, and third-party MCP
Even when Uber generates MCP artifacts without involving a service team upfront, ownership stays with that team. Service owners review generated descriptions, refine them, and explicitly enable servers and tools. Description edits trigger configuration diffs that owners must approve; they can deploy approved changes or roll back to a prior version. That workflow matters for compliance-minded readers: AutoCrawler plus LLM-written descriptions scale catalog breadth, but the enablement gate is what prevents surprise agent access to sensitive RPCs.
Third-party MCP servers (Jira, Google, and similar) ride the same gateway with a split responsibility model. MCP Gateway relays the caller’s user token downstream while applying authorization, rate limiting, and sensitive-data redaction. A separate third-party MCP service exchanges the internal user token for the external provider’s token before hitting the outside MCP server. Uber gets one orchestration and policy surface even when the tool implementation lives outside the fleet.
Executing calls: Muttley, translation, and redaction
On the data plane, server handlers map each tool to a downstream destination—HTTP endpoint configuration or gRPC/TChannel procedures kept in memory. When an MCP request arrives the handler translates JSON into wire-format bytes, forwards through Muttley (Uber’s service mesh sidecar), and converts protobuf or Thrift responses back to MCP JSON for the agent. Native MCP servers register as virtual proxies; runtime traffic is forwarded transparently to the real server and returned unchanged in shape to the caller.
Security is tool-granular. The gateway integrates with Uber’s internal access control (“charter” policies on detected caller actors—humans, services, and agents) with optional per-tool overrides. Responses pass through out-of-the-box redaction for PII and other sensitive fields. That combination is what lets a single gateway front both benign read-only tools and high-risk write paths without giving every agent blanket service credentials.
Protocol translation is the unglamorous core. Agents speak MCP JSON; Uber’s fleet speaks years of protobuf, Thrift, and HTTP conventions. The gateway handlers serialize and deserialize across that gap so agent authors think in tools while service owners keep their existing contracts. Delegating execution to Muttley also means retries, routing, and mesh-level behavior stay consistent with non-agent traffic—one less divergence for SRE teams to debug when an agent spike looks like a microservice incident.
When tool catalogs eat the context window
Scaling to hundreds of servers surfaced a second-order problem: context bloat. MCP has no built-in cross-server search. An agent must already know which server to talk to before it can list tools, and wiring hundreds of server URLs, credential sets, and tool manifests into a client consumes model context fast. Uber’s mitigations read like a mini-platform on top of the platform.
Omni MCP is a single proxy that exposes incremental discovery tools: discover_server (intent-based server lookup), discover_tools, get_tool_schema, and invoke_tool. Agents fetch only what they need for the current step while still inheriting gateway authorization and the rest of the control plane.
Response Projection is a GraphQL-like pattern for MCP calls: the model injects a field listing nested paths it cares about, and the gateway trims payloads at runtime so enormous API responses do not flood context. Uber credits that mechanism with making enterprise-scale API schemas usable through MCP at all.
Code Mode targets coding agents that live in shells. Through aifx, Uber’s CLI for agentic operations, agents run aifx mcp list, aifx mcp search, and aifx mcp call without installing MCP servers locally or loading full tool definitions into the prompt. Output can land in files that filesystem-based agents grep selectively. Uber states Code Mode is now the company default for MCP tool use in coding agents—an admission that context economics matter as much as RPC compatibility.
Omni MCP’s staged discovery—server first, then tools, then schema, then invocation—mirrors how a human engineer would explore an unfamiliar internal platform, but machine-enforced and token-bounded. Response Projection then attacks the other side of the bill: even a correct tool call can return a JSON blob too large to reason about inline. Together they describe an maturity path Uber hit only after the catalog grew past “we can list everything in the system prompt.” Startups copying MCP literally from laptop tutorials may never feel that pain; Uber’s post is written for the moment the pain arrives.
What other builders should take from the post
Uber’s write-up is explicitly a design document for peers facing the same fragmentation curve. The through-line is conservative about exposure and aggressive about automation: crawl IDLs, LLM-enrich descriptions, register everything, enable nothing by default, execute through a mesh sidecar you already trust, then layer discovery and projection tricks once the catalog outgrows any single agent’s context window. None of that replaces model safety work, but it explains how a ride-hail and delivery conglomerate got from “MCP demos worked” to 800+ servers and 5,000+ tools without asking every service team to become MCP experts overnight.
The blog also notes Uber’s cover art for the post was generated with ChatGPT by OpenAI with no external logos—a separate acknowledgment in their piece. Afterimage’s lead image is an independent photograph supplied for this article; in-body diagrams and screenshots are Uber’s figures as labeled.
Readers outside Uber will not get access to the gateway itself; the value is the blueprint. If your organization is past a dozen MCP integrations and agents still cannot find tools reliably, Uber’s numbers suggest the next investment is probably gateway and registry engineering—not another frontier model API key.
Abhishek Bhatia, credited in Uber’s author notes, contributed to AI developer tooling including Code Mode in aifx—linking the gateway story to how coding agents actually run inside the company day to day. Gaurav Gill’s bio on the post ties MCP Gateway to Uber’s broader “deep agent ecosystem” on the Edge Platform team. The through-line for external readers is continuity: this is not a skunkworks demo archived in a PDF; it is infrastructure Uber expects agents to ride for the foreseeable future, with figures, UI screenshots, and explicit scale metrics to prove it.
Sources
- Uber Engineering, “Designing MCP Gateway: Uber’s MCP Management Platform,” October 1, 2026. https://www.uber.com/us/en/blog/designing-mcp-gateway/
- Uber Engineering on X, MCP Gateway article link, October 2, 2026. https://x.com/UberEng/status/2106071967619322330