MCP tool-input rewriters: gauging interest before opening a PR

Hey — opening this to check interest before sending a PR.

The idea

Add an mcp-rewrite subcommand that filters/normalizes the JSON inputs Claude Code sends to MCP tool calls — same way rtk's existing CLI filters compress shell command output, but applied to structured tool-call payloads. Wires up via PreToolUse hooks matching on mcp__* tool names.

The "input" side of an MCP request is often where the agent silently leaves performance on the table. Concrete example: calling mcp__rider__search_text (JetBrains Rider's MCP server) without paths: excludes floods results with .claude/worktrees/* mirror duplicates and obj//bin/ build artifacts. A few KB of garbage tokens per call, and the agent has no way to know it should set the exclude unless the user has told it.

Same philosophy as the rest of rtk: silent, fast, transparent, opt-in via hook config, additive only (never overrides what the agent explicitly set).

Shape

• One submodule per MCP server (mcp::rider, mcp::serena, etc.) — keeps server-specific quirks isolated
• Snapshot-tested with insta
• No networking, no daemon — pure JSON in / JSON out, fits rtk's <10ms startup constraint and single-threaded design

Why ask first

I have a working implementation on a fork (currently Rider-only, ~150 lines of rewriter code + tests). Before cleaning it up for a PR I'd like to know:

1. Is this in scope for rtk? Token compaction of MCP traffic feels on-mission, but happy to be told it isn't.
2. Any preferences on subcommand naming, hook integration, or per-server module layout?

If interest is low, no harm done — I'll keep it on the fork. If interest is there I'll send a focused PR with just the rewriter. (My fork also has an mcp-proxy daemon for live response compaction; that one is architecturally off-brand for rtk — long-running, threaded, IDE-specific — and stays fork-only regardless.)

Happy to elaborate on any of this.