What Broke
A couple of commits ago we loosened our inline image rules: 500 KB limits, forced WebP conversions, no downsampling, and image blocks emitted before any text. Claude Code happily trimmed the history, but Claude Desktop retained every base64 payload. Two tool calls later the session was carrying megabytes of inline data and the desktop client tapped out.
How We Diagnosed It
- Compared the working 38623b8 commit against head and spotted the inline-budget and ordering drift.
- Pulled structured-content logs from both clients and confirmed Desktop rejected responses when an inline block arrived before text or exceeded ~150 KB.
- Researched MCP SDK guidance plus broader thumbnail best practices—most recommend sub-100 KB payloads and long edges under 256 px.
- Reproduced the failure locally by running multi-image generations; context bloat showed up immediately in Desktop.
Fix We Shipped
- Text-first ordering – summaries now lead every response, followed by
resource_linkblocks, with inline previews last. - Format-aware compression – we respect the caller’s preferred MIME (JPEG/PNG/WebP) and only transcode when necessary, keeping fidelity predictable.
- Real downsampling – previews resize to a 256 px long edge before the quality ladder runs, landing around 35–45 KB per image after base64.
- – inline budgets, resize targets, and quality tiers live behind a shared config so we can tune per client hint.