Um workflow n8n de 100+ nós custa uma fortuna em tokens para um LLM ler direto
A maioria das pessoas nem sabe até onde isso escala mal. Eu fui medir.
resumo
Um workflow n8n com 100+ nós não cabe no contexto de um LLM quando lido via MCP direto (erro de teto de tokens, sem fallback) — porque cada nó carrega muito mais metadado de armazenamento (posição no canvas, UUID, typeVersion) do que decisão de negócio real. Um redutor determinístico que separa as duas coisas corta ~84% dos tokens (de ~59.800 para ~9.750) sem perder nenhuma condição, query ou prompt.
Testei os dois caminhos de leitura, no mesmo fluxo em produção, no mesmo instante.
A via direta trava antes de começar
Pela via direta (MCP get_workflow_details, o caminho padrão), o fluxo nem chegou a entrar no contexto. Erro de teto de tokens: result exceeds maximum allowed tokens. Sem fallback, sem forma de contornar.
A partir de certo tamanho, ler o workflow inteiro para raciocinar sobre ele deixa de ser “mais caro” e passa a ser impossível.
A causa é estrutural, não acidente de escala
Cada nó de um export n8n carrega muito mais metadado de armazenamento do que decisão de negócio: coordenada no canvas, typeVersion, UUID de credencial, options: {} vazio. Em 100+ nós, isso domina o JSON.
Um redutor que sabe separar as duas coisas
Escrevi um redutor determinístico (~400 linhas, zero dependências) que separa as duas categorias:
- ✓Mantém condição de IF, query de Postgres, prompt de agente, URL de HTTP Request
- ✓Resolve a topologia de conexões (incluindo a fiação invertida dos sub-nós de IA do n8n)
- ✓Descarta tudo que é metadado de armazenamento
O resultado, no mesmo dump
Rodei o mesmo dump pelos dois caminhos: 239.270 caracteres brutos (~59.800 tokens, estimativa por chars/4) caíram para 38.978 (~9.750 tokens).
bruto
~59.800
tokens
reduzido
~9.750
tokens
economia
−84%
O que fica
O número é secundário. O que fica: contexto de LLM não é problema de tamanho, é problema de sinal-ruído. A pergunta certa não é “como caibo mais”. É “o que aqui é decisão e o que é metadado”.
Um redutor que sabe essa diferença por tipo de nó bate um resumo de LLM: mesmo input, mesma saída, sempre.
Perguntas
Por que um workflow n8n grande quebra o contexto de um LLM?
Porque cada nó de um export n8n carrega muito mais metadado de armazenamento (coordenada no canvas, typeVersion, UUID de credencial, options vazio) do que decisão de negócio real. Em workflows com 100+ nós, esse metadado domina o JSON e o volume de tokens ultrapassa o teto permitido antes mesmo do LLM começar a raciocinar sobre o conteúdo.
O que acontece ao ler um workflow n8n grande via MCP direto?
A chamada get_workflow_details falha com o erro "result exceeds maximum allowed tokens", sem fallback e sem forma de contornar. A partir de certo tamanho, ler o workflow inteiro não fica só mais caro — fica impossível.
Quanto um redutor determinístico consegue reduzir o tamanho de um workflow n8n?
No teste medido, 239.270 caracteres brutos (~59.800 tokens) caíram para 38.978 caracteres (~9.750 tokens) — uma redução de 84%, preservando toda condição de IF, query de Postgres, prompt de agente e URL de HTTP Request.
Qual a diferença entre reduzir contexto de LLM com um script e com um resumo gerado por outro LLM?
Um redutor determinístico que sabe separar decisão de negócio de metadado de armazenamento por tipo de nó produz sempre o mesmo output para o mesmo input. Um resumo gerado por LLM não tem essa garantia — pode variar entre execuções e omitir detalhes de forma inconsistente.