The Cost of Pretty JSON
JSON was designed for application-to-application interchange — readability for developers, clarity for debugging. When an AI agent reads a tool response, it processes the same structural characters that make JSON readable: quotation marks around every key and string value, braces around every object, brackets around every array, commas between every element, and whitespace for indentation.
Each of those characters is a token. In a production agent workflow where tool responses flow through the context window hundreds or thousands of times a day, the overhead is substantial. Research on MCP workloads across 22 teams in Q1 2026 found that MCP-related input tokens accounted for 41 to 58 percent of total Claude Code spend. [1] Poor data serialization can consume 40-70% of available tokens in production agent systems before any meaningful reasoning begins. [2]
The simplest optimization — the one you can do in five minutes — is to stop pretty-printing JSON in tool responses.
Minified JSON: The Five-Minute Win
Switching from indented JSON to compact JSON is the highest-ROI optimization available. In most languages, it's a one-line change. In Python: json.dumps(obj, separators=(",", ":")) instead of the default json.dumps(obj, indent=2). In JavaScript: JSON.stringify(obj) without the pretty-print arguments.
The results are measurable. Benchmarks on a mid-sized Home Assistant installation show compact JSON is 31% smaller than indent=2 and 18% smaller than the standard library default. On a full entity list of 1,000-2,000 items, that translates to roughly 100,000 tokens saved per call. [3]
This is not a tradeoff. The model doesn't need indentation to parse JSON — it tokenizes the content the same way regardless of whitespace. You lose nothing in comprehension and gain significant cost reduction. If your MCP servers or tool responses are returning pretty-printed JSON, fix that first before considering anything more exotic.
Beyond Minification: Token-Optimized Formats
Compact JSON removes whitespace but retains all of JSON's structural syntax — quotes around every key, braces around every object, commas between every element. A new generation of formats targets that structural overhead directly.
TRON: Token Reduced Object Notation
TRON is a superset of JSON — meaning any valid JSON is also valid TRON — that reduces token count by allowing "class" definitions (schemas) for objects. Instead of repeating property names in every object in an array, you define the schema once and encode subsequent objects as positional values. This eliminates the key repetition that dominates large JSON arrays.
Benchmarks across four agentic evaluation suites (BFCL, MCPToolBenchPP, MCP-Universe, StableToolBench) show TRON reduces tokens by up to 27% with accuracy within 14 percentage points of the JSON baseline. [2] Because TRON is a JSON superset, adoption is incremental — you can introduce class definitions for the most repetitive data structures without changing anything else.
TOON: Token-Oriented Object Notation
TOON takes a more radical approach. It eliminates quotation marks, braces, and brackets entirely, using YAML-like indentation for nested objects and CSV-style tabular notation for uniform arrays. The result is visually closer to a configuration file than a data interchange format.
TOON achieves up to 42.6% fewer tokens than JSON while matching JSON's retrieval accuracy (72.2% vs 71.4% in benchmarks). The TOON specification reached version 4.1 in July 2026, maintained under an MIT license with TypeScript and Python SDKs available. [4]
The tradeoff: TOON is not a JSON superset. It requires explicit encoding and decoding steps. And the "Notation Matters" benchmark study found that structural-correctness rates degrade for models without native support — TOON can cascade on multi-turn parsing failures and collapse parallel tool-call output for most open-weight models. [2] For production agentic loops, TRON's incremental approach tends to be safer than TOON's wholesale format replacement.
Other Emerging Formats
The research space is active. JTON uses a tabular grid encoding and reports 15-60% token reduction across seven domains. ONTO uses pipe-delimited columnar notation, reducing tokens by 46-51% on IoT data. TSLN achieves 68-73% reduction through schema-first architecture for time-series data. [2] Each is optimized for specific data shapes rather than general-purpose interchange.
The MCP Token Tax
These format optimizations matter most in MCP workflows, where tool responses pass through the model's context window as part of the conversation. The "MCP Tax" — the overhead of loading verbose JSON schemas for all connected tools upfront — can account for the majority of token spend before any meaningful computation begins. [5]
For a deeper look at how tools are exposed to models and why schema design matters, see How Tools Work with AI Models. The token cost of tool definitions compounds with the token cost of tool responses — optimizing both surfaces is where the real savings come from.
Teams that applied MCP optimization techniques systematically — including compact JSON, selective tool loading, and response filtering — reduced MCP input-token share from 47% to 21% of total spend in four weeks. [1]
Practical Recommendations
- Start with compact JSON. Switch all tool and MCP server responses to minified JSON — no indentation, no extra whitespace. This is a one-line change that delivers 18-31% token reduction with zero accuracy cost.
- Filter tool output to what's needed. A tool call that returns 50 fields when the agent needs 3 wastes tokens regardless of format. Trim responses to the fields the agent will actually use. [6]
- Evaluate TRON for repetitive data. If your tool responses include arrays of objects with shared schemas (database rows, API results, entity lists), TRON's class definitions can cut token count by up to 27% on top of minification. Since TRON is a JSON superset, you can adopt it incrementally.
- Be cautious with TOON in production loops. TOON's token savings are substantial, but the multi-turn parsing failures documented in benchmarks make it risky for autonomous agent workflows. Consider TOON for human-facing reports or single-turn interactions where parsing failures are recoverable.
- Measure before and after. Token counts are observable. Log the token usage of your agent's tool calls before and after format changes to verify the actual savings in your workload.
Where This Is Heading
The tension between human-readable data formats and token-efficient agent formats will persist as long as agents process structured data through token-based context windows. JSON will remain the default interchange format — it's too deeply embedded in web infrastructure to replace. But the layer between tool output and agent input is increasingly becoming an optimization surface.
The trajectory is toward format-aware agent infrastructure: MCP servers that automatically negotiate output format based on the client's capabilities, context compaction that summarizes verbose responses server-side, and model architectures that handle structured data more efficiently than tokenizing raw text. Until then, the practical advice is straightforward: minify your JSON, filter your responses, and measure the difference.