Skip to content
n8n Help Center home
n8n Help Center home

MCP Server Trigger tool calls fail with "No bridge acquired for this context"

Overview

If tools called through an MCP Server Trigger fail with No bridge acquired for this context. Call acquire() first., the trigger node's version is the likely cause. Version 1.1 of the node resolves tool parameters through a path that fails when a tool parameter contains an expression. Replacing the node with version 2 resolves this for clients that connect over streamable HTTP, and it changes your MCP URL.

When this happens

All of the following are usually true:

  • Your MCP client connects successfully and can list the available tools. Only the tool calls themselves fail.

  • The error returned to the client is No bridge acquired for this context. Call acquire() first.

  • Your workflow uses an MCP Server Trigger (@n8n/n8n-nodes-langchain.mcpTrigger) at typeVersion 1.1.

  • The tools that fail pass parameters through expressions, for example $fromAI(), {{ $vars.MY_VAR }}, or any other {{ }} expression. Tools whose parameters are all static values keep working normally, so if some of your tools work and others do not, this is a strong signal.

  • In the n8n executions list, the failed calls may still appear as Success. To see the error, open the execution and select the tool node. The error appears in the node's output panel even though the execution is marked successful.

Before you start

Check your node version. Open the MCP Server Trigger, open the node's settings, and check the node version. You can also select the node on the canvas, copy it with Ctrl+C or Cmd+C, and paste it into a text editor to read the typeVersion value directly.

Check your n8n version. Version 2 of the node is only available on newer n8n versions. If your instance does not offer version 2, update n8n first. On n8n Cloud, update from your Admin Panel:

How To Update To The Latest Stable Version In N8n Cloud

Fix: replace the MCP Server Trigger node

  1. Note your current settings before deleting anything: the Path value, the Authentication method, and any credential selected on the trigger. You will need to set these again.

  2. Delete the existing MCP Server Trigger node from the canvas.

  3. Add a new MCP Server Trigger from the nodes panel. On a current n8n version this comes in as version 2.

  4. Confirm the new node is version 2. Select it, copy it, and paste it into a text editor to check that "typeVersion": 2 appears.

  5. Set the Path field back to your original path, for example <your previous path>. Keeping the same path keeps the rest of your URL unchanged.

  6. Reapply the Authentication method and reselect the credential if the original node used one.

  7. Reconnect every tool node to the new trigger.

  8. Save and publish the workflow.

Important: your MCP URL changes

Version 2 does not use the /sse suffix. Your URL changes like this:

Old, version 1.1: https://your-instance.app.n8n.cloud/mcp/your-path/sse

New, version 2: https://your-instance.app.n8n.cloud/mcp/your-path

Update every external connector to the new URL. The old /sse address stops responding after the change, so a connector left pointing at it will fail to connect.

Notes

  • On n8n Cloud, instance-level environment variables such as N8N_EXPRESSION_ENGINE cannot be changed by users or by support, so this is not an available fix.

  • On self-hosted n8n, this error only occurs when the experimental vm expression engine is active. Setting N8N_EXPRESSION_ENGINE=legacy, or removing the variable entirely since legacy is the default, also resolves it. See Expression engine.

  • A fix for version 1.1 is in progress. Replacing the node with version 2 is the immediate solution.

  • The same underlying behaviour can affect other components that connect over SSE, including the MCP Client Tool node. If you see this error outside an MCP Server Trigger, mention that when contacting support.

  • If a newly created workflow unexpectedly contains a version 1.1 trigger, tell us how it was created, for example by hand, from a template, with the AI workflow builder, or through an MCP client. That helps us track down what produced the older node version.

Still having trouble?

Test your tool calls after making the change and confirm your connectors point at the updated MCP URL. If calls still fail, contact support with your workflow JSON, with credentials and any sensitive values removed, plus your n8n version and the trigger node's typeVersion.

Powered by Plain