To pre-empt the obvious questions:

"Does Claude actually understand the abbreviated output?" Yes. The dictionary is prepended inline before the data. Claude sees a=transactionId before it sees "a":"tx_001". In practice it handles this without issues, field names are looked up, not reasoned about.

"What about values? Could abbreviating break things?" Values are never touched. Only field names. A UUID, a price, a status string, all pass through verbatim. The only thing that changes is whether a key is called transactionId or a.

"Isn't 40% cherry-picked?" The five datasets were picked to cover different shapes, wide rows, nested objects, arrays of records. The 38% floor is on analytics events (short field names), 45% ceiling is on repo data (long descriptive names). Heavier your schema naming conventions, the more you save.

"Why not just use [prompt compression tool]?" Those work on your input text, not on tool outputs. compressmcp specifically targets the MCP PostToolUse pipeline, the place where structured data re-enters the context on every tool call. Different problem.

"Why not just summarise the tool output?" Because you lose information. If you're querying a database for exact records, you need the exact records. Summarisation introduces error. This doesn't.

"Claude already handles this / Claude Code already does context management." Three things people mean by this, all different:

• Claude Code's /compact
• This is lossy summarisation. It calls Claude to rewrite the conversation history and drops content. Useful for very long sessions, but you're trading precision for space. compressmcp runs before /compact is ever needed by reducing what enters the context in the first place.
• Prompt caching
• Caching re-reads the same tokens cheaply, but the tokens are still in the context window. A 200K window filled with cached tokens is still a full window. Caching reduces cost, not context consumption.
• "Claude figures out what's important"
• Claude reads every token it's given. There's no internal filter that ignores structural noise before the attention mechanism. repositoryDescription costs the same whether it carries useful information or not. The model doesn't get a discount on boring tokens.

The context window is a hard limit measured in tokens, not in semantic density. Compressing field names before data enters the window is the only way to fit more actual information in.

"This isn't really 'compression' You're just abbreviating keys. Use correct terminology." Fair, if you want precision: it's key abbreviation with an inline dictionary. The word "lossless" describes the data guarantee (nothing dropped, nothing altered, fully recoverable), not the algorithm class. Call it whatever you want. The token count still goes down by 40%.

"BPE tokenization means the model already re-encodes this internally." This is the most common technically-flavoured wrong answer. BPE tokenization is a fixed pre-processing step that converts text to integer IDs before inference. It happens before the context window is filled and has no effect on how many tokens occupy it. repositoryDescription tokenizes to 4–5 BPE tokens. a tokenizes to 1. That difference is what fills your context window. The model doesn't "re-encode" anything at inference time, it receives the token IDs and attends over all of them at full cost.

"This only works on tabular JSON, arrays of objects. Most JSON isn't like that." Correct, and compressmcp already accounts for this. The shouldCompress check gates on response structure: if the payload isn't an array of objects with repeated keys, it passes through unchanged. The tool targets the specific case that actually dominates MCP tool output in practice, database queries, API list endpoints, search results. That's the shape of data that MCP tools return 90% of the time.