MCP tools stop when workflows abort
MCP tool calls no longer consume tokens after a workflow fails or is cancelled. The execution engine's abort signal is now propagated to in-flight and pending tool calls, preventing unnecessary spend.
When a workflow execution fails or is cancelled, MCP tool nodes previously continued running and consuming tokens — leaving customers paying for tool calls that had no chance of affecting the outcome. The execution engine's abort signal was not reaching MCP tool calls, so in-flight and pending requests had no way to know the parent workflow had already errored out.
MCP tool nodes now check the execution cancel signal before starting work and pass that signal through to the underlying tool call layer. If the signal is already aborted when a tool call begins, or if it becomes aborted mid-flight, the tool exits cleanly rather than continuing to consume resources. The agent executor's invoke call also now passes execution options that include the abort signal.
The fix lives in the n8n-nodes-langchain package, specifically in the MCP client tool implementation and its utility functions. Test assertions were updated to verify that mid-flight aborts are handled correctly.
View Original GitHub Description
Summary
When a workflow execution fails or is cancelled, MCP tool nodes continued to execute and consume tokens. This was reported by a customer observing unnecessary token spend from MCP tool calls that fired after the parent agent had already errored out.
Root cause: The abort signal from the execution engine was not propagated to MCP tool calls, so in-flight and pending calls had no way to know the execution was already cancelled.