AI Model & Platform UpdatesAgent InfrastructureEditor's Pick

Uber’s MCP Gateway: Scaling Agent Access to Thousands of Internal APIs

Uber built an MCP Gateway to let AI agents access thousands of internal APIs without forcing every team to write MCP servers. This piece explains AutoCrawler, centralized discovery, protocol translation, policy enforcement and operational patterns — and why gateway layers are becoming essential infrastructure for enterprise agents.

NexusAI Editorial DeskOct 6, 20261.7K views8 min read

Uber’s MCP Gateway: Scaling Agent Access to Thousands of Internal APIs

AI Brief

Uber’s MCP Gateway solves a scaling problem every large company will face as it deploys agents: how to expose thousands of existing APIs to autonomous systems without requiring engineering teams to rewrite services or build bespoke MCP servers. This article breaks down the Gateway’s two-plane design, AutoCrawler discovery workflow, runtime protocol translation, and policy/redaction controls. It highlights operational patterns — Omni MCP, Response Projection, Code Mode — that reduce token and cost overhead, and explains risks, ownership models, and practical steps for enterprises evaluating a gateway-first approach to agent infrastructure.

Enterprise AI agents become useful only when they can access reliable, current business context and act on it. Uber’s MCP Gateway answers a specific but unavoidable question: how do you give agents governed, discoverable access to thousands of preexisting APIs without forcing every service team to implement an MCP server? The Gateway centralizes discovery, translation and enforcement so service teams stay off the critical path — they don’t need to rewrite endpoints, and owners retain review and enablement control. That trade-off reduces duplicated infra and aligns governance while preserving operational independence for teams.

Architecturally the Gateway splits into a control plane (the MCP Registry and AutoCrawler) and a data plane (Proxy Gateway). The Registry is the single source of truth for virtual servers and tools; AutoCrawler continuously derives tool definitions from IDLs and native MCP servers so the catalog scales automatically. The Proxy Gateway materializes virtual MCP servers at runtime, translates MCP calls into HTTP/gRPC/TChannel, delegates execution to the service mesh sidecar (Muttley), and returns MCP-compatible results. This separation enables fast iteration, real-time config refreshes, and a consistent execution model for diverse agent clients.

AutoCrawler is the crucial operational lever that makes the whole system viable. Rather than relying on manual authoring, Uber uses a Cadence-driven workflow that scans the IDL registry, monitors native MCP heartbeats, parses protobuf/Thrift definitions, and generates initial tool manifests. These generated tools remain disabled by default; ownership and enablement rest with service teams. AutoCrawler also enriches schemas and descriptions using LLMs to produce agent-friendly documentation — a pragmatic compromise that balances machine-driven scale with human review and security gating.

Security, policy and operational safety are built into the gateway layer rather than scattered across teams. The platform enforces tool- and server-level charter policies through Uber’s internal access-control system, performs PII redaction on responses, and applies rate limits and auditing uniformly. Third-party MCP integrations are supported without weakening policies: the gateway relays internal tokens while third-party services exchange them for external credentials, keeping central controls intact. This model offers a practical middle path between flexibility and enterprise governance.

From a cost and performance perspective, the Gateway addresses two scaling blockers for agentic workflows: context bloat and token costs. Omni MCP provides incremental discovery — tools to find servers, list tools, fetch schemas and invoke tools — so agents don’t have to preload hundreds of tool definitions. Response Projection trims responses at runtime to requested fields only, and Code Mode (via aifx) makes CLI-based coding agents write outputs to disk instead of loading everything into model context. Together these patterns reduce unnecessary model context, latency and API spend at enterprise scale.

Key Takeaways

Centralize discovery, preserve ownership

Use automated crawling to build a searchable tool catalog, but require service owner review and enablement before exposure. This minimizes friction while maintaining accountability and security.

Optimize context and cost at the gateway

Implement incremental discovery (Omni MCP), field-level response projection, and CLI-based code mode to reduce model context, latency, and API spend for agent workflows.

Treat the gateway as critical infra with safety controls

Apply uniform access policies, PII redaction, rate limits and observability at the gateway; pair with staged rollout and canaries to limit blast radius from misconfigurations.

Design and architecture: two planes, one catalog

The MCP Gateway’s two-plane design shapes how it scales and how teams interact with it. The control plane (MCP Registry) holds a canonical catalog of virtual MCP servers and tool manifests; the data plane (Proxy Gateway) executes requests and maintains an in-memory materialization of enabled servers. This split enables instant config rollouts without redeploys and lets discovery be automated while enforcement and ownership remain human-centered. For operators, it reduces maintenance by collapsing repetitive MCP infra into one managed service that speaks to the existing service mesh.

AutoCrawler: discovery at scale without adding team workload

AutoCrawler is the discovery engine that prevents a combinatorial authoring problem. It continuously scans IDL registries and native MCP heartbeats, parses protobuf/Thrift files, generates JSON-RPC-compatible schemas, and creates virtual MCP server entries marked disabled by default. Importantly, AutoCrawler enriches tool descriptions with LLM-generated summaries and keeps teams off the critical path: service owners review and enable artifacts when ready. Practically, this means companies can bootstrap agent tool catalogs quickly while retaining review gates and ownership controls.

Security, policy and redaction: enforce once, apply everywhere

Centralizing authorization and redaction in the Gateway simplifies risk management. Uber applies server-level charter policies with optional per-tool overrides, uses the internal access-control system to evaluate caller actors (humans, services, agents), and performs PII redaction on returned data. For third-party integrations the Gateway relays user tokens while the external service performs token exchange, preserving traceability. This approach reduces variance in safety posture across teams and provides consistent audit trails while keeping enforcement close to run-time execution.

Operational patterns: Omni MCP, Response Projection, and Code Mode

Uber’s operational additions address friction around discovery and model context. Omni MCP provides discovery primitives (discover_server, discover_tools, get_tool_schema, invoke_tool) so agents can discover and call tools incrementally. Response Projection lets LLM prompts specify only needed fields so the Gateway trims responses, lowering token usage. Code Mode, exposed through the aifx CLI, lets coding agents sequence list/search/call commands and write outputs to disk; downstream filesystem agents then load only required data. These patterns are practical levers for cost control and reliability in production agent chains.

Risks, limits and who should own what

A gateway-first approach reduces duplicated effort but introduces operational concentration risk: misconfiguration or a bug in the gateway can affect many tools. Ownership boundaries are therefore critical — discovery should be automated but enablement must remain with service teams. Other limits include schema drift for IDL-backed services, edge cases in protocol translation, and residual costs from projection mismatches. Enterprises should pair a gateway with robust CI, approval workflows, canarying, and observability to mitigate systemic failure modes.

Frequently Asked Questions

Why not make every team build a native MCP server?

At enterprise scale, requiring teams to author and operate MCP servers creates duplicated infrastructure, inconsistent security, and delayed adoption. A central gateway removes that friction by translating existing APIs into MCP-compatible tools, letting teams opt in for native servers when they need finer-grained control.

How does AutoCrawler avoid exposing unsafe endpoints?

AutoCrawler only registers discovered services as disabled-by-default virtual servers. Service owners must review generated schemas and descriptions and explicitly enable tools. The gateway also layers in policy checks and automated redaction so discovery does not equal exposure.

What operational controls limit blast radius if the gateway fails?

Best practices include per-tool rate limits, server-level policies, circuit breakers, canary rollouts of config changes, live config refresh cadence, and exhaustive observability. Ownership and approval workflows ensure that only reviewed tools are enabled, and quick rollback capability reduces recovery time.