Describe the problem/error/question
I am using the new Instance-level MCP integration in n8n together with OpenAI’s Developer Mode (Tools / MCP host).
-
When I call text-only workflows through MCP, everything works perfectly.
-
The problem appears when I call a workflow that includes an HTTP Request node calling Google Gemini’s Nano Banana image model, which returns base64-encoded image data.
Inside my n8n workflow, I:
-
Receive the base64 image result from Gemini,
-
Process it (convert/upload it to an image hosting service),
-
And ensure that the final node output is only a small JSON with an image URL, for example:
{
"image_url": "https://…/generated.png",
"prompt": "some christmas card prompt"
}
From the workflow designer’s perspective, there should be no large binary data left in the final output.
However, when this workflow is executed via Instance-level MCP from OpenAI Developer Mode, I observe:
-
The OpenAI MCP tool call response becomes extremely slow,
-
The conversation context in OpenAI is effectively “blown up”,
-
The LLM quickly hits context limits and begins with hullucination answers.
By contrast, the same MCP setup with text-only workflows does not show this behavior.
Because I don’t have direct visibility into the exact JSON that n8n returns to the MCP host, I can’t definitively prove it, but:
Based on the behavior, it is a strong hypothesis that the MCP execution response currently includes full workflow run data, including intermediate nodes with base64/binary content (e.g. the raw Gemini image result), even though the last node returns only a small JSON.
For workflows that involve image generation or any binary payload, this behavior makes the MCP integration practically unusable with LLMs, because the host (OpenAI) tries to load all of that internal data into the model’s context window.
What is the error message (if any)?
There is no explicit error from n8n.
On the OpenAI side, the symptoms are:
-
Tool responses that appear too large,
-
Context being exhausted very quickly after a single tool call,
-
In some cases, behavior consistent with truncated responses or the model silently dropping parts of the tool output.
So this is not a runtime crash in n8n, but rather a payload-size / context-limit issue on the LLM host side, very likely caused by the size of the MCP response.
Please share your workflow
Share the output returned by the last node
Information on your n8n setup
- n8n version: Version 1.121.3
- Database (default: SQLite): SQLITE
- n8n EXECUTIONS_PROCESS setting (default: own, main): main
- Running n8n via (Docker, npm, n8n cloud, desktop app): Hostinger, docker
- Operating system: Ubuntu 24
