Hi, I have setup a custom MCP connector allowing users in Claude to access Workday data. I set this up by using the n8n to Workday api setup that I had previously. The connection from claude to n8n to call the MCP Server Connector is working, however it is not registering the tool call the user entered in Claude and thus the call to tool to return the results is not working. The error message in Claude is “No bridge acquired for this context. Call acquire() first.”
can anyone help?
Hi @jamiemcc
“No bridge acquired for this context. Call acquire() first.” — is actually an n8n internal bug, not a Claude-side or MCP protocol issue, so the fix is on your n8n workflow side rather than the connector itself.
In your case, this is almost certainly happening inside the n8n workflow that sits behind your MCP Server Trigger — likely in whichever node parses/builds the tool call parameters coming from Claude (a Code node, Set node with expressions, or the Basic LLM Chain/AI Agent node), before it maps them to your Workday API call.
It will be helpful if you can share which node type is throwing the error in your Executions log (Code node, Set node, HTTP Request, or the MCP Trigger’s own tool schema)
Can you try these?
1)Check if your n8n MCP Server Trigger node has a Streamable HTTP option (recent n8n versions added this alongside SSE) — switch to it if available, since Claude’s claude mcp add --transport http in your setup notes suggests you may already be trying HTTP but the underlying trigger might still be SSE-only internally
2)Update n8n to the latest version
3)Re-register the connector in Claude from scratch rather than reusing the old registration — stale session/transport negotiation cached from before the deprecation can cause exactly this “connects but doesn’t route” symptom.
4)Inspect n8n’s execution log for the MCP Server Trigger during a failed Claude call — if the trigger fires but no downstream Tool node executes, the tool-name-to-node mapping (session/routing layer) is breaking, not your Workday logic itself.
5)If self-hosted behind a reverse proxy (Nginx/Traefik/Caddy), confirm gzip/buffering is disabled specifically for streamable HTTP endpoints too, not just /sse — this is a common regression point when transport changes
6)As a workaround, try mcp-remote as a local bridge (npx mcp-remote <url> --transport http-first) instead of Claude’s native SSE URL, since it auto-negotiates transport and has fixed similar breakages for other providers during this same migration window.
Can you confirm what n8n version you’re currently running, and whether your MCP Server Trigger node shows a transport-type option (SSE vs Streamable HTTP) in its settings?
Version is - 2.31.5
I am on SSE. I will switch to SSE
Hi @jamiemcc
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’s parameters outside the isolate window that engine requires, so the session connects and the tools list fine while every actual tool call dies. Put the engine back on the default and restart:
N8N_EXPRESSION_ENGINE=legacy
Removing the variable entirely does the same thing, legacy is the default. It’s a self-hosted setting, so if you’re on Cloud, help@n8n.io can tell you whether the vm engine is enabled on your instance.
I also encounter the same problem. With claude_desktop_config.json as below:
{
“mcpServers”: {
“n8n”: {
“command”: “npx”,
“args”: [
“-y”,
“supergateway”,
“–sse”,
“https://xxxxxx.app.n8n.cloud/mcp/xxxxxxxx”
]
}
}
I can view the connectors in claude.
BUt with below error in n8n. Anyone know how to fix that? Appreciate for your info.
