Expand RTK beyond PreToolUse — add PostToolUse hooks to optimize MCP tool outputs with TOON encoding

[gauravsagar483]

Problem

RTK today only intercepts before execution (PreToolUse) — rewriting git status → rtk git status. This works great for Bash or similar cli commands, but completely misses MCP tool outputs or API responses.

In a long-running agent session, hundreds of MCP calls return raw JSON (search results, query outputs, API responses) that flow into the LLM context unoptimized. This is arguably a bigger token sink than Bash output.

Today:    MCP Tool → raw JSON (15K tokens) → LLM sees everything
Proposed: MCP Tool → raw JSON → RTK PostToolUse filters + TOON encodes → LLM sees ~2K tokens

Proposal

Add PostToolUse hook support to RTK. After any tool executes, RTK intercepts the response and applies:

1. RTK's existing filtering strategies (field exclusion, truncation, deduplication — already 12 strategies in the codebase)
2. TOON encoding as default for uniform arrays (~40% token savings with equal or better LLM accuracy)
   Config-driven, per-tool:

[post_tool]
default_format = "toon"
 
[post_tool.rules.search_hotels]
exclude_fields = ["description_html", "image_urls", "raw_policies"]
max_items = 10

Bonus: catches what PreToolUse can't

Claude Code's built-in tools (Read, Grep, Glob) bypass the Bash hook entirely. A PostToolUse hook would catch these too — same filtering logic, unified pipeline.

---

Summary

RTK's PreToolUse hooks solved token optimization for shell commands. PostToolUse hooks would solve it for everything else — MCP tools, built-in agent tools, API responses — using the same filtering intelligence RTK already has, with TOON as the default compact encoding.

The combination of RTK's filtering + TOON encoding in a PostToolUse hook could save 85%+ tokens on structured tool outputs across hundreds of MCP calls in a long-running agent session.

Would love to hear thoughts from the maintainers and community on feasibility, especially around agent hook support for PostToolUse.

---

Config-driven per-tool rules

# ~/.config/rtk/config.toml
 
[post_tool]
default_format = "toon"           # TOON for uniform arrays, passthrough otherwise
 
[post_tool.rules.search_hotels]
exclude_fields = ["description_html", "image_urls", "raw_policies"]
max_items = 10
format = "toon"
 
[post_tool.rules.search_flights]
exclude_fields = ["detailed_itinerary", "raw_price_breakdown"]
format = "toon"
 
[post_tool.rules."*"]             # Wildcard: default for any MCP tool
exclude_fields = ["_debug", "_raw", "_internal"]
max_items = 50

What the LLM actually sees

before:

{"hotels":[{"id":1,"name":"Grand Hotel","price":250,"rating":4.5,"currency":"USD","city":"Paris","stars":5,"reviewCount":1823,"checkIn":"15:00","checkOut":"11:00","cancellation":"free","provider":"expedia","lastUpdated":"2026-06-19T08:00:00Z"},{"id":2,"name":"City Inn","price":180,"rating":4.2,"currency":"USD","city":"Paris","stars":4,"reviewCount":945,"checkIn":"14:00","checkOut":"12:00","cancellation":"non-refundable","provider":"expedia","lastUpdated":"2026-06-19T08:00:00Z"}]}

After:

hotels[2]{id,name,price,rating,currency,city,stars,reviewCount,checkIn,checkOut,cancellation,provider,lastUpdated}:
  1,Grand Hotel,250,4.5,USD,Paris,5,1823,"15:00","11:00",free,expedia,"2026-06-19T08:00:00Z"
  2,City Inn,180,4.2,USD,Paris,4,945,"14:00","12:00",non-refundable,expedia,"2026-06-19T08:00:00Z"

~40% savings on just 2 rows.
That's the same data the LLM needs to make decisions — at a fraction of the token cost.

RTK already has the filtering engine, the tracking infrastructure, the hook system, and the agent integrations. PostToolUse is the natural extension.

Token Savings Estimate

Based on TOON benchmarks (~40% savings on uniform arrays) combined with RTK's field filtering (~50–80% noise removal):

Scenario	Raw Tokens	After RTK + TOON	Savings
10 hotel search results	~8,000	~1,200	~85%
50-row SQL query result	~12,000	~2,000	~83%
Flight search (5 itineraries)	~6,000	~900	~85%
100 MCP calls/session avg	~500K+	~75K	~85%

I can contribute to this if you people approve the idea.
Thanks!!

[richardchen874-sys]

PostToolUse hooks plus TOON encoding hit the larger token sink here: raw MCP and API responses entering the model context after tool execution.

I would define a small provider capability matrix and attach usage/latency/error metadata to every routed call. That gives you a clean path to cost-aware routing without hiding why a route was chosen.

I am working through similar issues while testing an OpenAI-compatible layer for official Chinese models, mainly around routing, cost visibility, and response-shape compatibility. For rtk, would you rather optimize routing first for cost, latency, or fewer failed agent steps?