Bug Description / Feature Request
The AI Agent node (@n8n/n8n-nodes-langchain.agent) re-establishes the MCP connection and re-fetches tools/list from every attached MCP Client Tool sub-node before every model call within a single execution. With multiple MCP tool sub-nodes attached, this adds a large, fixed dead-time cost to every agent iteration, dominating wall-clock time for multi-turn agent runs.
We measured this with a controlled dose-response experiment (details below): each attached MCP Client Tool sub-node costs ≈7.0 seconds per model call, independent of the size of the server's tool list. At 10 attached MCP sub-nodes, an agent spends ≈60s of dead time before every single model call — a 20-turn agent run pays ~20 minutes of pure reconnect/listTools overhead.
Measurements (n8n 2.36.8, self-hosted)
Four byte-identical clones of a production agent workflow, differing only in the number of attached MCP Client Tool sub-nodes (all httpStreamable, OAuth2, pointing at healthy HTTP MCP servers). Identical synthetic 5-model-call task, 8 interleaved runs per variant (32 runs, 128 inter-call gap samples). Per-turn dead gap = time between consecutive model calls minus tool execution time within the window:
| MCP tool sub-nodes attached |
median inter-call dead gap (s/turn) |
IQR |
| 0 |
0.10 |
0.09–0.11 |
| 2 |
12.26 |
10.3–18.4 |
| 5 |
32.04 |
23.9–39.0 |
| 10 |
60.29 |
40.5–97.4 |
Linear fit: gap_s = 6.96 × n_tools + 0.26 (R² = 0.67 over all 128 samples). Model latency stayed flat (~1.4s) across variants — the cost is entirely in the per-iteration MCP connect + tools/list round trips. The marginal per-node cost was uniform across small (3-tool) and large (~70-tool) servers — it's connection/handshake overhead, not schema byte size.
The 0-node floor of 0.10s/turn shows the agent loop itself is essentially free; the entire dead time is attributable to per-iteration MCP session re-establishment.
We confirmed the mechanism by consolidating the 10 MCP sub-nodes into 1 (an aggregating MCP endpoint exposing the same tools): median per-turn dead gap dropped from ~46–60s to ~3.4–5.9s on the same workflow — matching the fit's prediction for n=1.
Suggested improvement
Cache the MCP client connection and tools/list result per execution (or with a short TTL), instead of reconnecting and re-listing before every model call in the agent loop. Tool schemas essentially never change mid-execution; a per-execution cache would eliminate this term entirely for every n8n AI Agent user with MCP tools attached. An opt-out (or listChanged notification support) could cover servers with genuinely dynamic tool lists.
To Reproduce
- Create an AI Agent workflow with a chat/LLM model and attach N MCP Client Tool sub-nodes (HTTP streamable transport) pointing at any healthy MCP servers.
- Give the agent a scripted task requiring ~5 sequential tool calls (one per turn).
- Inspect the execution timeline: measure the wall-clock gap between consecutive model calls and subtract tool execution time.
- Repeat with different N. The dead gap scales linearly with N (~7s per attached MCP sub-node per model call in our environment).
Expected behavior
Per-iteration overhead should be independent of the number of attached MCP tool sub-nodes (connect + listTools paid once per execution, not once per model call).
Environment
Bug Description / Feature Request
The AI Agent node (
@n8n/n8n-nodes-langchain.agent) re-establishes the MCP connection and re-fetchestools/listfrom every attached MCP Client Tool sub-node before every model call within a single execution. With multiple MCP tool sub-nodes attached, this adds a large, fixed dead-time cost to every agent iteration, dominating wall-clock time for multi-turn agent runs.We measured this with a controlled dose-response experiment (details below): each attached MCP Client Tool sub-node costs ≈7.0 seconds per model call, independent of the size of the server's tool list. At 10 attached MCP sub-nodes, an agent spends ≈60s of dead time before every single model call — a 20-turn agent run pays ~20 minutes of pure reconnect/listTools overhead.
Measurements (n8n 2.36.8, self-hosted)
Four byte-identical clones of a production agent workflow, differing only in the number of attached MCP Client Tool sub-nodes (all
httpStreamable, OAuth2, pointing at healthy HTTP MCP servers). Identical synthetic 5-model-call task, 8 interleaved runs per variant (32 runs, 128 inter-call gap samples). Per-turn dead gap = time between consecutive model calls minus tool execution time within the window:Linear fit:
gap_s = 6.96 × n_tools + 0.26(R² = 0.67 over all 128 samples). Model latency stayed flat (~1.4s) across variants — the cost is entirely in the per-iteration MCP connect +tools/listround trips. The marginal per-node cost was uniform across small (3-tool) and large (~70-tool) servers — it's connection/handshake overhead, not schema byte size.The 0-node floor of 0.10s/turn shows the agent loop itself is essentially free; the entire dead time is attributable to per-iteration MCP session re-establishment.
We confirmed the mechanism by consolidating the 10 MCP sub-nodes into 1 (an aggregating MCP endpoint exposing the same tools): median per-turn dead gap dropped from ~46–60s to ~3.4–5.9s on the same workflow — matching the fit's prediction for n=1.
Suggested improvement
Cache the MCP client connection and
tools/listresult per execution (or with a short TTL), instead of reconnecting and re-listing before every model call in the agent loop. Tool schemas essentially never change mid-execution; a per-execution cache would eliminate this term entirely for every n8n AI Agent user with MCP tools attached. An opt-out (orlistChangednotification support) could cover servers with genuinely dynamic tool lists.To Reproduce
Expected behavior
Per-iteration overhead should be independent of the number of attached MCP tool sub-nodes (connect + listTools paid once per execution, not once per model call).
Environment
supplyData()— same code path; a per-execution connection cache would also narrow that failure window)