TL;DR — Key Takeaways
1. Uber’s MCP Gateway demonstrates governance at enterprise scale. Its architecture manages more than 800 MCP servers and 5,000 tools through a centralized registry, proxy gateway, ownership tracking and tool-level authorization.
2. The most valuable lessons don’t require Uber’s infrastructure. Platform teams managing just 10 or 50 MCP servers can improve security by maintaining a tool registry, assigning ownership, disabling new tools by default and requiring approval before exposure.
3. Efficient discovery matters more than offering every tool at once. Gradual tool discovery, response filtering and repeatable CLI workflows can reduce context consumption, simplify automation and make MCP environments easier to operate securely.
Uber published the design of its MCP Gateway earlier this month: A single control plane and proxy layer that now fronts more than 800 MCP servers and 5,000 tools across the company.
The numbers are the part that travels, but they are not the part worth copying. The part worth copying is the governance model underneath them: a registry that tracks ownership, tools that start disabled until an owner enables them, and authorization enforced at the level of individual tools.
Most platform teams will never run 800 MCP servers. Many will run ten, or fifty, or a hundred. The question is what survives the trip down from Uber’s scale to everyone else’s. Some of it does. Some of it breaks. And the parts that break are instructive in their own way.
What Uber Actually Built
The gateway has two halves. The MCP Registry is the control plane: a catalog of every server and tool, and the source of truth for discovery, ownership, and enablement. The Proxy Gateway is the data plane: it translates MCP calls into HTTP, gRPC, or TChannel through Uber’s service mesh sidecar, so the underlying services never have to change.
Getting 5,000 tools into that registry by hand would have been hopeless, so Uber built AutoCrawler, a scheduled workflow that watches the company’s interface definition registry. For Protobuf or Thrift services it generates a virtual MCP server, parses method names and schemas, uses a language model to write agent-friendly descriptions, and registers the tools disabled by default. Native servers get proxied in through heartbeat signals. Third-party tools like Jira and Google come through the same front door, with user tokens, rate limits, and sensitive-data redaction.
Then comes the part that matters most: discovery does not imply exposure. Every generated tool starts disabled. The owning team reviews the description, refines it, and enables it. Any change to a tool description produces a config diff the owner has to approve, with the option to roll back. Authorization runs through Uber’s access control system down to individual tools, and responses are redacted for personal data by default.
For actually calling tools, Uber added three mechanisms to keep context windows under control. Omni MCP is a single proxy exposing four tools (discover server, discover tools, get schema, invoke) so an agent finds what it needs gradually instead of loading hundreds of schemas up front. Response Projection lets the model request only the fields it needs and trims the rest at runtime. And Code Mode, through Uber’s aifx CLI, lets coding agents chain list, search, and call in one command and write results to files. Code Mode is now the company default.
The Governance Model is the Portable Part
Strip away the scale and the core claim is simple: existing APIs are the fastest way to give agents tools, as long as translation, discovery, and ownership live in one place, and nothing is exposed until an owner enables it.
That sentence works at any size. A registry does not have to be a distributed control plane; it can start as a documented list of which tools exist, who owns each one, and whether it is enabled. The default-deny posture does not require Uber’s access control system; it requires the discipline to treat every new tool as off until someone takes responsibility for it. Owner approval on description changes is just change review, the same muscle teams already use for infrastructure code.
This is also where most teams get it backwards. The instinct is to wire up as many tools as possible and sort out governance later. Uber’s experience suggests the order runs the other way: The registry and the ownership model come first, and they are what make the tool count sustainable. Five thousand tools are manageable when each one has an owner and an enablement state. Fifty tools with no owners are a liability.
Where the Auto-Generation Breaks Down
AutoCrawler is the least portable piece of the design, and it is worth understanding why. It exists to solve a problem most teams do not have: thousands of internal services that would each need a hand-written MCP server. For a team with dozens of tools, the economics invert. Hand-authoring a few dozen tool definitions is a week of work. Reviewing a few dozen machine-generated ones, each needing an owner to verify the description, the schema mapping, and the safety properties, can easily cost more.
Generated descriptions have a specific failure mode. A language model writing from an interface definition can describe what a method does, but it cannot know the operational context: which parameters are safe to guess, which calls are irreversible, what the blast radius is when the agent gets it wrong. My own Terraform MCP setup generates infrastructure code from natural language, and the useful part of the output is not the generated module. It is the warnings: flagging a single NAT gateway as a single point of failure, catching drift between the plan and the desired state. That judgment comes from encoding operational knowledge into the tool, not from parsing a schema.
There is also a quieter risk in the heartbeat model. Proxying native servers based on liveness signals assumes those servers describe themselves accurately. A tool that misreports its schema or silently changes behavior will be discovered and invoked by agents that trust the registry. At Uber’s scale, that is a monitoring problem. At a smaller team’s scale, it is a reason to keep the registry small enough that a human has actually read every entry.
What This Means at 10 or 100 Tools
So what should a platform team running a handful of MCP servers take from all this? Four things, roughly in order.
First, keep a registry, even a boring one. A page that lists each server, its tools, the owning team, and whether it is enabled will prevent most of the confusion that Uber built a control plane to solve. When I set up MCP servers for Terraform, Kubernetes, Grafana, AWS, Alertmanager, and GitLab, the useful artifact was not any single server. It was the map of all of them: Which systems the agent could touch, and through which tools.
Second, default to disabled. Every new tool should start off disabled, and enabling it should be a deliberate act by the owner. This costs nothing to implement and it is the single cheapest safety control in the whole design. The Alertmanager server in my setup, for example, can silence alerts during a deployment window. That is exactly the kind of tool you want gated behind an explicit enablement decision, with critical alerts excluded by policy rather than by hope.
Third, borrow the discovery pattern. Agents do not need every tool schema in context. The gradual approach- find the server, look up its tools, fetch one schema, invoke- works just as well with ten servers as with eight hundred, and it keeps prompts small and predictable. The same goes for trimming responses to the fields the model actually needs.
Fourth, prefer CLIs over chat for repeatable operations. Uber’s Code Mode exists because conversational tool use does not scale to routine work. A Kubernetes debugging session that starts with “why is the checkout-service pod crashing” is a good chat interaction the first time. The fiftieth time, it should be a command. Build the MCP server, then wrap the common paths in scripts. None of this requires a gateway. It requires treating the tool surface like infrastructure: owned, reviewed, versioned, and off by default.
The Pattern, not the Platform
Uber’s post ends with advice worth repeating: read the write-up before copying the pattern. The pattern is not the proxy or the crawler. The pattern is one place where translation, discovery, and ownership live together, and a rule that nothing is exposed until an owner enables it.
Teams running ten MCP servers do not need Uber’s architecture. They need Uber’s discipline, applied at a scale where a human can still hold the whole registry in their head. That is, if anything, a stricter standard than the one a gateway enforces. A control plane can track 5,000 tools. A team can only vouch for the ones it has actually read. Page 3/3