Generated by Codex with GPT 5.6 Sol High

At enterprise scale, connecting an AI agent to a useful tool is less an integration problem than a platform problem. A few hand-built Model Context Protocol (MCP) servers can work well, but hundreds of teams independently wiring agents to internal systems create duplicated infrastructure, inconsistent security, poor discoverability, and tool definitions that are expensive to load into a model’s context. In “Designing MCP Gateway: Uber’s MCP Management Platform,” published by the official Uber Engineering blog, Uber describes the shared control and data planes it built to turn thousands of existing service APIs into governed agent tools. The platform now hosts more than 800 MCP servers and 5,000 tools.

Put a stable agent interface in front of existing services

Uber’s central architectural choice is to preserve the company’s existing back ends rather than require every service team to build and operate a new MCP server. The MCP Gateway presents a uniform MCP interface to agents while translating calls to HTTP, gRPC, or TChannel behind the scenes. That separates the interface agents consume from the protocols services already speak.

The system is split into a control plane and a data plane. The MCP Registry is the control plane: it stores server and tool definitions, schemas, ownership, and enablement state. The Proxy Gateway is the data plane: it loads those configurations into memory, materializes virtual MCP servers, routes requests, converts JSON payloads into Protobuf or Thrift when necessary, and translates responses back into MCP-compatible JSON. Downstream calls flow through Muttley, Uber’s service-mesh sidecar, so the gateway inherits existing routing and service-to-service infrastructure instead of recreating it.

This boundary is useful beyond MCP. A new interface can spread quickly when it adapts mature systems in place and centralizes only the concerns that truly need to be common. Protocol translation, authentication, observability, and policy enforcement belong in the gateway; business behavior remains in the services that already own it.

Automate discovery, but keep exposure deliberate

Manually authoring thousands of tool definitions would make service teams the bottleneck. Uber’s AutoCrawler instead scans the company’s interface-definition registry for services, APIs, and schema changes. A scheduled Cadence workflow parses Protobuf and Thrift definitions, extracts methods and documentation, uses an LLM to enrich descriptions for agents, converts schemas into MCP-compatible JSON-RPC definitions, and upserts the results into the registry. Native MCP servers are discovered through heartbeat signals and queried with listTools.

Discovery is intentionally not the same as permission to use a tool. New servers and tools are registered disabled by default. Their owners review and refine the generated definitions, approve configuration diffs, and can roll changes back. That design preserves the speed of automated inventory without letting automation silently expand an agent’s authority.

The same principle applies at runtime. The gateway uses Uber’s internal access-control system to distinguish human, service, and agent callers and apply server-level policies with optional tool-level overrides. It also redacts sensitive data from responses. For third-party services, the gateway forwards the caller’s internal identity to a separate component that performs the external token exchange, while retaining centralized authorization, rate limiting, and redaction.

Make tool discovery incremental

A registry containing thousands of tools creates a second scaling problem: even if every tool is valid, giving all of their schemas to a model would consume too much context and make selection harder. Uber addresses this with staged discovery rather than a giant static tool list.

Omni MCP exposes a small set of meta-tools that let an agent search for a server, inspect its tools, fetch one schema, and invoke the chosen tool. The model pays the context cost only for definitions relevant to the current task. Response Projection cuts the other side of the context budget: callers specify the nested fields they need, and the gateway removes everything else before returning a tool result.

Coding agents get an additional path called Code Mode. Uber’s aifx command-line interface lets them list, search, and call gateway tools without installing each MCP server or placing every definition in the prompt. Results can be written to files and inspected selectively with ordinary shell tools. This makes the filesystem a buffer between large service responses and the model’s limited context, and it is now Uber’s default MCP access pattern for coding agents.

The broader engineering lesson

Uber’s design treats agent tooling as production infrastructure rather than a collection of clever wrappers. The important work is not merely converting an API into a tool. It is maintaining a trustworthy catalog, preserving ownership, mediating identity, enforcing least exposure, refreshing configuration without redeployments, and controlling how much schema and response data enters the model’s context.

The strongest general lesson is that agent platforms need both centralization and restraint. Centralize the repetitive connective tissue so teams get a consistent security and operating model. Keep tools disabled until owners approve them, reveal capabilities progressively, and reuse the service boundaries that already encode business responsibility. That combination lets an organization scale agent access without turning convenience into uncontrolled authority or context into an unbounded tax.