Repository navigation
Large MCP image artifacts omitted despite sufficient maxToolResultChars #602
Description
Withdrawn by the submitter; closed as not planned, not fixed. The same-turn sizing reproduction below remains valid. This is independent of LibreChat's documented cross-turn tool-image behavior. Associated PR #603 is withdrawn without merging; local patches and evidence are retained.
Related to ldavis9000aws/cf-fleetrebuild#55 and ldavis9000aws/CreatorFlow#47.
LibreChat v0.8.8, @librechat/agents 4.0.1, Desktop Commander 0.2.52, LiteLLM 1.101.0. Current agents main (97b2db3, package version 4.0.4) retains the same jsonStringLength implementation.
Minimal reproduction: construct an AIMessage with a tool call and matching ToolMessage whose artifact.content is [{type:'image_url',image_url:{url:'data:image/png;base64,' + Buffer.alloc(2477915).toString('base64')}}]. Call projectAnthropicArtifactContent(messages, 8000000) or projectArtifactPayload(messages, 8000000). Neither projection retains the image. A 33354-byte image survives.
The approximately 3.3M-character data URI exhausts MAX_STRUCTURED_CHARACTER_WORK (1M) in utils/toolContent.jsonStringLength. getToolContentCharLength returns a conservative oversized estimate and bounded artifact accumulation omits the image. Raising maxToolResultChars alone cannot recover it. UI attachments are saved independently and can appear even though the following provider request contains no image.
Verified with real Desktop Commander calls and redacted outbound request metadata: unpatched /v1/messages has no image after the PNG tool result; a 340755-byte JPEG also exceeds the ordinary default 400K artifact allowance, a separate expected configured limit. Small image delivery works on both native Anthropic and OpenAI-compatible custom transports.
Proposed fix: count bounded, escape-free base64 image data URIs directly while retaining existing size/context limits and traversal protection for arbitrary structured content. No infrastructure or TLS changes are required.
Activity
ldavis9000aws commentedon Oct 8, 2026
Additional deployment validation of the shared counting fix: the original OpenAI-compatible custom endpoint now passes actual Desktop Commander PNG reads with an 8M configured bound, without switching to Anthropic transport. A fresh Sonnet chat and the unchanged saved CreatorFlow Agent on Opus 5.5 each send a 3303910-character embedded image_url via LiteLLM chat/completions and accurately read the board's labels. Repeated saved-agent read and two-board/text-tool continuation pass. GPT Sol receives the original full JPEG and describes it accurately. The separate Anthropic endpoint was only a diagnostic workaround and is removed from the final deployment. Source PR #603 remains the same narrow shared sizing fix.
bickov commentedon Oct 10, 2026
This matches something on the screenshot side rather than the MCP transport side. Vision models already resize an oversized image down before they ever read it, and on a tall page that resize step alone can land the body text at roughly 1.4 pixels tall, unreadable long before your character bound even matters. Bounding the base64 length fixes the drop you found, but an image that passes the bound can still arrive at the model too small to read, so downscaling or tiling before that check would close the other half of the gap. I wrote the pixel math up on my blog, at slimsnap.ai/blog/screenshot-downscaling, if it's useful for sizing the fix.
ldavis9000aws commentedon Oct 14, 2026
Closing this report as not planned at the submitter's request while withdrawing PR #603. This is an administrative withdrawal, not a finding that the behavior is by design or that upstream has fixed it. The reported same-turn sizing defect remains supported by the reproduction below and is distinct from LibreChat's documented later-turn image omission. Preserve the technical record for any future maintainer investigation.