# 1,000 MCP servers, zero schema bloat? Lessons from Uber's attack on AI costs

> Source: <https://www.thestack.technology/1-000-mcp-servers-zero-schema-bloat-ubers-assault-on-ai-costs/>
> Published: 2026-09-16 13:07:11+00:00

Uber is now running over 1,000 MCP server interactions through a single unified gate for central policy enforcement – and has shared some important lessons from its approach including how the company dramatically drove down its generative AI costs.

Uber shared its approach in an engineering [blog](https://www.uber.com/gb/en/blog/efficient-software-factory/?ref=thestack.technology) that comes after the company’s CTO Praveen Naga hit the headlines earlier this year for saying the company had “burned” through its annual AI budget in months. In a series of posts Naga has since shared how Uber attacked each “underlying lever” to cut its AI costs. These include: 

- Scaling vendor-neutral managed agents
- Optimising prompt caching
- Making tool and MCP usage more efficient
- Building efficient, reusable agent skills
- Giving engineers real-time cost visibility

It is its work on MCP servers and reducing schema overhead that stood out to The Stack in a recent blog by the rideshare firm’s Distinguished Engineer Uday Medisetty.

In it, he flagged how weekly active users of its AI coding tools rose 7x and weekly agent requests climbed 9.4x between February and August 2026 while Uber kept total spend roughly flat since April. Isolating optimisation efforts, Uber cut cost per 1,000 requests by an impressive ~34% and cost per session by ~52% from its peak.

### See also: [**__Nike cuts tech roles, continues IT efficiency drive after Finops wins__**](https://www.thestack.technology/nike-tech-layoffs/)

__Nike cuts tech roles, continues IT efficiency drive after Finops wins__
Uber directs "helper" tasks to smaller models by default; only the tasks needing top-tier reasoning get expensive models. An internal benchmark process sees it runs frontier and open-weight models alike across different task types and use the outputs to “inform model selection across all our SDLC-managed agents” – an approach that the likes of Databricks, Dutch neobank bunq and many others have also adopted.

Notably, his blog shows how much tool access architecture is itself a cost lever.

Connecting more agents (Uber has agents doing “code review, self-healing CI failures, completing E2E PRs with visual validation, triaging on-call alerts, debugging incoming bugs, and handling a variety of code maintenance tasks”) to more SaaS MCP servers has a real, compounding token cost that shows up on every turn of every session.

One challenge stood out:

“Managing third-party software proved significantly more challenging than our internal servers. Vendors design MCP servers to expose full product capabilities because they can't anticipate specific customer usage.”

As the Uber engineer flagged, one workspace suite “bundles 49 tools into a single server, requiring ~22K tokens of schema, while messaging and project tracking vendors ship 34 and 46 tools, respectively,” he said. Agents end up carrying “more schema overhead than the file being edited before a user even enters a prompt.”

With just over 100 tools installed, schema overhead alone added roughly 50,000–70,000 tokens to the *initial* prompt, before any work happened, Uber said. And because every turn in a conversation ultimately re-sends the full history, that overhead wasn't paid once; it was paid again on every single turn of the session.

### See also: [Uber plans to refactor Cassandra, MySQL, Redis workloads for Arm](https://www.thestack.technology/uber-plans-to-refactor-cassandra-mysql-redis-workloads-for-arm/)

Uber took three primary routes to attacking this issue.

1. CLI tool resolution: Instead of loading tool definitions into the model's context, the model is given the ability to run a shell command. The command resolves and invokes the right tool against the gateway *at the moment it's needed*, so the schema never has to sit in context at all. All 1,000+ gateway tools are exposed this way.

2. Tool search; For cases where CLI resolution isn't the pattern, the model can search a catalog of available tools and pull in only the definitions relevant to that specific task, on demand, rather than everything being pre-loaded, he explained. This scales because the overhead doesn't grow with the size of the total tool library.

3. Code-mode (batching): Under vanilla MCP, each tool action is its own round trip: Code-mode instead lets the model write a small script that runs the whole sequence in a subprocess, with only the final summary returned to the model.

These three mechanisms reportedly have helped Uber bring its per-session tool-schema overhead from that 50K–70K-token baseline down to near-zero, applied across internal systems and third-party SaaS tools routed through the same gateway.

Uber also built ~25 pre-packaged "code-mode skills" for their most-used tools so this efficient pattern is the *default* path, not something engineers have to opt into. 

Uber is explicit that the savings are internal to their codebase, team size, and workflows; the *numbers* won't transfer directly, but the *methodology* (benchmark real work, decompose cost, re-optimise continuously) is designed to.

### **The Big Interview:** [**Ron van Kemanade, Group COO, Lloyds, on tackling COBOL with AI, rethinking the org.**](https://www.thestack.technology/ron-van-kemanade-group-coo-lloyds-on-pivoting-to-agents-eying-200-cobol-applications/)

**Ron van Kemanade, Group COO, Lloyds, on tackling COBOL with AI, rethinking the org.**
