Why does MCP cost grow faster than the number of people using it?

Because the cost is a product, not a sum. Every seat carries the same standing overhead — each connector's tool definitions sit in the context of every call — and every seat makes its own verbose read calls. Multiply the per-call waste by the number of connectors, then by the number of people, then by how often each one runs a query, and the bill climbs on three axes at once rather than one.

Is the cost only about people, or do agents make it worse?

Agents make it steeper. A person runs a handful of connector calls an hour; an automated agent or a scheduled workflow can run many more, unattended. When a team points fleets of agents at the same connectors, the multiplier stops tracking headcount and starts tracking call volume, which grows much faster.

Can we keep our connectors and still cut the team-scale bill?

Yes. The expensive part is the standing overhead and the verbose payloads repeated across every seat and every call, not the connectors themselves. Route the calls through one lean layer that serves the same connectors and trims each response, and you cut the per-call waste everywhere it's being multiplied, without changing your connectors or their permissions.

Does Stash Lite store our data to reduce this cost?

No. Stash Lite is a transit layer, not a cache. It serves the connectors you already use, reshapes each response as it passes through, and retains nothing. The data passes through to the AI; it does not live in Stash Lite.

Why running many MCP servers gets expensive at team scale

Why does MCP cost grow faster than headcount?

At one desk, MCP cost is invisible. The trouble is that nothing about the per-call waste is shared across a team — every seat pays it in full, independently.

Two costs repeat on every single call:

Standing overhead. Each connector puts its tool definitions into the context of every call. Ten connectors means that baseline context rides along on every turn, for every user.
Payload bloat. Each read returns the full record — body, metadata, nested fields, audit blocks — even when the answer used two fields. We took one such response apart in a field-by-field teardown.

Neither is a fault in any single connector. It's what happens when several general-purpose tools share one context, and then that context is duplicated across everyone on the team.

The standing overhead every seat pays

Think of the tool definitions as a tax you pay before the model has answered anything. On a solo account it's a rounding error. Across a team it's the same fixed cost, charged once per seat per call, whether or not that call even touched most of the connectors.

Nobody on the team is doing anything wrong. Each person just has the full connector set enabled, so each person drags the full baseline into every prompt. The waste isn't dramatic per call — it's dramatic because it's the same small tax collected relentlessly, everywhere, all day.

The payload cost, multiplied across a team

Now stack the verbose responses on top. A read that returns fifty fields when the answer needed five wastes the same share of tokens for every person who runs it. When ten people each pull the same kind of bloated record forty times a day, you're not paying for that waste once — you're paying for it four hundred times, before you count the other connectors.

This is why the curve looks steeper for teams than the connector cost spiral does for one user. The spiral is one person adding connectors. Team scale is that spiral run in parallel across every seat.

Where the curve bends: agents, not just people

The multiplier gets sharper when the callers aren't people. A person makes a handful of connector calls an hour and then goes to lunch. An automated agent, a scheduled report, a background workflow — those run continuously, and they can each make many more calls than a human would.

Point a fleet of agents at the same connectors and the cost stops tracking headcount and starts tracking call volume, which grows much faster. This is usually the point where a token bill goes from "a line item" to "who owns this?"

Can you keep the connectors and cut the team bill?

Yes, because the expensive part isn't the connectors — it's the standing overhead and the verbose payloads, repeated across every seat and every call. Cut the per-call waste once, centrally, and you've cut it everywhere it was being multiplied.

That's what an in-transit layer does. Stash Lite serves the connectors your team already runs — Notion, Coda, Jira and Confluence, HubSpot, GitHub, Salesforce, and more — reshapes each response as it passes through, and stores nothing. Same connectors, same auth, same permissions; a leaner call. From our preliminary, directional testing, heavy reads can drop up to about 80% of their token cost through a reshaping layer — a ceiling on favourable workloads, not a guarantee, and worth measuring on your own traffic. It's read-only by design and holds no copy of your data, which keeps the security surface small when a whole team is routing through it. Stash Lite is in early access, so it's a new service and pricing may change.

See the team-scale consolidation setup and join the early-access list: stashlite.com/consolidate.

A prompt to estimate your team's connector overhead

Before you change anything, get a rough figure for what the multiplier is doing to you. Paste this to your AI agent with your connectors live:

Help me estimate our team's MCP connector overhead at scale.

1. List the connectors we have enabled and their tool definitions
   that ride in context on every call.
2. For our most common read queries, estimate what share of each
   response the answer actually uses versus what's returned unused.
3. Given rough numbers for seats and daily calls per seat (I'll
   provide them), estimate how many times a day we pay that
   standing overhead and that unused payload across the whole team.
4. Summarise where consolidating to one lean call would save the
   most: which connectors, and whether people or automated agents
   are driving the volume.

The output is directional, not exact — but it tells you which axis is really driving your bill, which is where consolidation pays off first.

This is part of our Stash Lite series on the real mechanics of MCP cost at scale, measured carefully and hedged where it should be. Related: how to consolidate multiple MCP connectors into one call and why MCP connector responses cost so many tokens.