Omni MCP
An MCP agent solution developed by Uber that addresses context-window overflow when invoking large numbers of tools. It converts the full loading of 5,000+ tools into a four-step incremental retrieval process via an on-demand loading mechanism, and integrates permission verification and response trimming.
Timeline (last 90 days)
In Uber's system, the registry is the control plane holding the tool catalog, and the gateway is the data plane handling actual invocations.
Every MCP server and tool starts in a disabled state and must be explicitly reviewed and enabled by the responsible team.
Response projection allows an agent to declare which fields it wants before receiving results, and the gateway strips all other fields before the model reads them.
Omni MCP performs permission checks at the gateway layer, where the gateway verifies whether the caller has permission when a tool is actually invoked.
Uber did not clarify whether the tool list itself hides tools the caller has no permission to use, meaning it is not clear whether permission filtering occurs at the listing stage or the execution stage.
Omni MCP uses a Response Projection mechanism, where the agent requests only the fields it needs and the gateway trims away the rest of the response.
Uber proposed an agent solution called Omni MCP, designed to allow AI agents to acquire tools step by step on demand rather than loading all tools at once.
For scenarios with only small servers, introducing a proxy layer adds unnecessary call rounds and complexity, and using the standard tool list is recommended.
When the tool library expands to hundreds or thousands, the pattern of injecting all tools into the context at once breaks down, and hierarchical lazy loading combined with gateway-side trimming is a more sustainable architectural choice.
Uber has not published any real-world data on token savings or latency changes from Omni MCP.
2 more timeline events
All Facts (12)
Omni MCP provides the agent with only four small tools: discover server, list the server's tools, get the schema of a specific tool, and execute a tool.
60%UnverifiedIn Uber's system, the registry is the control plane holding the tool catalog, and the gateway is the data plane handling actual invocations.
50%UnverifiedEvery MCP server and tool starts in a disabled state and must be explicitly reviewed and enabled by the responsible team.
50%UnverifiedResponse projection allows an agent to declare which fields it wants before receiving results, and the gateway strips all other fields before the model reads them.
50%UnverifiedOmni MCP uses a Response Projection mechanism, where the agent requests only the fields it needs and the gateway trims away the rest of the response.
50%UnverifiedUber proposed an agent solution called Omni MCP, designed to allow AI agents to acquire tools step by step on demand rather than loading all tools at once.
50%UnverifiedFor scenarios with only small servers, introducing a proxy layer adds unnecessary call rounds and complexity, and using the standard tool list is recommended.
50%UnverifiedWhen the tool library expands to hundreds or thousands, the pattern of injecting all tools into the context at once breaks down, and hierarchical lazy loading combined with gateway-side trimming is a more sustainable architectural choice.
50%UnverifiedUber has not published any real-world data on token savings or latency changes from Omni MCP.
50%UnverifiedIn the Omni MCP process, only the layer-by-layer unfolded query results enter the model context, enabling on-demand incremental loading rather than one-time full loading.
50%UnverifiedOmni MCP performs permission checks at the gateway layer, where the gateway verifies whether the caller has permission when a tool is actually invoked.
50%UnverifiedUber did not clarify whether the tool list itself hides tools the caller has no permission to use, meaning it is not clear whether permission filtering occurs at the listing stage or the execution stage.
50%