# Uber Builds MCP Gateway for 800+ Servers and 5,000+ Tools

Connecting an AI agent to one or two **Model Context Protocol (MCP)** servers on a laptop is effortless. You add a JSON block to your local config file, expose three or four tools, and watch Claude or Cursor query your database.

Now imagine what happens when an enterprise the size of **Uber** adopts MCP across hundreds of internal engineering teams. Suddenly, you do not have three MCP servers and ten tools—you have **more than 800 MCP servers and over 5,000 distinct tools** spanning HTTP, gRPC, and legacy TChannel microservices, plus third-party SaaS platforms like Jira and Google Workspace.

At that scale, naive MCP deployments collapse under two immediate failure modes: **security fragmentation** (every team rolling its own authentication and accidentally leaking PII into LLM prompts) and **context-window bloat** (dumping 5,000 JSON tool schemas into an agent's system prompt before the user even asks a question, burning tens of thousands of tokens per turn and confusing the model).

This week, Uber's engineering team revealed how they solved both problems in production by building the **Uber MCP Gateway** alongside **Omni MCP**, an incremental tool-discovery and response-filtering architecture. For any software organization scaling beyond a handful of internal AI agents, Uber's control-plane/data-plane split is the definitive reference architecture for enterprise MCP governance.

## Fast Facts

- **Control Plane vs. Data Plane Split:** Uber separates the **MCP Registry** (control plane managing schemas, tool ownership, and enablement flags) from the **Proxy Gateway** (data plane translating MCP tool calls into **HTTP, gRPC, or TChannel** requests without requiring code changes to underlying microservices).
- **Cadence-Powered `AutoCrawler`:** An automated crawler built on **Cadence** scans Uber's internal Interface Definition Language (IDL) registries, extracts **Protocol Buffers (Protobuf)** and **Thrift** schemas, generates MCP tool definitions, and uses an LLM to draft tool descriptions—keeping newly discovered tools **disabled by default** until the owning service team reviews and enables them.
- **Incremental Tool Discovery via `Omni MCP`:** Instead of stuffing 5,000 tool schemas into an agent's context window, **Omni MCP** lets agents dynamically search for relevant servers, inspect individual tool schemas on demand, and invoke only what they need.
- **Response Projection & PII Redaction:** To prevent massive JSON payloads from overflowing agent context windows, **Response Projection** allows agents to request only specific fields from an API response, while the gateway automatically redacts **Personally Identifiable Information (PII)** and exchanges internal Uber tokens for third-party **Jira** and **Google** OAuth credentials.
- **Zero-Downtime Propagation & `aifx` CLI:** Registry configuration updates propagate to the data plane instantly without service restarts, and Uber's **`aifx` CLI** lets coding agents write large tool outputs to local files for selective inspection.

## Solving the "Zero-Touch Microservice" Problem: Registry + Proxy Gateway + AutoCrawler

As Microsoft CoreAI Principal Software Engineer Ajay Sharma and Pipe17 President Kelly Goetsch both noted in commentary on Uber's release, the AI engineering world has spent the past year painfully rediscovering why enterprise software invented API gateways two decades ago. Asking 800 backend microservice teams to manually write, deploy, and maintain their own standalone MCP server wrappers creates massive infrastructure duplication.

Uber eliminated that toil by treating MCP as a **protocol translation layer** at the gateway rather than a new server binary every team has to host:

| Architectural Challenge | Naive Point-to-Point MCP Setup | Uber MCP Gateway + Omni MCP Architecture |
|---|---|---|
| **Onboarding Existing APIs** | Every team writes & hosts a custom MCP wrapper | **Cadence `AutoCrawler`** converts Protobuf/Thrift IDLs; **Proxy** translates to HTTP/gRPC/TChannel |
| **Default Security Posture** | Auto-exposed endpoints; inconsistent auth | **Disabled by default** until owner review; server + tool-level RBAC + **PII redaction** |
| **5,000-Tool Context Bloat** | Dumps all tool schemas into system prompt (~100k+ tokens) | **`Omni MCP`** provides incremental search $\\rightarrow$ schema fetch $\\rightarrow$ invocation |
| **Bloated API Payloads** | Returns full 50KB JSON objects into LLM context | **Response Projection** filters fields + **`aifx` CLI** writes large outputs to disk |

Look at how Uber's **AutoCrawler** workflow balances automation with strict human governance:

1. A background **Cadence** workflow continuously scans Uber's internal Protobuf and Thrift IDL repositories whenever backend teams update their microservice APIs.
2. `AutoCrawler` automatically generates an MCP-compatible JSON schema for each endpoint and uses an LLM to write a clear natural-language description explaining when an agent should call the tool.
3. By design, **every newly crawled tool lands in the MCP Registry in a `disabled` state**. An AI agent cannot call a newly generated tool until the engineering team that owns the underlying microservice logs in, verifies the LLM-generated description and permission scope, and flips the enablement toggle—which propagates live to the Proxy Gateway with zero restarts.

## How `Omni MCP` and `Response Projection` Save Millions of Context Tokens

Even after you govern 5,000 tools in a central registry, you face a brutal LLM physics problem: you cannot pass 5,000 JSON tool schemas into an agent's prompt on every turn. Even if each tool schema averages just 150 tokens, 5,000 tools would consume **750,000 tokens** on every single request!

Uber solved this with three practical context-engineering patterns that every agent builder should steal immediately:

1. **Incremental Discovery (`Omni MCP`):** Instead of binding thousands of tools upfront, an agent starts with a lightweight meta-tool (`Omni MCP`). The agent queries `Omni MCP` to search the directory of 800+ servers by keyword or domain, retrieves the full parameter schema *only* for the 2 or 3 specific tools relevant to the user's task, and invokes them on the fly.
2. **Response Projection (GraphQL-Style Field Selection for MCP):** Internal microservice APIs frequently return massive nested JSON objects containing 80 fields when the AI agent only needs `status`, `driver_id`, and `updated_at`. Uber added **Response Projection** to its MCP Gateway so the agent can specify the exact fields it wants returned—slashing tool-response token consumption and preventing sensitive adjacent fields from ever entering the prompt.
3. **File-Backed CLI Inspection (`aifx`):** When a coding agent inside an IDE invokes a tool via Uber's `aifx` command-line interface that genuinely returns a large log or dataset, `aifx` writes the payload to a local file rather than dumping it into stdout/context, allowing the coding agent to `grep` or read specific line ranges selectively.

### The 4-Step Enterprise Implementation Playbook

1. **Put a Protocol-Translating Proxy in Front of Existing gRPC/REST Services:** Stop asking backend teams to build and maintain bespoke MCP server containers. Deploy a central MCP Proxy Gateway that reads your existing OpenAPI, Protobuf, or GraphQL schemas and translates MCP tool calls into standard backend RPCs.
2. **Enforce "Disabled by Default" on Auto-Generated Tool Schemas:** Use an automated crawler to convert your OpenAPI/Protobuf specs into draft MCP tool definitions, but require the owning service team to explicitly review the tool description and approve read vs. write RBAC permissions before exposing it to agents.
3. **Replace Static Tool Lists With Incremental Meta-Search (`Omni MCP` Pattern):** Once your workspace exceeds 25 to 30 MCP tools, stop passing all tool schemas in the initial LLM request. Expose a 3-step meta-tool (`search_tools` $\\rightarrow$ `get_tool_schema` $\\rightarrow$ `invoke_tool`) so agents load schemas dynamically on demand.
4. **Add Field Projection and PII Redaction at the Gateway Egress:** Add an optional `fields` projection parameter to your MCP gateway wrapper so agents only pull the JSON keys they need, and run an automated PII regex/NER scrubber on all gateway responses before they reach the model context.

## Next Steps