Uber has built an MCP Gateway to bring order to a rapidly expanding internal AI agent ecosystem, standardizing how agents discover and invoke services across more than 800 MCP servers and 5,000 tools. The system is designed to reduce duplicated integrations, centralize governance, and enforce security controls as agent adoption scales inside the company.
Why Uber built an MCP Gateway
As AI agents become more common in internal workflows, Uber says the fragmentation problem starts to look familiar: teams build overlapping connectors, security practices vary, and every new integration can add another layer of complexity. The company’s answer is an MCP Gateway that exposes existing APIs as MCP tools without requiring changes to the underlying services.
Uber describes the platform as a microservice architecture for agent access, with a common layer for discovery, protocol translation, authorization, and execution. In practical terms, the gateway helps agents find the right service, understand its schema, call it through the proper interface, and receive results in a form that MCP-compatible systems can use.
How the Uber MCP Gateway is structured
The architecture splits responsibilities between two main components. The MCP Registry serves as the control plane, while the Proxy Gateway handles runtime execution.
The registry maintains tool definitions, schemas, ownership metadata, and enablement settings. The proxy then translates MCP requests into the protocols Uber already uses internally, including HTTP, gRPC, and TChannel, before converting responses back into MCP-compatible results.
- MCP Registry: stores tool metadata, schemas, ownership, and enablement state
- Proxy Gateway: executes requests and translates between MCP and internal service protocols
- Common control layer: supports discovery, governance, authorization, and runtime execution
Uber’s approach reflects a broader pattern many teams will recognize from earlier generations of API infrastructure. The company is effectively applying the gateway model to agent tooling, rather than treating each AI integration as a bespoke case.
Discovery at scale with AutoCrawler
One of the harder problems in a large enterprise environment is keeping track of what tools exist in the first place. Uber’s AutoCrawler is designed to automate that discovery process using Cadence.
According to the company, AutoCrawler scans internal interface definition language registries and extracts API definitions from Protocol Buffers and Thrift schemas. It then generates MCP-compatible schemas and uses a large language model to produce tool descriptions. That helps populate the catalog without requiring teams to manually register every tool by hand.
Importantly, newly discovered tools do not go live automatically. They remain disabled until the owning teams review them and explicitly enable them. Uber also says configuration changes propagate to the data plane without requiring service restarts or redeployments, which reduces operational friction when the catalog changes.
Security and governance remain central
Uber’s design makes it clear that agent access is not just an indexing problem; it is also a governance problem. The gateway enforces authorization at both the server and tool levels through Uber’s internal access control system.
The platform also supports redaction of personally identifiable information and other sensitive data in tool responses. That matters because agent workflows often move quickly across services, and a response that is harmless in one context may expose too much data in another.
For third-party services such as Jira and Google, Uber uses a separate service to exchange internal user tokens for the corresponding external authentication tokens. That arrangement allows the company to keep internal identity handling aligned with outside provider requirements.
Omni MCP helps agents work with large catalogs
At Uber’s scale, simply loading every tool definition into an agent’s context would be inefficient. The company says that as the tool catalog grows, agents need a more selective way to discover and use what they need.
To address that, Uber developed Omni MCP, which supports incremental discovery. Instead of forcing an agent to ingest thousands of tools at once, Omni MCP lets it search for servers, discover relevant tools, retrieve individual schemas, and invoke selected tools only when needed.
Uber also introduced Response Projection, which allows agents to request specific response fields instead of receiving entire payloads. That can reduce unnecessary data transfer and help keep outputs focused on the information the agent actually needs.
What this means for coding agents
Uber says its aifx command-line interface extends the same ideas to coding agents. The CLI can discover and invoke tools and then write results to files for selective inspection. That gives developers a way to work with agent outputs without having to process every response inline.
This is a small detail, but it reflects a larger design goal: make access to internal services usable for automated systems while still preserving control over what gets surfaced and when.
Why the design is drawing comparisons to API gateways
Uber’s MCP Gateway has already drawn comparisons to long-established API gateway patterns. The core idea is straightforward: centralize discovery, policy, routing, and governance rather than distributing those responsibilities across every client.
Ajay Sharma, Principal Software Engineer at Microsoft CoreAI, said in a LinkedIn post that “Azure API Gateways has been doing this for a while now. It’s a recipe for order to the chaos that LLMs come with.”
Kelly Goetsch, President at Pipe17, made a similar point, writing that “Uber’s new MCP gateway looks identical to gateways we’ve built over the decades for APIs and later GraphQL.” Tamir Dresher also highlighted the continuing relevance of distributed systems concerns such as security, discovery, observability, and governance.
What stands out in Uber’s approach
Uber’s announcement is notable not because it introduces a brand-new category, but because it shows how familiar infrastructure patterns are being adapted for AI agents. The company is using a gateway, registry, discovery automation, token exchange, and selective response shaping to manage a much larger and more dynamic tool surface.
That matters because agent systems tend to multiply quickly. Without a common governance layer, teams can end up with inconsistent authorization, duplicated connectors, and fragile manual onboarding. Uber’s implementation is an attempt to keep that complexity manageable as use grows.
- More than 800 MCP servers are supported
- More than 5,000 tools are available through the platform
- New tools stay disabled until owners explicitly approve them
- Runtime execution can translate MCP requests into HTTP, gRPC, or TChannel
- Response redaction and token exchange are built into the access flow
A sign of where enterprise agent infrastructure is heading
Uber’s work suggests that the next stage of enterprise AI infrastructure may look less like isolated prompt applications and more like formal service platforms. As agents gain access to internal systems, organizations will likely need the same kinds of control planes they built for APIs, only with additional concerns specific to model-driven behavior.
That includes incremental discovery, schema management, access control, data minimization, and operational visibility. Uber’s MCP Gateway does not remove those challenges, but it does provide a structured way to manage them at scale.
Source: Original report
Was this helpful?
Explore more: Software Development More Software Development Tech News
Last Modified: November 2, 2026 at 10:33 pm
0 views
