MCP bridge acquisition erro

Questions
1

Since early July, my MCP Server Trigger is returning ‘No bridge acquired’ on every tool call. The SSE endpoint is live, mcp-remote connects, but the bridge never initialises. Was working fine in late June. Cloud instance, workflow using Execute Workflow sub-workflows as MCP tools. Has anyone found a fix?

2

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

Suggested resources

Automatically matched to your question.

Docs:

Forum:

@Gonzalo_Romero_Herna, @Inshal_Amir, @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 @Munish_Gupta Welcome!
That string comes from n8n’s own expression evaluator and only fires when the experimental vm expression engine is active. The MCP Server Trigger resolves the tool parameters outside the isolate window that engine needs, so the session connects and the tools list fine while every call dies at hand-off with no sub-execution spawned. N8N_EXPRESSION_ENGINE is a self-hosted variable with no Cloud equivalent, so help@n8n.io has to check whether vm is enabled on your instance and put it back to legacy. Send them the workflow ID, the exact error string, and the detail that the call dies in milliseconds without spawning a child execution.
Until they switch it, expose the sub-workflows through instance-level MCP instead of the trigger node. Go to Settings > Instance-level MCP, enable access, turn on “Available in MCP” on each sub-workflow, then point your client at:

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

The client runs them with execute_workflow and passes the arguments straight through, so no $fromAI() expression in a tool node has to resolve. That tool runs the published version of the workflow.

4

Hi @Munish_Gupta, the word “bridge” in that error is misleading — it has nothing to do with the MCP transport bridge. It’s n8n’s V8 isolate bridge inside the expression evaluator, which is why every transport-level symptom looks healthy: SSE endpoint live, mcp-remote connecting, tools listing correctly. The transport layer is fine. The failure is downstream, at tool-parameter resolution.

Specifically: when the experimental vm expression engine is active, the MCP Server Trigger resolves the tool’s parameters outside the isolate window that engine requires, so the handshake and tools/list succeed while every tools/call dies before your sub-workflow ever starts.

Confirm it in about five minutes:

  1. Duplicate one of your tools.
  2. In the copy, replace every $fromAI() input with a hardcoded literal.
  3. Call both from your client.
  • Hardcoded works, $fromAI() fails → confirmed. It’s parameter resolution, not your sub-workflows.
  • Both fail → something else is going on; post the execution.

Also open a failing execution and look for this fingerprint: very short duration (tens of milliseconds), empty output, and no child execution spawned. If the sub-workflow execution never appears in the Executions list, it died at hand-off before your workflow ran at all.

Skip these — they look relevant but aren’t the cause: re-registering the connector, switching SSE → Streamable HTTP, reinstalling or re-pinning mcp-remote.

Since you’re on Cloud, N8N_EXPRESSION_ENGINE is a self-hosted environment variable with no Cloud equivalent and no UI toggle, so you can’t revert it yourself. Email help@n8n.io with:

  • your workflow ID and exact Cloud version
  • the exact error string
  • that tools list correctly but every call fails
  • that calls die in milliseconds with no child execution spawned
  • your hardcoded-vs-$fromAI() result

And ask them directly: “Is N8N_EXPRESSION_ENGINE set to vm on my instance? Please revert it to legacy.” Being that specific is what keeps it from getting routed into generic MCP troubleshooting.

Workaround while you wait: bypass the MCP Server Trigger entirely and expose the sub-workflows through instance-level MCP. Settings → Instance-level MCP → enable access, then switch on “Available in MCP” for each sub-workflow, and point your client at:

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

The client invokes them via execute_workflow and passes arguments straight through, so no $fromAI() expression has to resolve in a tool node. Two caveats: it runs the published version of each workflow, so save and publish first; and tool names and descriptions come from the workflow name/description rather than your tool node config, so your client’s tool list will look different from what you have now.

One thing that would help narrow this down — what exact Cloud version are you on? “Fine in late June, broken early July” probably brackets the release that turned this on for your instance.

5

We have taken a look at this and it looks like it might be fixed in a recent release, Please update and see if you are still running into the same problem.

6

Thanks guys. The issue was resolved on updating the n89 version.