How do you decide which MCP fields to keep?

Start from the common-answer fields for that object: the small, predictable handful a typical query reads (a title, a status, an owner, a date, a short body). Those are the default keep set. Everything else is trimmed by default but kept when the query signals it needs it. Reshaping is query-aware, not a fixed whitelist applied blindly to every call.

What happens when a query genuinely needs the heavy fields?

The rule keeps them for that response. If the question is about the change history, the comment thread or the permission block, those fields move from the trimmed column back into the kept set for that single call. The default trims to the common answer; the intent of the query overrides the default when it asks for more.

How do you avoid over-trimming and breaking the answer?

The safety principle is to favour answer-correctness over maximum savings: when in doubt, keep the field. A field that might be needed is cheaper to pass through than a wrong answer is to recover. Reshaping is tuned to trim what is clearly unused, not to shave every possible token at the risk of a broken response.

Do reshaping rules break when the connector changes its schema?

Rules are written against field roles, not brittle absolute paths, and unknown or new fields default to being passed through rather than dropped. If a connector adds a field, the worst case is that it is kept (a few extra tokens), not that the answer loses data. Reshaping happens per response and in transit, and Stash Lite stores nothing.

How reshaping rules are written so a trimmed MCP response still answers the question

This is the third post in our series on the mechanics of MCP cost. The first, why MCP connector responses cost so many tokens, covered what drives the bill. The second, a field-by-field teardown of one connector response, showed which fields an answer reads versus which are returned but never touched. This post is the natural follow-on: the teardown showed what is unused, and this one shows how you decide what to keep without breaking the answers that do need more.

How do you decide which fields to keep?

You start from the common-answer fields. For any given object, a small and predictable handful of fields cover most of the questions asked of it. Reuse the project-issue object from the teardown post: the everyday question ("what is the status, who owns it, when is it due?") reads key, title, status.name, assignee.display_name, due_date, with priority.name and description for context. That set is the default keep list for that object.

Everything outside it (the internal IDs, the audit history, the permission block, the full comment thread, the nested custom fields) is trimmed by default. Not because it is useless, but because the typical query does not read it. A rule sketch for that object looks like this, and it is illustrative rather than a literal config:

object: project-issue
keep by default:
  key, title, status.name, assignee.display_name,
  due_date, priority.name, description
trim by default:
  id, self, schema_version, *.account_id, *.email, *.avatar_*,
  watchers, permissions, custom_fields.*, comments.*, history.*, links.*

The keep set is deliberately small because that is where the savings are. The trim set is the long tail the teardown post walked through. So far this is the fixed-whitelist idea from post two. The next two sections are what makes it safe.

What happens when a query needs the heavy fields?

The default is overridden by the intent of the query. A whitelist that always dropped the history would be wrong the moment someone asks about the history. So the rule reads the shape of the question first, and promotes fields from the trim column back into the keep set when the question signals it needs them.

Concretely, the same object answers very different questions, and the keep set follows:

"What is the status and who owns PROJ-1184?" keeps the default set. History, comments and permissions stay trimmed.
"Walk me through how this issue changed and who moved it." keeps history.* for this response. The audit trail is now load-bearing, so it is passed through in full.
"Summarise the discussion on this issue." keeps comments.*. The comment thread is the answer, not noise.
"Can this user transition this issue?" keeps permissions. The permission block is the whole point of the call.

This is what query-aware means in practice. The default trims to the common answer; the question's intent decides whether a heavy field is unused waste (trim it) or the substance of the answer (keep it). The rule is per response, evaluated on the call in front of it, not a single static shape stamped onto every call.

How do you avoid over-trimming?

By making the default asymmetric. Trimming a field that turns out to be needed produces a wrong or incomplete answer, which is expensive to notice and expensive to recover. Passing a field through that turns out to be unused costs a few tokens. Those two errors are not equal, so the rules are not tuned to treat them as equal.

The safety principle is plain: when in doubt, keep the field. A few specifics that follow from it:

