DEV Community

Ahab
Ahab

Posted on Originally published at indieseek.co

Qwen Code 0.24.5 bounds MCP screenshots: verify media budgets before trusting tool output

Qwen Code 0.24.5 bounds MCP screenshots: verify media budgets before trusting tool output

Quick answer

Qwen Code 0.24.5 closes a costly path: large images returned by MCP tools no longer enter every later model request at the server's original resolution. Released code now recognizes supported image bytes, bounds JPEG, PNG, and WebP content, then applies the inline byte ceiling before the result reaches the conversation.

Do not treat the upgrade alone as proof that every media path is safe. Pin 0.24.5, connect a synthetic MCP server, replay small, oversized, mislabeled, unsupported, multi-image, and over-limit fixtures, and inspect what the model actually receives. Keep a receipt for dimensions, patch count, MIME type, bytes, placeholder behavior, latency, and follow-up context growth.

Who this is for

This guide is for teams using browser, screenshot, design, chart, or document MCP servers with Qwen Code. It is especially relevant when an agent takes several full-page screenshots in one session or when the MCP server is outside your trust boundary.

If you are controlling signed-in browser tabs, first apply the Browser Use cleanup checklist. If you retain recordings or HAR files, use the browser-agent recording checklist as a separate privacy boundary.

What changed—and what the official evidence proves

The official 0.24.5 release includes two related fixes: bounding oversized MCP images and deciding media handling from the bytes rather than the declared label. The merged implementation applies the existing image-view budget to tool-result image blocks, embedded resource blobs, and images returned with tool errors.

The released constants are concrete: longest edge at most 1,568 pixels, at most 1,568 visual patches, a 100 MiB source cap, a 9 MiB rendered-output cap, and a default 10 MiB inline-media ceiling controlled by QWEN_CODE_MAX_INLINE_MEDIA_BYTES. A supported image that already fits stays byte-for-byte unchanged. The official pull request reports a test fixture changing from a 3840×2160 PNG at 10,764 patches to a 1456×819 JPEG at 1,560 patches. That is maintainer evidence, not an IndieSeek benchmark.

Map the media paths before testing

Input path Expected 0.24.5 behavior
Oversized JPEG, PNG, or WebP tool result Resize/re-encode to the visual budget, then enforce the byte ceiling
Small supported image Preserve original bytes, format, and alpha
Supported bytes with a wrong MIME label Detect from magic bytes and apply the supported-image path
Unsupported GIF or SVG within the inline ceiling Forward unchanged; no visual-budget guarantee
Source above 100 MiB or an unboundable over-ceiling part Replace with a safe text placeholder
Multiple images Process sequentially to bound peak decode/render memory
Omni upload declined or failed Bound an image before keeping it inline

Two gaps matter. A separate MCP resources/read flow is outside the pull request's coverage, and image-like data inside structuredContent follows text serialization rather than the image budget. The implementation also has no new per-result image-count or aggregate-byte budget outside the omni delivery limits of eight uploads and 128 MiB. Do not generalize “MCP images are bounded” beyond the tested path.

Run a seven-case canary

Use synthetic content only. Record the Qwen version and tag commit (59c8e93c0e9b34db77beb1b087e4076916532513), then have a disposable MCP tool return:

  1. A 400×300 transparent PNG; require identical bytes and MIME.
  2. A 3840×2160 PNG; require longest edge and patch count at or below 1,568.
  3. PNG bytes labeled application/octet-stream; require byte sniffing to select the image path.
  4. A small GIF; require unchanged forwarding and mark it “not visually bounded.”
  5. A decodable image above the inline ceiling; require a bounded result under the ceiling or a placeholder.
  6. A source above 100 MiB; require rejection before decode and a placeholder.
  7. Nine large images with omni delivery enabled; require no more than eight uploads and a bounded inline remainder.

Inspect the outbound provider request or a test transport—not just the terminal summary. A UI label can say JPEG while stale bytes or another route still enters the request. Run one follow-up turn after every fixture and measure total request bytes or visual patches; the original bug mattered because old screenshots persisted across later turns.

Keep a media receipt 

{"case":"oversized-png","qwen":"0.24.5","entry":"mcp-call-tool","declared_mime":"image/png","detected_mime":"image/png","source_px":"3840x2160","delivered_px":"1456x819","delivered_mime":"image/jpeg","patches":1560,"bytes":314822,"placeholder":false,"followup_request_bytes":488120,"latency_ms":184}
Enter fullscreen mode Exit fullscreen mode

Store the configured inline ceiling and whether omni delivery was active. Compare the same fixtures on your previous pinned version and 0.24.5. Promotion requires every supported-image case to stay within both geometry and byte limits, unsupported formats to follow the documented fallback, placeholders to contain no attacker-controlled markup, and p95 processing latency to remain within your tool budget.

Roll back if request size still grows across follow-up turns, the wrong byte type bypasses bounding, a source above the cap reaches the decoder, or the placeholder hides a required artifact without a recoverable retry path.

Common mistakes

  • Checking only file size; a compressed 4K screenshot can still consume excessive visual patches.
  • Trusting the MCP-provided MIME label instead of the released byte-sniffing path.
  • Setting QWEN_CODE_MAX_INLINE_MEDIA_BYTES below the renderer's practical output and mistaking placeholders for tool failures.
  • Assuming GIF, SVG, structuredContent, and resources/read share the JPEG/PNG/WebP guarantee.
  • Testing one image but never the ninth-image, upload-failure, or follow-up-turn path.
  • Calling the official before/after fixture an independent production result.

Make your Mac notch useful with SuperNotch—22 native tools for music, clipboard, focus, screenshots, system controls, and more.

FAQ

Does 0.24.5 prevent every MCP server from exhausting context?

No. It bounds supported images on the covered tool-result paths. Text, unsupported media, aggregate result count, separate resource reads, and serialized structured content need their own limits.

Should I lower the default 10 MiB ceiling?

Only after replaying your fixtures. The official change notes that an unusually low ceiling can turn a successfully resized image into a placeholder. Choose the ceiling from accepted output and memory limits, not from guesswork.

Did IndieSeek reproduce the maintainer's 10,764-to-1,560 patch result?

No. This article verifies the released tag, source constants, merged tests, and stated boundaries, then provides a canary protocol. The numerical before/after fixture remains Qwen's evidence until independently replayed.

Sources

Originally published on IndieSeek.

Top comments (0)