u/Pitiful-Surround-285

The default MCP pattern has a quiet cost: the model reads the full schema of every tool on every connected server, every turn, before it even knows which tool it needs.

We stress-tested it with a deliberately oversized tool: 217,316 bytes of schema, roughly 54k tokens at four characters per token, sitting in context just to make one tool callable.

You pay for that three times. It's input tokens on every call (caching softens the bill, not the rest). It's latency, more context to process before the first useful token. And it's context pressure, schema you never use crowding out the task.

The fix was to stop showing the model the catalog at all. It gets exactly two operations: search and execute. It searches with plain-language intent ("create a support ticket"), gets back a few compact cards capped at 1,800 bytes each, and executes one by its action ID. The full schema never enters context. The bridge rebinds it after selection and validates the call server-side against the real thing.

Result on the stress fixture: 217,316 bytes became a 5,062 byte card. 97.7% less, ~54k tokens down to ~1.3k, and execution stayed exact. The model still called the right tool with the right arguments. It just stopped reading the encyclopedia first.

What this does not solve, honestly:

- Discovery adds a step. The model searches before it executes.

- Large tool results still cost context. This compresses schemas, not outputs.

- It's one oversized fixture, not a promise that every catalog saves the same. What it demonstrates is the shape: two fixed operations and a few small cards, no matter how many servers you connect.

You can check your own overhead in two API calls: send the same one-line prompt with your MCP servers connected and with none, and diff the input tokens in the usage fields. That difference is your schema tax.

*We build Orca, an agent runtime, and this bridge is part of it. Happy to go deeper on any of this in the comments, including the tradeoffs.*

If you are curious what agents actually cost to run in production, here's our last week, unedited:

- 61 runs

- 15.4M tokens

- $37.68 total spend

- 189 tool calls

- 27 minutes of sandbox execution

- P95 run duration: 3m 17s

That's about $0.62 a run, roughly 250K tokens per run.

Some things I didn't expect until we had real metering in front of us:

• I assumed compute would be a meaningful chunk of the bill. It isn't. The entire week of sandbox time added up to 27 minutes, which costs pennies. The token line is effectively the whole bill, and all our cost thinking has quietly turned into token thinking.
• The most boring decision turned out to be the most important one: we count spend in millionths of a dollar, as integers. When we reconciled a $5 credit purchase against our payment provider's meter, it matched to the exact micro dollar. I don't think that ever happens with float math on money. The rounding drift just hides until it's real cents.
• We also gave every run a hard budget that kills it at zero. It felt wrong to build something that blocks our own revenue, but a runaway loop is a race between the model and your wallet, and I'd rather lose the run.

Usual caveats: one week, one workload, ours. We build tooling in this space and run our own agents on it, so this is dogfood data. An agent chewing through 200 page PDFs will look nothing like this.

If you're running agents in production, I'd honestly love to know what a run costs you.