Librechat does not support image content from MCP tool's return

[Fritsl]

What happened?

Although issue #6951 was marked as fixed, LibreChat still does not correctly render image content returned from MCP tools. When using the official E2B MCP server
with LibreChat, image outputs (e.g. PNG plots generated by Python code) are displayed as long base64 text blobs in the chat window rather than as images.

Expected behavior
LibreChat should detect image content (e.g. content: [{ type: "image_url", image_url: { url: "data:image/png;base64,..." } }] or similar) returned by MCP tools and render it inline as an or Markdown image, instead of dumping the raw base64 string.

Version Information

{
"type": "text",
"text": "{\n "results": [\n {\n "text": "<PIL.Image.Image image mode=RGBA size=1000x500>",\n "png": "iVBORw0KGgoAAAANSUhEUgAAA+gAAAH0CAYAAACuKActAAC/P0lEQVR4Ae2dBZxdxdmH30124+4OCRI0wSG4ayluxQu0FHcKLV6gFCkUh2Jtv+KFFvcQnCBBEyQQ4u5u95v/7M5yd7N2dc+595nfb/fee86cmXeeuXLemVdKEq4YBQIQgAAEIAABCEAAAhCAAAQgAIFGJdCkUXuncwhAAAIQgAAEIAABCEAAAhCAAAQ8ARR03ggQgAAEIAABCEAAAhCAAAQgAIEIEEBBj8AkIAIEIAABCEAAAhCAAAQgAAEIQAAFnfcABCAAAQhAAAIQgAAEIAABCEAgAgRQ0CMwCYgAAQhAAAIQgAAEIAABCEAAAhBAQec9AAEIQAACEI.......

Steps to Reproduce

Connect LibreChat to the E2B MCP server.

Run Python code that generates a plot and saves it as PNG (the MCP server returns the PNG as base64).

Observe the LibreChat UI: the PNG is shown as a long base64 string instead of an image.

What browsers are you seeing the problem on?

Firefox

Relevant log output

n/a

Screenshots

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[danny-avila]

It's working as expected. Your MCP server is not returning the proper format for images as we can see in your output:

{
"type": "text",
"text": "{\n "results": [\n {\n "text": "<PIL.Image.Image image mode=RGBA size=1000x500>",\n "png": 

Should be image type.

See the following for more information:

• https://modelcontextprotocol.io/specification/2025-06-18/server/tools#image-content
• https://www.librechat.ai/docs/features/image_gen#5--model-context-protocol-mcp

---

[agapara]

This was working correctly for me up to LibreChat version 8.0. The issue only started appearing in more recent versions, where the image is no longer rendered as chat content nor displayed inside the tool response, even though the tool executes successfully.

What makes this clearer is that the exact same MCP server and tool implementation works correctly in Claude Desktop, where the image is properly rendered inside the tool response.

The MCP server implementation I’m using is based on the example from StacklokLabs/plotting-mcp. In older LibreChat versions, the image output (PNG/base64) returned by the tool was correctly interpreted and rendered. In recent versions, however, the response is shown as plain text instead of being treated as image content.

I’ve verified that the MCP server, response format, and configuration are identical in both cases, and the only variable is the LibreChat version. This suggests a regression or a change in how LibreChat parses and classifies MCP tool responses containing image content.

[danny-avila]

Working fine on my end (on latest). Which provider/model are you using?

mcpServers:
  plotting:
    command: uvx
    args:
      - --from
      - /home/danny/plotting-mcp
      - plotting-mcp
      - --transport=stdio

[agapara]

Thanks a lot for checking this so quickly and for confirming that it works on your end — really appreciate you taking the time to test it.

From my side, there are two clear differences compared to your setup, and I’m not sure to what extent they may be contributing to the issue:

Transport: instead of using stdio, I’m using streamable-http, which is a hard requirement in my case and not something I can switch away from.

Providers / models: I’ve tested this with multiple providers — Mistral, DeepInfra, and Nebius — and with several different models on each of them.

What makes this confusing is that with these exact same conditions (streamable-http + those providers/models), everything was working correctly up to LibreChat version 8.0. The issue only started appearing in more recent versions, where the image output is no longer rendered in the chat or within the tool response.

[agapara]

I’ve done an additional test that might help narrow this down.

When using Google directly as the provider, the image renders correctly in LibreChat. However, when using the same Gemini model via DeepInfra as the provider, the image does not render, even though the MCP server and tool response are identical.

Given that the model itself is the same, this seems to suggest that the difference lies in how the provider’s response is handled or normalized before being passed to the UI.

I’d be interested in understanding why this happens, as being able to use different providers is important in my setup.

[forsandree]

This issue persists because the fix in #6951 addressed MCP image rendering but not the underlying token explosion.

I've traced the root cause to ensureThinkingBlockInMessages() in @librechat/agents (src/messages/format.mjs). When using thinking-enabled models (Claude with extended thinking), if the model makes tool calls without first producing a thinking block, the function serializes the entire message sequence — including base64 image data — to a plain text string via getBufferString().

This means a single MCP image that should cost ~1,200 native image tokens instead costs ~214,000 text tokens (174× amplification), immediately exceeding context limits.

Workaround: Instruct the agent (via system prompt) to always produce a thinking block before tool calls and to avoid parallel tool calls when image tools are involved. This prevents the destructive code path from triggering.

I've filed a detailed issue on danny-avila/agents with reproduction steps and a suggested fix.

[danny-avila]

Thanks for highlighting this, I have a fix: danny-avila/agents#71