A 100+ node n8n workflow costs a fortune in tokens for an LLM to read directly
Most people don’t know how badly this scales. I went and measured it.
summary
A 100+ node n8n workflow doesn’t fit into an LLM’s context when read straight through MCP (token ceiling error, no fallback), because every node carries far more storage metadata (canvas position, UUID, typeVersion) than actual business decisions. A deterministic reducer that separates the two cuts ~84% of the tokens (from ~59,800 to ~9,750) without losing a single condition, query, or prompt.
I tested both reading paths, on the same production flow, at the same instant.
The direct path fails before it even starts
Through the direct path (MCP get_workflow_details, the default route), the flow never even made it into context. A token ceiling error: result exceeds maximum allowed tokens. No fallback, no way around it.
Past a certain size, reading the entire workflow to reason about it stops being “more expensive” and becomes impossible.
The cause is structural, not an accident of scale
Every node in an n8n export carries far more storage metadata than business decisions: canvas coordinates, typeVersion, credential UUID, empty options: {}. At 100+ nodes, that dominates the JSON.
A reducer that knows how to tell the two apart
I wrote a deterministic reducer (~400 lines, zero dependencies) that separates the two categories:
- ✓Keeps IF conditions, Postgres queries, agent prompts, HTTP Request URLs
- ✓Resolves the connection topology (including n8n’s inverted wiring for AI sub-nodes)
- ✓Discards everything that is storage metadata
The result, on the same dump
I ran the same dump through both paths: 239,270 raw characters (~59,800 tokens, estimated at chars/4) dropped to 38,978 (~9,750 tokens).
raw
~59,800
tokens
reduced
~9,750
tokens
savings
−84%
What actually matters
The number is secondary. What matters: LLM context isn’t a size problem, it’s a signal-to-noise problem. The right question isn’t “how do I fit more in”. It’s “what here is a decision, and what is metadata”.
A reducer that knows that difference by node type beats an LLM summary: same input, same output, every time.
Questions
Why does a large n8n workflow break an LLM's context?
Because every node in an n8n export carries far more storage metadata (canvas coordinates, typeVersion, credential UUID, empty options) than actual business decisions. In workflows with 100+ nodes, that metadata dominates the JSON, and the token volume exceeds the allowed ceiling before the LLM even starts reasoning about the content.
What happens when you read a large n8n workflow directly through MCP?
The get_workflow_details call fails with the error "result exceeds maximum allowed tokens", with no fallback and no way around it. Past a certain size, reading the whole workflow doesn't just get more expensive. It becomes impossible.
How much can a deterministic reducer shrink an n8n workflow?
In the measured test, 239,270 raw characters (~59,800 tokens) dropped to 38,978 characters (~9,750 tokens): an 84% reduction, preserving every IF condition, Postgres query, agent prompt, and HTTP Request URL.
What's the difference between reducing LLM context with a script versus a summary generated by another LLM?
A deterministic reducer that knows how to separate business decisions from storage metadata by node type always produces the same output for the same input. An LLM-generated summary has no such guarantee: it can vary between runs and omit details inconsistently.