Uber's MCP gateway: 800 servers and 5,000 tools behind one control plane

Uber has published the design of the MCP gateway that fronts its agent fleet: more than 800 Model Context Protocol servers and 5,000 tools behind a single control plane, with every tool registered disabled until its owning team reviews it. Coverage calls it the first publicly documented MCP deployment at this scale from a Fortune 500 company; it reads as a reference architecture for enterprise MCP governance.

What shipped

The post, "Designing MCP Gateway: Uber's MCP Management Platform", by Principal Engineer Alok Srivastava, Senior Staff Engineer Deepanshu Mehndiratta, and Sr. Software Engineer Gaurav Gill, describes a two-plane architecture. The MCP Registry is the control plane: a catalog of servers, tools, ownership, and enablement state. The Proxy Gateway is the data plane: it translates MCP calls into HTTP, gRPC, or TChannel requests and routes them through Muttley, Uber's service mesh, so agents can call existing back-end services without those services implementing MCP themselves.

The piece that makes this scale possible is AutoCrawler, a Cadence-powered distributed workflow that runs on a cron schedule and watches Uber's IDL registry for new services, APIs, and schema changes. For each discovery it creates or updates a virtual MCP server, parses the Protobuf or Thrift definitions, uses an LLM to generate agent-friendly tool descriptions, translates the schemas into MCP-compatible JSON-RPC 2.0, and registers the tools — disabled by default. Native MCP servers built on Uber's MCPFx framework are also discovered by AutoCrawler, via heartbeat metrics and a listTools call. Third-party servers (Jira, Google) are proxied, with the gateway relaying the caller's user token to a service that exchanges it for the third-party credential.

The governing principle is stated explicitly: "discovery doesn't imply exposure." Every server and tool starts disabled and must be reviewed and enabled by its owning team; every change to a tool description goes through a config-change diff that owners approve, with rollback to a previous version. The data plane materializes virtual MCP servers from that config and refreshes its in-memory state on a fixed cadence, so enablement changes take effect without redeploys. Security is enforced per tool: charter policies from Uber's internal Access Control System apply per detected caller actor (human, service, agent), with out-of-the-box PII redaction on tool responses.

Three extensions attack the problems that only appear past a few hundred servers — what the post calls "context bloat and excessive cost":

• Omni MCP — a single proxy server exposing four tools (discover_server, discover_tools, get_tool_schema, invoke_tool) so an agent can find and call any tool in the fleet through gradual discovery, without loading every server's full schema into context.
• Response Projection — a GraphQL-like field-selection pattern that trims tool responses to only the fields the agent actually needs, cutting response-token bloat.
• Code Mode — aifx, Uber's CLI for agentic operations, routes MCP calls through the gateway with list, search, and call commands, letting coding agents write tool output to files and grep selectively instead of pulling full responses into model context.

The identity layer is documented separately in Uber's May 2026 post "Solving the Identity Crisis for AI Agents": an AI Agent Mesh where agents authenticate with short-lived, single-hop JWTs minted by a Security Token Service, each token embedding the fully attested actor chain (engineer → oncall agent → investigation agent) so the gateway sees the whole lineage, not just the immediate caller. The per-hop exchange is based on OAuth 2.0 Token Exchange (RFC 8693), on top of SPIRE/SPIFFE workload identities.

Why it matters

Two patterns here are worth copying regardless of whether you ever reach Uber's scale.

The first is disabled-by-default registration. Manually wiring up server URLs, credentials, and tool lists for hundreds of servers doesn't scale — the post's own framing — but neither does letting an auto-generated tool become callable the moment it is discovered. AutoCrawler decouples the two: discovery is fully automated, authorization is a human review step owned by the team that owns the service. That is "discovery doesn't imply exposure" made operational — the answer to the governance question every large enterprise hits when agents start touching production systems.

The second is the token-cost arc. Uber's August post on running its software factory efficiently quantifies the problem: with over 100 tools installed, pre-loading schemas added roughly 50K–70K tokens of overhead to the initial prompt, re-sent on every context turn. Omni MCP → Response Projection → Code Mode is a three-stage answer: don't load schemas until needed, don't return fields the agent didn't ask for, and don't put tool output in context at all when a file will do. Uber reports the combination cut fleet-wide token use by more than 40%, per port.io's summary of its software-factory talk (ZenML reports the same 40% figure).

This gateway is also the substrate for Uber's agentic development push. Per The Pragmatic Engineer's March coverage, 84% of Uber developers are agentic coding users and 65–72% of code inside IDE-based tools is AI-generated — which is why token economics at this layer are a first-class concern, not an optimization footnote.

Caveats

• Everything here is vendor-reported. Uber's own numbers don't fully agree: the August software-factory post says the gateway encompasses "more than 1,000 MCP servers", while the October post says "over 800 MCP servers and over 5000 tools."
• The "10,000 service IDLs" figure that appears in much of the coverage comes from Uber's MCP Dev Summit talk and secondary write-ups such as forkast, not from the blog post itself, which says Uber "operates with thousands of internal services."
• The P99-under-40 ms token-exchange latency appears in secondary coverage (forkast, speakeasy) but could not be confirmed in the security post's text.
• Coverage of the post is uniformly positive, and some of it is vendor-adjacent: speakeasy sells the infrastructure it describes as a product. The most independent treatment, The Pragmatic Engineer, predates the October post and adds the counterweight that AI-related costs at Uber are up 6x since 2024.
• The blog post's live page blocks automated fetching; the text was verified via Wayback Machine snapshots.

Sources

• Uber Engineering: Designing MCP Gateway: Uber's MCP Management Platform (Oct 1, 2026; Wayback snapshot)
• Uber Engineering: Solving the Identity Crisis for AI Agents (May 21, 2026; Wayback snapshot)
• Uber Engineering: Running a Software Factory Efficiently at Uber Scale (Aug 27, 2026; Wayback snapshot)
• forkast: Uber Ships MCP Gateway at Production Scale
• ZenML LLMOps Database: Uber — Building a Managed Software Factory with Agentic AI
• The Pragmatic Engineer: How Uber uses AI for development: inside look
• port.io: How Uber Built a Software Factory
• speakeasy: The Uber Enterprise AI Playbook
• codingscape: Inside Uber's AI & MCP gateways