Did Uber Just Fix MCP's Biggest Problem?

0:00 An agent with 5,000 tools can fill its context before it reads your task. Uber reports more than 5,000 MCP tools on more than 800 servers, and its agents don't load that list. The context is the

0:12 text the model can read at one time. Uber says that configuring hundreds of servers by hand would fill it. MCP is the standard way an AI agent calls a tool, so you can meet the same limit.

0:22 So, what does the agent load instead? MCP has no cross-server search, Uber writes. An agent has to already know which server to talk to before it can ask what tools are available. The

0:33 standard flow adds a second cost. In the 25th of November 2025 version of the spec, the client lists the tools, the model picks one, and the client calls it. Each listed definition has a name, a

0:44 description, and an input schema, which is a short description of the fields the tool accepts. So, the list step puts every definition in the context, and at Uber scale, that means thousands. Uber's

0:55 answer is Omni MCP. It's one proxy server that stands between the agent and the other servers, and it exposes four metatools. A metatool is a tool for finding and calling other tools. The

1:06 agent uses them in sequence. Only what the agent asks for enters the context. So, the agent never sees the full list of definitions. Omni MCP has four tools: discover server, discover tools, get

1:19 tool schema, and invoke tool. In order, they find a server by intent, list that server's tools, fetch one tool's JSON schema, and invoke the tool. That schema is the same input schema the spec

1:30 describes. Together, the four tools make the choice smaller at each step. Now for the imaginary request. Uber describes the four tools as a sequence. The server, tool, and field names below are

1:41 made up. Suppose an agent must find the status of one delivery order. Step one is discover server. The agent sends a query that states its intent, such as checking an order status. The

1:52 tool returns a matching server, so the agent knows where to look. The agent doesn't need to name a server. That solves the earlier problem where the agent had to know the server first. One

2:02 result is a simplification in this example. The post doesn't explain how discover server ranks servers. It could match keywords or it could compare meanings with a model. That choice

2:12 changes how well step one works. Step two is discover tools. The agent names the server from step one. The tool returns that server's tools. The reply probably includes a short description

2:23 for each tool because the agent has to choose one. Descriptions matter because the agent has to choose a tool. Uber has a large language model or LLM write agent-friendly descriptions for the

2:34 tools it finds. I'll show where that happens in a moment. A poor description could send the agent to the wrong tool. So, the quality of the text is part of the design. Step three is get tool

2:43 schema. The agent chooses one tool and asks for its JSON schema. A standard MCP definition carries the same input description, but now the agent loads one schema instead of thousands. The agent

2:55 doesn't guess the fields. It reads them from the schema before it sends the call. Step four is invoke tool. The agent fills in the arguments that the schema describes and sends the call. The

3:05 call goes to the service that owns the tool. The result comes back to the agent. This step doesn't need the rest of the catalog. Count what entered the context. The agent holds one server, one

3:15 list of that server's tools, one schema, and one result. The rest of the 5,000+ tools stayed outside. The context holds only what this one task needs. Each step also reduces the number of

3:28 choices. First, the agent picks a server, then one of that server's tools, then it fills in the arguments. That's my reading of the design, not Uber's wording. You can use it to check any

3:38 design of this kind. Ask whether each step leaves fewer choices for the next step. Uber's system has two other parts that matter here. The registry is the control plane and it holds the tool

3:48 catalog. The gateway is the data plane and it handles the calls. The registry records which tools exist, the gateway passes the calls on. The post doesn't spell out how these two parts relate to

3:59 OmniMCP. The gateway turns an MCP call into one of three protocols: HTTP, gRPC, or T-channel. Then it hands execution to Mutley. The post calls Mutley a service mesh sidecar, which is a helper process

4:12 that runs next to a service. So, the agent sends MCP calls, and the gateway sends calls in those protocols to the services. The catalog gets in two ways. Native MCP servers are queried with list

4:24 tools. For other services, a tool called autocrawler reads the interface definition files written in protobuff or thrift. Both paths fill the catalog of tools.

4:34 Autocrawler has an LLM write agent-friendly descriptions for the tools it finds. Then it registers every tool, and every tool starts disabled. Uber puts it this way: Every MCP server

4:45 and tool starts in a disabled state and must be explicitly reviewed and enabled by the owning team. For the descriptions, the post names owner review and no other check. So, a machine

4:56 writes the text first, and a person decides after that. This review is separate from the permission checks. Now, the permission question. Uber says the gateway uses its internal access

5:05 control system to apply what it calls charter policies. The post doesn't define the term, but from context, they look like the access rules. The rules are set per server, and a single tool

5:15 can have its own override. The policy also depends on the caller. The gateway detects whether the caller is a human, a service, or an agent. So, the same tool can have different rules for each kind

5:25 of caller. One rule for all three callers would not fit every case. The post says authorization and redaction of personal data, called PII, apply per tool. A rule can cover one tool, not

5:38 only a whole server. Redaction means hiding personal data. When does the check happen? The post says the gateway enforces permissions on the request path. That is the path a call takes from

5:48 the agent to the service. The post doesn't say whether discovery or the schema fetch also checks permissions. So, the exact step in the Omni flow isn't stated. The post also doesn't say

5:58 whether discover tools filters by caller permissions or by whether a tool is enabled. If you build this, I'd filter on both. Then the agent can't choose a tool it can't call. Discovery reduces

6:09 what goes into the context before the call. Results are a second problem. A single large result can still fill the context after the call. Uber has two answers. The first is response

6:19 projection. The agent requests only the fields it needs, and the gateway trims the response at runtime. So, the agent states which fields it wants before the answer arrives.

6:28 In our imaginary request, the agent asks for the status field. It doesn't ask for the whole order record. The gateway removes the other fields before the model reads the response. The post

6:38 doesn't show where the agent states the fields. The second answer is code mode for shell agents. Shell agents work through a terminal. They call MCP tools through a command line tool named AIFX.

6:51 Its commands are list, search, and call under the MCP command. The agent chains several calls in one command. The agent writes the output to files. Then the agent searches those files with grep, a

7:02 text search tool, and loads only what it needs into the context. So, the long output stays on disk, and the model reads a small part. Suppose a call returns a long list of orders. The

7:12 output goes to a file, and grep finds the one order the agent wants. Only that order enters the context. The file keeps the full result, and the context keeps only the match. One limit matters here.

7:23 Uber describes files only for code mode. The post doesn't say how Omni MCP handles oversize results. It could cut them, cap their size, or write them to a file. So, how much does this save? Uber

7:35 published no measured token savings, no latency numbers, and no percentage. Any figure for Uber saving would be a guess. So, this video gives none. Anthropic gives one number for a similar idea. On

7:46 the 4th of November 2025, it described loading tool definitions on demand and filtering results in code before the model sees them. It's worked example cut 150,000 tokens to 2,000, a 98.7%

8:00 saving. That figure is a different system's example. It isn't a measurement of Uber's gateway. It shows what one example reached, and it says nothing about Uber's results.

8:09 The loop is find, list, fetch, and call. The gateway enforces permissions on the request path. Projection and files keep large results out of the context. If you run many MCP servers, try this design.

8:21 First, measure your tool list. If you run one server with a few tools, keep the standard list because four steps mean more calls. That extra cost is my inference, not Uber's claim. Before you

8:32 build it, make three choices. Decide whether discovery hides tools the caller can't use. Decide which step enforces permissions. Decide how your gateway handles oversized results. How many

8:42 tokens does your own tool list use before the first task starts? Count them. Then compare that number with your model's context size. That tells you how much room a design

8:51 like Uber's could give back to the task.