AI NewsInfrastructureAnnouncement

Uber built an MCP Gateway over 800 servers and 5,000 agent tools

Uber built an MCP Gateway that lets AI agents reach 800 internal servers and 5,000 tools. It separates a registry from the runtime proxy.

AI News

Editorial2 min read

LinkedInX
Uber Engineering social card for the MCP Gateway blog post

Image: Uber

Why it mattersA team building an agent that reaches many internal services can read what Uber built. The gateway is a known pattern applied to MCP.

An AI agent that calls a company system has to find the right one. It needs to know what to send, and it needs permission to run it. Uber Engineering just described how it does this at scale. One agent can reach 800 MCP servers and 5,000 tools. The design is an MCP Gateway: a registry on one side, a proxy on the other.

The registry is the control plane. It holds every tool's schema, its owner, and whether a given agent is allowed to use it. The proxy handles each request at runtime. It takes the MCP call and turns it into HTTP, gRPC or TChannel. It hits the actual service. It sends the result back as an MCP response. Uber says the services do not change. Their existing APIs become tools without a rewrite.

How tools get discovered

A new tool shows up through a job called AutoCrawler. It runs on Cadence, scans Uber's interface definition language registries, and reads API shapes from Protocol Buffers and Thrift. It then produces an MCP schema for each one. A language model writes the tool's human description. The tool stays off until the owning team opens it. Settings changes do not need a restart.

Access control sits at two levels. A caller is checked at the server, then at each tool it tries to call. Sensitive fields in responses can be redacted, including personally identifiable information. Outside systems such as Jira and Google need their own tokens. A separate service swaps the internal user token for the matching third-party token.

Omni MCP and Response Projection

A big catalog hits a different wall. A big catalog is heavy for an agent to carry. Loading 5,000 schemas on every call runs the context out of room. It also spends more on tokens than on reasoning. Uber built Omni MCP for this. The agent searches for a server. It pulls the tools it needs. It retrieves just those schemas. Then it calls one. Response Projection lets the agent ask for the fields it wants instead of the full payload. Uber also built a command-line tool called aifx. Coding agents use it to browse tools. Results are written to a file for later review.

The API-gateway comparison

Several engineers pointed out that the design looks familiar. Kelly Goetsch is president at Pipe17. He wrote on LinkedIn that Uber's design looks the same as the gateways teams built for APIs and GraphQL. Ajay Sharma, principal software engineer at Microsoft CoreAI, said Azure API Gateways have been doing this for a while. Uber's post agrees with the comparison. The piece worth copying for a team doing this inside its own estate is the loading pattern. Never put the full catalog in a prompt. Never give an agent a schema it will not use on this call.

Source

Designing MCP Gateway: Uber's MCP Management Platform, Uber Engineering.

Reporting: Uber Builds MCP Gateway to Govern Access to 800+ Servers and 5,000+ AI Agent Tools, InfoQ, by Leela Kumili.

This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.

Share
LinkedInX
Start a project