Uber's engineering team has published one of the clearest production examples yet of what happens when Model Context Protocol moves beyond a handful of developer tools and into a company with thousands of services.
Why an MCP gateway becomes necessary
A small agent project can connect directly to several MCP servers. At enterprise scale, that model becomes difficult to operate. Uber has thousands of internal services exposing HTTP, gRPC and TChannel APIs. Requiring every team to build and maintain a dedicated MCP server would duplicate work. Uber separates three responsibilities: a proxy layer that translates MCP requests to existing service protocols, a discovery layer with an MCP registry, and a control plane for authoring and management.
A gateway centralizes translation, not ownership
Consider an organization with existing inventory, billing, and customer services. An agent-facing gateway can expose a consistent tool surface without requiring each service to adopt the same transport. Uber's engineering account describes a gateway architecture for its service environment. The transferable lesson is separation of responsibilities: translate the request, discover the available capability, and apply policy. A gateway should not become the place where every business rule is reimplemented, because that creates a second version of the service contract.
For a hypothetical inventory lookup, the gateway accepts a typed tool request, checks its caller and scope, maps it to the existing service operation, and returns a bounded result. The inventory service still owns stock semantics and data access rules. Keep versioned schemas between the agent-facing tool and the backend so that a change to the backend response does not silently break the agent contract. Document which layer is responsible for validation failures, timeouts, and domain errors; otherwise a simple unsuccessful lookup turns into a difficult cross-team incident.
AutoCrawler changes the problem
Uber says AutoCrawler continuously scans its IDL registry, translates APIs into tools and updates the MCP registry. It can also discover native MCP servers. This changes MCP adoption from manual server authoring into a discovery and translation problem. Conceptually: existing API or IDL → crawler → tool metadata → MCP registry → gateway → agent.
Gateway vs direct MCP
Direct connections remain appropriate for small deployments. A gateway starts to earn its complexity when there are many services, multiple agent clients, centralized policy requirements, tool discovery needs or existing APIs that should be reused rather than rewritten.
What smaller teams should copy
Keep a tool registry
Store tool name, description, schema, owner, authentication requirements, risk level and upstream endpoint.
Translate existing APIs before building new servers
If a product already has clean OpenAPI specifications, an adapter can be cheaper than a second implementation. Related AiFolder reading: OpenAPI to SDK, CLI and MCP.
Put policy at the gateway
An agent should not receive every tool merely because it exists. A gateway is a natural place for identity, allowlists, rate limits and audit logs. Related AiFolder reading: AI Agent Permissions Explained.
Treat tool descriptions as production interfaces
Tool selection depends on names, descriptions and schemas. They need versioning and quality checks like normal APIs.
Make discovery a controlled catalog
An agent cannot use a capability it cannot discover, but exposing every operation creates an overwhelming and potentially dangerous tool list. A catalog should describe purpose, required inputs, expected outputs, owner, and allowed caller roles. Read operations and writes should be visibly different. A refund tool, for example, should not be indistinguishable from a transaction lookup just because both take an order identifier. Narrow tool descriptions also reduce the chance that the model selects a similar-looking operation with a very different effect.
Treat the catalog as governed operational data. A service team should be able to deprecate a tool, update a schema, and identify the clients still using it. Avoid passing downstream credentials through the gateway without the intended identity checks; the MCP security guidance explains why token audience and scope matter. Shared translation can reduce duplication, but it also concentrates responsibility. The gateway needs useful audit records and rate controls so an agent's repeated call loop does not overwhelm a backend service that was designed for ordinary application traffic.
Registry vs gateway
A registry answers what tools exist and how they can be discovered. A gateway controls how a request reaches the right tool. An MCP server exposes the actual MCP interface. Large systems may need all three.
A lean architecture
A smaller platform can use: Agent → MCP Gateway → auth and policy → registry lookup → adapter → service. Add observability around tool name, caller identity, latency, error class and policy decision, while avoiding sensitive arguments in logs.
AiFolder test plan
AiFolder can expose the same small API through a native MCP server and an API-to-MCP gateway, then compare setup effort, schema fidelity, tool-selection reliability, latency and maintenance burden. Test status: pending. No AiFolder benchmark result is claimed here.
Practical takeaway
Uber's design shows that production MCP is becoming platform engineering for discovery, translation and governance, not just individual tool wrappers.
Source
Uber Engineering, Designing MCP Gateway, published October 1, 2026.
Design for failure at each boundary
If the billing service times out, the gateway should not report that no invoice exists. If authorization fails, it should not retry under a broader identity. If a downstream response exceeds the allowed size, it should provide an explicit bounded failure or documented pagination. These distinctions matter because an agent may reason from the result it receives. A misleading empty success can produce a confidently wrong plan even when every component technically remained online.
Trace a request across the gateway and backend with a shared identifier while keeping sensitive payloads out of routine logs. Test one successful call, one permission denial, one schema mismatch, and one backend timeout before expanding the tool catalog. Start with a small set of useful read operations and add writes with clear owner approval and recovery behavior. We are analyzing Uber's published architecture, not claiming to have benchmarked its infrastructure or reproduced its internal scale. The diagrams illustrate these transferable boundaries in a smaller hypothetical organization. Keep catalog owners reachable when a contract changes.
