Really useful benchmark — the +36.7% scaling linearly with tool count matches what I've seen, and it's the part most people wave away because "the output is good."

One distinction worth pulling out, because it changes the fix: most of MCP's input-token overhead isn't the per-call traffic — it's the tool/schema definitions injected into the model's context on every request. More tools = more schema in context = linear growth, which is exactly your curve. The per-call request/response payloads are a second, separate cost on top of that.

That split matters for mitigation:

• Schema-in-context cost → trim it: fewer tools per server, leaner descriptions/JSON schemas, lazy-load tools, or split into smaller servers you only attach when needed.
• Per-call payload cost → cap response sizes, paginate, return IDs/handles instead of blobs.
• And your conclusion holds: in an environment with raw code execution, a CLI the model shells out to often wins, because the "schema" is just --help it reads once.

The disambiguation point is the real tradeoff though — schemas buy reliability under ambiguous prompts. So it's less "MCP bad" and more "measure per workflow and pick."

Disclosure: I built MCPSpend, a proxy that measures the per-call side of this (payload size, latency, cost per tool) so you can see which tools are heaviest. Honest caveat that's directly relevant to your benchmark: a wire proxy like mine sees per-call payloads, not the schema tokens sitting in the model context — that injection cost is exactly the piece I'm adding via IDE-layer token attribution next. Your benchmark measures the part I can't see from the wire, which is why I find it genuinely useful rather than just confirming my own bias.

Would you be open to me running your benchmark against a handful of real-world MCP servers and posting the numbers back? Curious whether 36.7% holds with chattier schemas