How MCP response reshaping interacts with write calls

This is the fourth 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. The third, how reshaping rules are written, covered query-aware field selection. This post takes the question the third one ended on: what happens to a write when the field you trimmed on the read is the field the write needs back.

Does reshaping the read break the write?

The honest version of the worry is specific. Reshaping trims a read response. Suppose the teardown post is right and the layer trims the internal id, the full status object, the permissions block and most of the rest, leaving the model with a clean answer to "what is the status of PROJ-1184?". Then the next instruction is "set it to Done." If the model never saw the identifier the write API targets, or the exact allowed value for the status field, that write could fail or be ambiguous, because the model is missing the handle it needs to act through.

That is a genuine failure mode, and it is worth naming plainly rather than waving away. It is also avoidable, because it comes from one specific kind of over-trimming: dropping the fields a write acts through. The rest of this post is what "designed correctly" means so that does not happen, and where the boundary sits.

What does a write call send?

Reads and writes move in opposite directions, and that is the first thing to get straight.

• A read asks the connector for an object and gets a response back. The response is where the tokens pile up, so the response is what reshaping trims. This is the whole subject of the first three posts.
• A write sends data the other way: the agent hands the connector a payload to create or update a record. "Set PROJ-1184 to Done" becomes a write call carrying an identifier (which issue) and the field change (status to the allowed value the connector expects).

The token cost reshaping optimises sits on responses, not on the payload the agent sends. A write payload is small to begin with (an id and a field or two), so there is little to trim there and reshaping leaves it alone. The interaction that matters is not "does the layer shrink my write" (it does not) but "did an earlier read leave the model holding the fields this write needs."

Which fields must survive trimming for writes to work?

Three kinds of field are the ones a write depends on, and a correctly designed reshaping layer treats all three as keep-by-default.

• The stable identifier. The key or id you target a write through is the handle for every later action on the object. It is kept by default precisely because it is how you act on the record, even though a pure read answer ("the status is In Progress") never quotes it. In the reshaping-rules post this is the reasoning for keeping key in the default set; the same reasoning keeps the underlying id addressable.
• Required field names. A create call needs to know which fields the connector requires. Those field names are part of what a write-shaped query needs, so a query whose intent is "create an issue" keeps them.
• The exact allowed values. A status enum has specific permitted values ("Done", not "done" or "Complete"). When the model needs to write one of those values, it needs the exact allowed set, not a friendly label.

The contrast is what makes this safe rather than lossy. Trimming display noise (avatar URLs, audit history, format metadata, repeated account objects) is safe, because no write acts through those. Trimming the identifier you write back through is not safe, so it stays. The asymmetry is the same one the reshaping-rules post described: when a field is the handle you act on the object with, keep it.

How does query-aware reshaping handle a write?

This ties straight back to the query-aware idea from the previous post. The default trims a read response to the common-answer fields, and the intent of the query promotes heavy fields back into the keep set when the question signals it needs them. A write intent is one of those signals.

When the model needs the exact allowed values to perform a write (the status enum, the valid field names, the required fields for a create), that is a query whose intent needs those fields. So the reshaping rule keeps them for that response, the same way "walk me through how this issue changed" keeps the history. Here is the running project-issue object again, with two responses from it, illustrative rather than a literal config:

object: project-issue

# read intent: "what is the status of PROJ-1184?"
keep: key, title, status.name, assignee.display_name, due_date, priority.name
# (id stays addressable as the write handle even though the answer never quotes it)

# write intent: "set PROJ-1184 to Done"
keep: key, id, status.allowed_values
# the identifier to target the write, and the exact enum value the write API expects

The model gets a lean read when the question is a read, and the allowed values when the question is going to act. In both cases the identifier survives, because it is the thing every write needs and the thing a read answer can afford to carry.

Does Stash Lite change my write payloads?

No, and this is the part that does not change at all. The write call itself goes to the connector unchanged. Reshaping does not rewrite the agent's write payload, does not reorder its fields, does not touch its values. Same connectors, same auth, same write semantics as talking to the official servers. What the layer changes is the size of a read response, never the write.

That is also why the security posture stays the same. The connectors and their auth are unchanged, reads are reshaped as they pass through, writes pass through untouched, and nothing is retained. Stash Lite is a transit layer, not a cache. The trimmed read shape exists for the length of the call and is then gone; the write payload passes straight through. The data passes through to and from the connector; it does not live in Stash Lite. A layer that retains nothing has far less to reason about than anything that keeps a copy.

What is the honest caveat?

This is a design constraint reshaping must respect, not a free lunch. Over-aggressive trimming that drops identifiers would break writes, exactly as the worry at the top describes. The claim is narrower and more honest than "trim everything and writes are fine." It is this: a correctly designed reshaping layer treats write-relevant fields (the identifiers, the keys you act through, the required field names, the allowed values when a write needs them) as keep-by-default, and stays read-only in what it changes. It changes response size, never the write.

That follows the same safety principle as the reshaping-rules post: when in doubt, keep the field. A trimmed identifier that breaks a write is far more expensive than the few tokens carrying it would have cost, so the identifier stays. The point of reshaping is to remove what was never going to be used, and the handle a future write acts through is, by definition, going to be used.

Does this hold across connectors?

Yes, with different names for the same roles. A CRM record is targeted by its own record id, and an update ("move this deal to Closed Won") needs that id and the exact stage value the connector accepts, while the enrichment fields and activity log stay trimmed. A docs page is targeted by its page id, and an update needs that id and the field being changed, while the version metadata and block tree stay trimmed. The connectors enterprises run in practice (Notion, Coda, Jira and Confluence (Atlassian), HubSpot, GitHub, Salesforce, and more) all separate the small handle you act through from the heavy body you usually do not, and a reshaping layer keeps the former addressable while trimming the latter.

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

The write-safety prompt

You can check, for your own connectors, that the fields your writes depend on are ones a reshaping layer would keep. Paste this to your AI agent in a session where your connectors are live:

Help me check that my writes still work if read responses are trimmed
for token cost.

1. Pick one connector object I both read and write (an issue, a record,
   a page). Pull one realistic example and show me the full response.
2. List 2-3 writes I really make on it (e.g. "set status to Done",
   "reassign owner", "update a field", "create a new one").
3. For EACH write, tell me exactly what the connector's write API needs:
   - the identifier it targets the write through (key or id)
   - any required field names for a create
   - the exact allowed values for constrained fields (e.g. the status enum)
4. Now mark which of those write-needed fields appear in a trimmed READ
   response that only kept the common-answer fields. Flag any that would
   be MISSING, because those are the fields a reshaping layer must keep
   by default for my writes to work.
5. Confirm the write payload itself is unchanged by trimming reads: the
   write still sends the same identifier and values to the connector.

Treat this as a check on my own workload, not a benchmark. The aim is to
confirm the identifiers and allowed values my writes depend on are
keep-by-default, while heavy read-only fields can still be trimmed.

That gives you a concrete list of the write-critical fields on your own objects, so you can confirm they sit in the keep-by-default set rather than the trimmed tail. If your writes depend only on identifiers and a handful of allowed values, and the heavy fields are read-only noise, reshaping reads in transit and passing writes through is safe to lean on.

This is the fourth 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: where the token savings really land across a week of real usage, and why the headline number per call is the wrong thing to watch.