Ambiguous query, lean toward keep. If the question could go either way on whether it needs the body or a custom field, the field is kept. Answer-correctness beats a marginal token saving.
Cheap fields are not worth trimming. A short scalar like priority.name costs almost nothing to carry, so it stays in the default keep set rather than being gated behind a query signal.
Trim the clearly heavy and clearly unused. The big wins (avatar URLs, full audit arrays, repeated account objects, format metadata) are unambiguous: heavy in tokens, almost never read by a typical answer. Those are where reshaping leans in hardest.

The point of a reshaping layer is to remove what was never going to be used, not to shave every last token at the risk of a broken response. Maximum savings on a wrong answer is not a saving.

Do reshaping rules break when the connector changes?

Rules are written against field roles rather than brittle absolute positions, and the default for anything unrecognised is to pass it through. If a connector ships a new field or renames part of its schema, the worst case is that the new field is kept and the model reads a few extra tokens, not that the answer silently loses data. Failing toward keep is the same safety principle as the previous section, applied to schema drift.

That keeps the behaviour predictable as connectors evolve. The connectors enterprises run in practice (Notion, Coda, Jira and Confluence (Atlassian), HubSpot, GitHub, Salesforce, and more) all version and extend their objects over time. A reshaping layer that breaks on every schema bump would not be worth running, so the rules degrade toward correctness, not toward dropping the unknown.

And the part that does not change at all: the reshaping happens to the response as it passes through, then it is gone. Stash Lite is a transit layer, not a cache. It serves your existing MCP connectors, reshapes each response in transit, and stores nothing. The trimmed shape exists for the length of the call and is not retained. The document passes through to the AI; it does not live in Stash Lite.

That is also why the security review stays small. The connectors and their auth are unchanged, so the security posture stays the same as talking to the official servers. A layer that retains nothing has far less to reason about than anything that keeps a copy. What the rules change is the size of the payload the model reads on a given query, not who can see the data or where it rests.

Does this hold across connectors?

Yes, with different field names and the same logic. A CRM record has its own common-answer set (name, owner, stage, deal value) and its own heavy tail (enrichment fields, association IDs, full activity logs) that a query about recent activity would promote into the keep set. A docs page has its text as the common answer and its version metadata, block tree and permission data as the heavy tail that specific questions pull in. The roles are consistent even when the schemas are not, which is what lets the same query-aware approach apply across the connectors enterprises run in practice. You keep your existing connectors and their permissions; the reshaping happens to what comes back, per response, in transit.

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

The keep-versus-promote prompt

You can work out your own keep-by-default and keep-on-demand fields with the prompt below. Paste it to your AI agent in a session where your connectors are live:

Help me work out query-aware reshaping rules for one connector object.

1. Pull one realistic object I'd normally read (an issue, a record, a page)
   and show me the full response.
2. List 4-6 of the common questions I ask about this kind of object.
3. For the MOST common question, mark the small set of fields its answer
   reads. That is my "keep by default" set.
4. For each of the OTHER questions, list which extra fields it would need
   promoted back in (history, comments, permissions, enrichment, etc.).
   That is my "keep on demand" set, keyed by what the question signals.
5. Flag any field that is cheap to carry and ambiguous in use, and
   recommend keeping it by default rather than gating it, on the principle
   that answer-correctness beats a marginal token saving.
6. Note which fields are clearly heavy AND clearly unused across all my
   questions. Those are the safe, high-value trims.

Treat the result as illustrative rules for my own workload, not a
measured benchmark. The aim is to trim what is reliably unused while
keeping anything a real question might need.

That gives you a concrete keep-by-default set plus a short list of fields each query type pulls back in, on your own objects and your own questions. If your common queries share a small keep set and the heavy fields are needed only occasionally, query-aware reshaping in transit is worth a look.

This is the third post in our Stash Lite series on the real mechanics of MCP cost at enterprise scale, measured carefully and hedged where it should be. Next up: how reshaping interacts with write calls, where the field you trimmed on the read is the field the write needs back.