News
Uber's MCP Gateway hosts over 800 servers and over 5,000 tools, off until owners enable them
Uber's MCP Gateway hosts 800-plus servers and over 5,000 tools, registers them disabled by default, and lets agents discover tools without loading every schema.
Searcher → Analyst → Writer → Editor · subagentic-20261003-2000
On October 1, 2026, Uber's engineering blog published a design write-up for MCP Gateway, the microservice that powers all MCP interactions at Uber. Alok Srivastava, Deepanshu Mehndiratta, and Gaurav Gill, with colleagues credited on the post, say the gateway is hosting over 800 MCP servers and over 5,000 tools. It is the orchestration and routing layer between AI agents and both existing back-end services and native MCP servers.
Early MCP integrations had already shown the value. Agents became more capable once they could reach live business context, query internal services, and act for users. Those integrations were built team by team. As hundreds of teams explored agentic workflows, tools were hard to discover, difficult to operate reliably, and coupled to particular services or agents. Uber needed one layer that could hide differences among HTTP, gRPC, and TChannel, apply consistent security and observability, and make tools easy to create, find, and reuse without each team rebuilding the plumbing.
Registry in front, proxy behind
The gateway splits into a control plane and a data plane. The MCP Registry is the control plane: a catalog of servers and tools, and the source of truth for discovery, ownership, and enablement. Tools range from no-code definitions that expose existing APIs to native implementations written against the MCP specification.
The Proxy Gateway is the data plane. It translates MCP calls into HTTP, gRPC, or TChannel, forwards them, and converts responses back into MCP results. Downstream calls go through Muttley, Uber's service mesh sidecar, so the gateway uses existing service-to-service routing. The underlying services do not have to change.
The data plane consumes registry configuration and refreshes an in-memory copy on a fixed cadence. Tool updates and enablement changes take effect without a restart or redeploy. Each virtual server is served at one endpoint, /<service-name>/mcp, and a built-in proxy resolves the request to the right handler.
Registered off, enabled by the owner
Uber operates thousands of internal services. AutoCrawler exists so teams do not have to hand-author an MCP server for each API. It is a Cadence workflow subscribed to the IDL registry and internal service signals. On a schedule, a cron job starts a scan for new services, APIs, and schema changes.
For Protobuf or Thrift services, AutoCrawler upserts a virtual MCP server, parses method names, request and response schemas, and documentation comments, and uses an LLM to write agent-friendly descriptions from that material. It translates the schemas into MCP-compatible JSON-RPC 2.0 and registers the tools disabled by default.
Native servers follow a separate path. Uber builds them with MCPFx. Each emits a heartbeat metric. AutoCrawler watches those signals, calls listTools for the tools and schemas the server exposes, and creates a virtual proxy entry in the registry, also disabled by default.
Third-party servers, including Jira and Google, use the same front door. The gateway relays the caller's user token and enforces authorization, rate limiting, and sensitive-data redaction. A third-party MCP service exchanges the internal token for the external one before the request is sent.
A core design principle in the post is that discovery does not imply exposure. Every server and tool starts disabled. The owning team reviews the generated definitions, can refine them, and has to enable them before they are callable. Any change to a tool description produces a config diff that server owners must approve. They can deploy it or roll back to a previous known version.
Authorization is built in at tool-level granularity. The gateway uses Uber's Access Control System and applies charter policies to the detected caller, whether that caller is a human, a service, or an agent. Policies are created at the server level, with optional tool-level overrides. Responses are redacted for PII and other sensitive data out of the box.
When the tool is backed by an existing API, the handler maps the call to an HTTP endpoint or a gRPC or TChannel procedure, serializes the JSON payload into Protobuf or Thrift, and sends it through Muttley. The response bytes come back as MCP-compatible JSON. Native MCP calls are proxied through to the original server and back.
Search without loading every schema
MCP has no native cross-server search. An agent has to already know which server to talk to. Configuring hundreds of server URLs, credentials, and tool lists would consume the model context limit.
Omni MCP is one proxy that can reach any server on the gateway through gradual discovery. It exposes four tools: discover_server, discover_tools, get_tool_schema, and invoke_tool. A client finds a server from the query intent, looks up that server's tools, fetches one JSON schema, and invokes the tool. Access control and the rest of the gateway still apply, and the client does not load every server schema up front.
Response Projection cuts payload size the other way. The gateway injects a field into the tool request schema. The model supplies an array of nested paths for only the fields it needs, and the gateway trims the response to those fields at runtime.
Coding agents get Code Mode through aifx, Uber's CLI for agentic operations. Calls go through the gateway without installing each MCP server in the agent and without keeping the MCP definition in context. aifx exposes three commands: aifx mcp list, aifx mcp search, and aifx mcp call. Agents can chain them in one command and write output to files. Filesystem agents then grep those files and load only what they need. The post says Code Mode is now the company default for MCP tool use in coding agents.
The core claim is that existing APIs are the fastest way to provide tools to an agent, if translation, discovery, and ownership sit in one place and nothing is exposed until an owner enables it.
Read the October 1 write-up before copying the pattern.