MCP Server (n8n Cloud) not working in Claude Desktop

Questions
1

Dear all,

I hope someone can help me figure out my problem with the MCP server. I have a very simple MCP server on n8n cloud, the MCP server is working with all other tools, I can connect from Cursor, or from the mcp inspector, but every time I try to connect from Cloud Desktop, the connection breaks. I’ve tried a hundred things already, but I could not figure out what the problem is. I really hope someone can help me fix this.
Thank you so much

here the logs:
2025-05-21T16:21:49.213Z [n8n_net] [info] Initializing server…
2025-05-21T16:21:49.240Z [n8n_net] [info] Server started and connected successfully
2025-05-21T16:21:49.243Z [n8n_net] [info] Message from client: {“method”:“initialize”,“params”:{“protocolVersion”:“2024-11-05”,“capabilities”:{},“clientInfo”:{“name”:“claude-ai”,“version”:“0.1.0”}},“jsonrpc”:“2.0”,“id”:0}
[supergateway] Starting…
[supergateway] Supergateway is supported by Supermachine (hosted MCPs) - https://supermachine.ai
[supergateway] - outputTransport: stdio
[supergateway] - sse: https://lionstep-ag.app.n8n.cloud/mcp/89752b04-5908-4a4f-b2e5-98ea0cf68e31/sse
[supergateway] - Headers: (none)
[supergateway] Connecting to SSE…
[supergateway] Stdio server listening
[supergateway] Stdio → SSE: {
jsonrpc: ‘2.0’,
id: 0,
method: ‘initialize’,
params: {
protocolVersion: ‘2024-11-05’,
capabilities: {},
clientInfo: { name: ‘claude-ai’, version: ‘0.1.0’ }
}
}
[supergateway] SSE connected
[supergateway] Response: {
jsonrpc: ‘2.0’,
id: 0,
result: {
protocolVersion: ‘2025-03-26’,
capabilities: { tools: {} },
serverInfo: { name: ‘n8n-mcp-server’, version: ‘0.1.0’ }
}
}
2025-05-21T16:21:50.326Z [n8n_net] [info] Message from server: {“jsonrpc”:“2.0”,“id”:0,“result”:{“protocolVersion”:“2025-03-26”,“capabilities”:{“tools”:{}},“serverInfo”:{“name”:“n8n-mcp-server”,“version”:“0.1.0”}}}
2025-05-21T16:21:50.327Z [n8n_net] [info] Client transport closed
[supergateway] Caught SIGTERM. Exiting…
2025-05-21T16:21:50.327Z [n8n_net] [info] Server transport closed
2025-05-21T16:21:50.327Z [n8n_net] [info] Client transport closed
2025-05-21T16:21:50.327Z [n8n_net] [info] Server transport closed unexpectedly, this is likely due to the process exiting early. If you are developing this MCP server you can add output to stderr (i.e. console.error('...') in JavaScript, print('...', file=sys.stderr) in python) and it will appear in this log.
2025-05-21T16:21:50.328Z [n8n_net] [error] Server disconnected. For troubleshooting guidance, please visit our debugging documentation {“context”:“connection”}
2025-05-21T16:21:50.340Z [n8n_net] [info] Server transport closed
2025-05-21T16:21:50.340Z [n8n_net] [info] Client transport closed

1 Like
2

Also can connect from an mcp client in n8n to the server. Also i’ve updated to the latest n8n Version

3

I have exactly the same issue (though self hosting n8n on Hetzner VPS). On a side note I don’t understand how the MCP test is supposed to be achieved (using the test URL provided in the node configuration)

4

@homebugs I’ve seen that on local deployment a lot of people had problems with requests being gzipped. Just in case you did not see this before.

5

Ok it looks like a bug in the latest n8n version. Version 1.92.2 is still working

1 Like
6

I have the same issue, I used chrome dev tool to try to deep dive into the issue. It seems to be a protocol version incompatibility between the MCP client (Claude) and the MCP server ( n8n) , but i don’t lnow how to solve it

1 Like
7

god help me how many things I have tried, but glad I’m not alone.

1 Like
8

+1 same issue

9

N8N should really resolve this ASAP. Glad to know no problem from my side.

10

Latest as in 1.93? beta?

11

I have found a solution for the problem if you are on a self-hosted plan. There was a change in protocol at version 1.93.0 and after that, it looks like the problem appeared.

Due to my research, there are two cases where this can fail:

One is having the communication to the server gzipped. I saw a lot of people having this issue, and with just changing how the traffic flows could resolve it.

The other is my case where newer versions just kill the functionality. In that case, just go back to a version before 1.93.0 and you should be good. Hopefully, n8n will soon patch this.

2 Likes
12

+1 same cloud

13

We cannot downgrade the n8n hosted cloud to version 1.92; downgrading is not a solution for n8n cloud hosting paying customers.

By the way, it works fine in VS Code and Windsurf, so I am unsure where it breaks with Claude Desktop, but Claude is receiving capabilities: { tools: {} }, which is incorrect …

1 Like
14

Same problem here. I see in the claude desktop log file that client uses protocol version 2024-11-05 but server now 2025-03-26. Beforehand both used 2024-11-05.
N8N version is 1.93.0.
What can I do?

1 Like
15

+1

having the same issue here, insane n8n hasn’t fixed this lol. Claude is probably the number 1 MCP client out there lmao

@n8n please fix this! On v1.94.1 and same issue.

2 Likes
16

I’m on version 1.94.0 with the same issue

1 Like
17

I believe there is a git issue here on this: After upgrading to 1.93.0, claude desktop cannot connect to MCP properly · Issue #15732 · n8n-io/n8n · GitHub

1 Like
18

worked!
thanks!

19

I am new to this

in the following.
I understand that I replace URL → with workflow production URL
TOKEN → with a Bearer token I create in n8n

Is that it? And is --sse no longer needed?

Thanks for the help.

{
  "mcpServers": {
    "n8n": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "<URL>",
        "--header",
        "Authorization: Bearer ${AUTH_TOKEN}"
      ],
      "env": {
        "AUTH_TOKEN": "<TOKEN>"
      }
    },
  }
}```
20

Thank you very much. Now it works.

If you want to test without authorization, claude_desktop_config.json would look like this (intention missing)

{
“mcpServers”: {
“n8n”: {
“command”: “npx”,
“args”: [
“mcp-remote”,
“same-url-as-before”
]
}
}
}