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.
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 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
Bloated API Payloads Returns full 50KB JSON objects into LLM context
Response Projection filters fields + aifx CLI
Look at how Uber’s AutoCrawler workflow balances automation with strict human governance:
A background Cadence workflow continuously scans Uber’s internal Protobuf and Thrift IDL repositories whenever backend teams update their microservice APIs.
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.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:
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.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.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
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.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.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.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
