Designing Uber's MCP Gateway news update

Uber deployed a centralized platform called MCP Gateway to standardize Model Context Protocol interactions between artificial intelligence agents and internal backend services, as detailed in uber.com's report. Authored by Alok Srivastava, Deepanshu Mehndiratta, and Gaurav Gill, the architecture replaces fragmented team integrations with unified routing and execution. The gateway hosts over 800 MCP servers and exposes more than 5,000 tools.

This report examines the architecture of Uber's gateway, covering its Cadence-powered AutoCrawler discovery engine, protocol translation proxy, and control plane governance mechanisms. It is designed for systems engineers, backend architects, and engineering managers aiming to deploy agentic systems across distributed enterprise microservices without requiring service owners to rebuild APIs or manage custom infrastructure.

Designing Uber's MCP Gateway news update: what actually changed

Uber replaced fragmented, team-level Model Context Protocol integrations with an enterprise microservice that decouples AI agents from backend engineering stacks. Earlier ad-hoc implementations across individual teams caused duplicated infrastructure, tight service coupling, and inconsistent reliability as adoption spread across hundreds of engineers. The new MCP Gateway establishes a shared control and data plane, consolidating protocol translation, security validation, and traffic management into a single platform that currently manages more than 800 MCP servers and over 5,000 tools across the company.

The process of exposing backend microservices to AI agents changed from manual engineering to automated API discovery. Rather than requiring service teams to manually write MCP servers, Uber implemented AutoCrawler to scan internal Interface Definition Language registries. The crawler converts Protobuf and Thrift definitions into JSON-RPC 2.0 schemas while generating natural language descriptions with large language models. Every tool is registered in a disabled-by-default state, ensuring that discovery does not grant exposure until service owners approve and activate the definitions.

Designing Uber's MCP Gateway news update: how it works

The platform architecture separates responsibilities between the MCP Registry control plane and the Proxy Gateway data plane. AutoCrawler runs on a fixed cron schedule as a Cadence distributed workflow, scanning IDL registries and internal service signals for new APIs and schema changes. AutoCrawler automatically extracts method names and schemas, translates them into MCP formats, and registers virtual proxy representations. For native servers built with Uber's MCPFx framework, the crawler monitors heartbeat signals, executes listTools calls directly against endpoints, and indexes their active tools in the registry.

During execution, the Proxy Gateway data plane refreshes its in-memory configuration at a fixed cadence from the registry without requiring service redeployments or daemon restarts. The gateway materializes virtual MCP servers behind standardized service endpoints, routing agent calls through tool-aware server handlers. These handlers translate incoming MCP JSON-RPC calls into HTTP, gRPC, or TChannel requests and convert backend responses back into MCP format. For external services like Jira and Google, the gateway forwards caller tokens to a service that exchanges them for third-party credentials.

Designing Uber's MCP Gateway news update: why it matters

Centralizing agent tool execution resolves the mounting operational complexity and developer friction that emerge when scaling generative AI across large enterprises. Without a shared gateway, connecting multiple autonomous agents to thousands of internal microservices requires bespoke translation layers for different communication protocols and authorization schemes. Uber's gateway abstracts protocol variations across HTTP, gRPC, and TChannel into consistent interfaces, allowing agents to query internal services seamlessly. This abstraction eliminates redundant infrastructure, allowing teams to expose existing back-end APIs as reusable tools without modifying their underlying application code.

The unified architecture also establishes critical security, ownership, and governance standards across autonomous agent interactions. AI agents querying operational systems introduce significant risk if permitted to access endpoints without centralized oversight. By funneling all calls through the Proxy Gateway, Uber enforces consistent authorization, sensitive data redaction, and rate limiting across internal microservices and external providers. In addition, because all auto-discovered tools remain disabled by default, service owners retain absolute authority over their tools through mandatory configuration change diff reviews, explicit approvals, and versioned rollback controls.

Designing Uber's MCP Gateway news update: who is affected

Backend engineering teams across Uber experience major operational relief in how their microservices interface with internal artificial intelligence systems. Service maintainers are no longer forced to build or manage custom MCP wrappers in response to requests from disparate AI teams. Instead, AutoCrawler derives virtual tool definitions directly from existing Protobuf and Thrift schemas. Service owners review LLM-generated tool descriptions inside the MCP Registry user interface, approve configuration diffs, and deploy or roll back tool access without modifying backend logic or coordinating separate release schedules.

AI agent developers gain a single, standardized entry point to access enterprise data and operational capabilities across the entire organization. Developers no longer need to investigate fragmented service documentation or build custom adapters for divergent protocols. Instead, agents discover available tools within the centralized registry and execute calls against predictable service endpoints. This uniform interface works identically across native MCPFx servers, legacy IDL-backed microservices, and external third-party applications like Jira, substantially accelerating the deployment and reliability of autonomous workflows across business units.

Designing Uber's MCP Gateway news update: what to watch

Engineering teams should monitor how the gateway handles latency and performance overhead as tool usage expands across Uber's thousands of internal microservices. The Proxy Gateway sits directly in the execution path, translating JSON-RPC requests into HTTP, gRPC, and TChannel formats in real time. Maintaining high throughput will test the gateway's ability to refresh in-memory configurations dynamically without service restarts. Observers will watch whether this centralized routing pattern introduces network bottlenecks or execution delays when hundreds of concurrent agents invoke complex multi-step backend operations.

Another key area to observe is the long-term reliability of automated tool generation and third-party token orchestration. As AutoCrawler processes ongoing schema modifications across IDL repositories, teams must ensure that LLM-generated tool descriptions remain accurate and free of ambiguity that could cause agent execution errors. Observers will also track how the gateway's token exchange mechanism handles external third-party API rate limits and sensitive data redaction policies when agents interact with enterprise systems like Google and Jira at enterprise scale.