n8n [email protected] was published on July 16, 2026. Its one documented fix makes an execution mode mandatory for MCP workflow executions, turning implicit core context into an explicit requirement for callers. GitHub marks this as a regular release, not a prerelease.
The full release notes and downloads are on the GitHub release page.
Execution mode becomes part of the contract ¶
The fix is recorded in core issue #34281 and implemented by commit ea5319f. Both sources describe the same narrow change: MCP workflow executions must include an execution mode. No node changes, connector updates, or interface work are listed for this tag.
The core scope matters. This is an execution contract fix, not a presentation change. A caller can no longer depend on n8n accepting an MCP workflow execution without the required context. That is relevant to data pipelines that expose workflows to MCP clients, since request construction now has a stricter requirement.
The release notes do not name accepted mode values. They also do not document a fallback, a default, or the exact error returned when the mode is absent. Operators should use the contract already expected by their n8n deployment and verify it in staging. Guessing a value from this short changelog would turn a precise fix into an avoidable compatibility problem.
Operational impact stays narrow ¶
Only workflow executions created through MCP are explicitly covered. The notes do not report changes to webhook, scheduled, manual, or queue based execution. Broad pipeline retesting is therefore less useful than a focused check of each MCP client that can start a workflow.
A caller that already supplies the required execution mode should see no intended contract change. A caller that relied on missing or inferred context is the risk case. The release does not say whether incomplete input is rejected during request validation or later in execution setup, so the observed failure surface should be tested rather than assumed.
For observability, compare application logs and execution records before and after the upgrade. Confirm that a valid MCP request starts the expected workflow and that its execution appears with the expected context. This patch does not claim better throughput, lower latency, different retry behavior, or new workflow features. It is a correctness fix for how an MCP initiated run is described to core.
Upgrade notes ¶
n8n 2.30.6 is not labeled as a breaking release, and the notes provide no migration procedure. Even so, a newly required value can expose an older client or custom integration that sent an incomplete request. Treat the upgrade as a small contract migration if MCP is present in the execution path.
Inventory services and agents that start n8n workflows through MCP.
Capture the request shape they send and confirm that an execution mode is present.
Run one valid request against a staging instance on
[email protected].Run a negative check with the mode omitted and record where n8n reports the failure.
Check logs and execution records for unexpected starts, missing runs, or repeated client retries.
These checks keep the test scope tied to the only change in the release. If MCP is not used to start workflows, the published notes identify no feature or migration work for data pipeline owners.