Title: MCP Server Trigger (v2) — every tool call fails with "No bridge acquired for this context. Call acquire() first."

Questions
,
1

Hi all,

My MCP Server Trigger connects fine and lists all its tools correctly, but every actual tool call fails with:

There was an error: “No bridge acquired for this context. Call acquire() first.”

Key detail — the failure is at the tool-invocation/bridge layer, not in my sub-workflow:

  • The tool’s sub-workflow runs to completion and succeeds when executed standalone (full chain, correct output).
  • Called via the MCP Server Trigger, the Call n8n Workflow Tool node returns the error with empty output, the execution finishes in ~42ms, and no child/sub-workflow execution is spawned — it dies at hand-off, before the sub-workflow runs.

So the sub-workflow itself is fine; the fault reproduces only through MCP.

This matches a known report where the experimental VM expression engine (N8N_EXPRESSION_ENGINE=vm) resolves MCP tool parameters outside the required isolate (“acquire()”) window — sessions connect and tools list fine, but every tool call dies with this exact error:

Setup:

  • n8n Cloud (latest)
  • MCP Server Trigger (@n8n/n8n-nodes-langchain.mcpTrigger) v2
  • Call n8n Workflow Tool (@n8n/n8n-nodes-langchain.toolWorkflow) v2.2, using $fromAI inputs

Questions:

  1. Why does the tool call fail with “No bridge acquired” through the MCP Server Trigger even though the sub-workflow succeeds standalone?
  2. Is this the experimental VM expression engine? On n8n Cloud, is N8N_EXPRESSION_ENGINE something I can change, or does it need n8n support to revert to legacy?
  3. Any known workaround for MCP Server Trigger v2 in the meantime?

Thanks!

2

Hey @Sohaib_Ibne_Ali, while you wait for a response, here are some things that might help:

Suggested resources

Automatically matched to your question.

Docs:

Forum:

@Anshul_Namdev, @tamy.santos, @Patrik_Breitenmoser - you’ve helped with similar issues before, can you take a look?

Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.

3

Hi @Sohaib_Ibne_Ali Welcome!
N8N_EXPRESSION_ENGINE is a self-hosted environment variable with no Cloud equivalent and no UI toggle, so moving your instance back to legacy is not something you can do yourself. help@n8n.io can check whether the vm engine is active on your instance and switch it. Send them the workflow ID, the exact error string, and the detail that tools list fine while every call dies in ~42ms with no sub-execution spawned, that pins it to parameter resolution.
In the meantime, drop the MCP Server Trigger and expose the sub-workflow through instance-level MCP instead. Go to Settings > Instance-level MCP, enable access, turn on “Available in MCP” on the sub-workflow, then point Claude at:

https://<your-n8n-domain>/mcp-server/http

The client runs it with execute_workflow and passes the arguments straight through, so no $fromAI() expression in a tool node has to resolve.

4

hi @Sohaib_Ibne_Ali welcome to the n8n community!

Before digging deeper, could you confirm your exact n8n version (with print if possible), whether you’re running in queue mode, and whether the issue still occurs after upgrading to a version that includes the recent expression isolate fixes and the MCP Trigger tool calls in queue mode fix?

5

If the Call n8n Workflow Tool continues to fail, use the AI Agent node as the “Brain” and the Workflow Tool as the tool.

  • Instead of the MCP Trigger → Tool Workflow path, use: MCP Trigger → AI Agent → Workflow Tool.
  • The AI Agent node manages its own context bridge more robustly than the direct Trigger-to-Tool hand-off.