Why do MCP connector calls cost so many tokens?

Most connectors return full, verbose JSON for every call, with metadata, nested objects and fields you never asked for. The model has to read all of it, so you pay for the whole payload on every single call, even when you only needed a title and a status.

Can you reduce MCP token costs without losing data or changing answers?

Yes. The saving comes from sending the model only the fields it needs, not from changing the underlying data. If you select and reshape the response in transit, the agent gets the same answer from a much smaller payload.

Does Stash Lite store my data to do this?

No. Stash Lite is a transit layer, not a cache. Responses are reshaped as they pass through and nothing is retained. The document passes through to the AI; it does not live in Stash Lite.

How much can you really save?

From our preliminary, directional testing, up to about 80% on heavy read calls. It varies a lot by connector and workload, so treat any single number as an estimate until you measure it on your own traffic.

Why MCP connector responses cost so many tokens (and how to cut the bill)

Why are MCP connector calls so token-expensive?

The Model Context Protocol made it easy to plug Claude (and ChatGPT) into the tools your team already uses. The trade-off shows up on the bill. Most connectors are built to be complete, not lean, so a single call returns the full object: timestamps, internal IDs, permission blocks, nested relations, formatting metadata, and the handful of fields you wanted, all in one payload.

Every token in that payload is a token your model reads. At the scale of one query that is invisible. At the scale of an enterprise running hundreds of connector calls an hour, the verbose half of each response is a recurring cost that buys you nothing.

What drives the token cost of a response?

Three things, roughly in order:

Field bloat. You asked for a task's title and status. You also got its full change history, every custom property, and the IDs of everyone who has ever touched it.
Format overhead. Deeply nested JSON spends tokens on structure (keys, brackets, quoting) as well as values. The same data in a flatter shape reads in fewer tokens.
Repetition across calls. The same heavy object comes back in full on every related call, so the waste compounds with usage rather than being a one-off.

None of this is the connector doing anything wrong. It is returning everything because it cannot know which slice you needed.

Can you reduce MCP token costs without losing data or accuracy?

Yes, and this is the part worth being precise about. The saving does not come from giving the model less information to reason with. It comes from not sending the parts of the response that were never going to be used. If a query needs five fields, the model gets those five fields cleanly, and the answer is the same as if it had waded through fifty.

The lever is response reshaping: field selection, projection and format, applied to what the connector returns before it reaches the model.

What is reshaping in transit?

Reshaping in transit means the response is trimmed and reformatted as it passes through, and then it is gone. This is a transport concern, not a storage one. Stash Lite sits between your connectors and your AI as a lean managed layer: it serves your existing MCP connectors, reshapes each response on the way through, and stores nothing. The document passes through to the AI; it does not live there.

That distinction matters for security review. A transit layer that retains nothing has a much smaller surface to reason about than anything that keeps a copy. The security posture stays the same as talking to the official servers, because the connectors and their auth are unchanged. What changes is the size of the payload, not who can see it.

How much can you save?

From our preliminary, directional testing, up to about 80% on heavy read calls. That number is a ceiling on favourable workloads, not a promise. Read-heavy connectors with bloated objects (large Notion or Coda pages, busy Jira or Confluence issues, fat HubSpot or Salesforce records) have the most fat to trim, so they save the most. Light calls that already return little will save little. The honest answer is to measure it on your own traffic, which is what the prompt below helps you do.

Does this work with the connectors we already use?

It is built around the ones enterprises run in practice: Notion, Coda, Jira and Confluence (Atlassian), HubSpot, GitHub, Salesforce, and more. You keep your existing connectors and their permissions. Stash Lite serves them for you and reshapes what comes back. There is nothing new to host and nothing to maintain. It is built on Stash, with one Google sign-in across Stash and Stash Lite.

Stash Lite is in early access right now. You can join the waitlist on the Stash Lite homepage.

The audit prompt

Before you change anything, it is worth seeing where your own tokens go. Paste this to your AI agent in a session where your connectors are live:

For the connectors I have enabled, help me audit token cost.

1. Make a few realistic read calls I'd normally make (pulling a page,
   an issue, a record, a list).
2. For each call, estimate the size of the response the model received,
   and break it down: which fields did the answer use, and
   which fields were returned but unused?
3. Roughly what share of each response was unused?
4. Summarise: which connectors return the most unused data per call,
   and which of my common queries would shrink the most if the response
   only contained the fields the answer used?

That gives you a directional picture of your own waste, in your own workload, which is the only number that really matters. If the unused share is large and your call volume is high, an in-transit reshaping layer is worth a look.

This is the first in our Stash Lite series on the real mechanics of MCP cost at enterprise scale, measured carefully, hedged where it should be. Next up: a field-by-field teardown of one bloated connector response.