Skip to content
NewsProduct launch

n8n 2.40 brings MCP toolkit execution to queue-mode workers and adds Confluence as a native agent tool

· by Pondero Newsdesk

The short version

Released September 15, n8n 2.40 lets MCP tool calls run on distributed queue-mode workers for the first time, adds Confluence as an AI agent tool, and ships a force-tool-call option for smaller models that skip wired tools in prose.

n8n 2.40 brings MCP toolkit execution to queue-mode workers and adds Confluence as a native agent tool

n8n released version 2.40 on September 15, 2026, and the most operationally significant addition removes a scaling ceiling: MCP tool calls can now execute on distributed worker processes, not just the main n8n instance, per the official release notes.

What changed

n8n's queue mode assigns execution work to separate worker processes, keeping the main process free for routing. Before 2.40, MCP toolkit members ran only on that main process. Self-hosted teams running production automation stacks in queue mode had a single bottleneck for every MCP tool call. Version 2.40 closes the gap: MCP toolkit members now execute on workers the same way any other workflow node does, per the GitHub release.

A second MCP fix addresses data fidelity. Updates to MCP workflows were silently dropping operation fields that the server did not recognize, which could corrupt a workflow configuration if the MCP client sent extended metadata. The 2.40 fix preserves all operation fields through update cycles.

Two additions round out the September agent-tool changes. Confluence is now a fully public node and can be used as a tool by AI Agents, letting agents create, read, and manage Confluence pages inside a workflow. The node was previously hidden behind a feature flag.

The AI Agent node (v3) gained a "Force Tool Call on First Iteration" option. When enabled, the model must call a tool on its first response of a run. That targets a recurring failure pattern with smaller models: Mistral-Small on IONOS, local Ollama deployments, and vLLM instances often respond in prose on the first turn and skip the wired tools entirely. The option resolves that without changing the model or rewriting prompts. Later iterations remain unrestricted so the agent can still produce a final answer. The option is off by default, leaving existing workflows unaffected.

n8n also added a fallback model option for AI nodes. If the primary model is unavailable, the node falls back to a secondary rather than failing the execution outright.

Why it matters

The worker-distribution change shifts the deployment math for operators running MCP in production. Queue mode with multiple workers is the standard n8n architecture for high-volume automation. Being unable to distribute MCP tool calls across workers either forced a single-process workaround or capped throughput at the main instance. That constraint is gone in 2.40.

The force-tool-call option is a low-friction fix for a reliability gap that often shows up late in deployment. A smaller model added to an agent workflow can appear to work in testing while silently skipping tools under production load. Enabling the option per-node adds a reliable first-turn tool engagement with no model swap required.

Confluence as a native agent tool closes an integration gap for teams whose knowledge base lives in Atlassian. AI agents can now query and update Confluence pages directly, without a custom HTTP Request node standing in.

What to watch next

The n8n 2.32 release from July 21, 2026, shipped MCP OAuth consent improvements: operators can select specific access scopes at consent time and see which client (Claude, Cursor, VS Code) holds each connected session, with brand icons in the connected-clients list. Combined with the 2.40 worker-distribution change, the two releases together address both the access-control and the execution-scale sides of a production MCP deployment.

Whether n8n publishes updated deployment documentation specifically for queue-mode MCP setups is the near-term gap to watch.

Sources