til

n8n MCP 404 in Claude Code? The endpoint is /sse on a v1 trigger

TL;DR To use your n8n workflows as tools inside Claude Code, add an MCP Server Trigger node, connect a tool node to it over the ai_tool connection, and activate the workflow. Then point Claude Code at the SSE endpoint: on n8n 2.29 with a v1 MCP Server Trigger the URL is http://host:5678/mcp/{path}/sse, not /mcp/{path} (that 404s). Register it with claude mcp add --transport sse. Separate concern: n8n-as-a-server (this post) is the opposite of czlonkowski/n8n-mcp, which lets Claude build workflows for you.

#claude-code #n8n #mcp #automation #ai-assisted

Search n8n mcp claude and you get two opposite things mixed together, and then the one you probably want fails at a single URL.

The two things: n8n as an MCP server (your n8n workflows become tools Claude Code can call) versus czlonkowski/n8n-mcp, a community MCP server that lets Claude build n8n workflows for you. Same search terms, reversed direction. This post is the first one: exposing a workflow you already have as a tool for Claude Code.

And here’s the part that cost me the most time. Once the workflow is built and active, you point Claude Code at the MCP endpoint. Every instinct says the URL is http://localhost:5678/mcp/{your-path}. It isn’t. On the current n8n with a version-1 MCP Server Trigger node, the real endpoint is /mcp/{your-path}/sse, with a matching /messages for the POST side. Hit the bare path and n8n returns a 404 that reads like your workflow is broken. It’s fine. The URL is wrong.

I ran the whole thing locally and this is the working setup, plus the two other spots people get stuck.

Tested environment

Two directions, so pick the right one first

Both show up under the same keywords, and they do opposite jobs. Deciding which you want is the first fork, because everything after it differs.

If your goal is “let Claude trigger my existing n8n workflow,” you want the first one. If your goal is “let Claude write n8n workflows for me,” you want the second. Most tutorials I found don’t say which they’re doing. The rest of this post is the first.

Build the workflow

The MCP Server Trigger does nothing on its own. It needs at least one tool node connected to it, and that tool is what Claude can call.

Two nodes:

The connection between them is the one non-obvious part. It is not a normal main connection. The tool connects into the trigger over the ai_tool connection type. In the workflow JSON:

"connections": {
  "Greeting Tool": {
    "ai_tool": [[{ "node": "MCP Server Trigger", "type": "ai_tool", "index": 0 }]]
  }
}

Create it through the API (POST /api/v1/workflows with the X-N8N-API-KEY header) or build it in the UI. One gate before the API works at all: a fresh n8n returns userManagement.showSetupOnFirstLoad: true, and you can’t mint an API key until you create the owner account in the browser. That step isn’t skippable from a script.

Then activate it (POST /api/v1/workflows/{id}/activate). Activation is what registers the MCP webhook.

The URL trap

This is where I lost the most time, so it gets its own section.

After activating, I pointed a client at http://localhost:5678/mcp/claude-hello and got:

{"code":404,"message":"This webhook is not registered for GET requests. Did you mean to make a DELETE request?"}

That message sends you the wrong way. It sounds like a method problem. It’s a path problem, and the reason is version-specific.

The MCP Server Trigger node has a version, and the transport changes with it. A v1 trigger implements the older Server-Sent Events transport, which exposes two suffixed endpoints:

A v2 trigger uses streamable HTTP and drops the suffix, answering at /mcp/{path} directly. So the bare path only works on v2. On v1 it 404s, and the error text won’t tell you why.

The node source makes the rule explicit. It appends the sse / messages suffix only when the version is below 2:

// McpTrigger.node.js — path built from the node version
parseFloat($nodeVersion) < 2 ? '/sse' : ''

If you copied a URL from a tutorial written for the other version, that one line is why yours 404s.

Hit the right path and the handshake starts immediately:

event: endpoint
data: /mcp/claude-hello/messages?sessionId=827ce381-...

That’s n8n handing you the session’s POST URL. The server is working; the bare-path 404 was the only thing wrong. If you see this endpoint event, the MCP server is healthy — the remaining step is just pointing Claude Code at the same /sse URL.

Confirm the tool is actually exposed

Before wiring Claude Code in, I checked the MCP round-trip by hand: open the SSE stream, then POST initialize and tools/list to the /messages URL. n8n answered:

{"serverInfo":{"name":"n8n-mcp-server","version":"0.1.0"},"capabilities":{"tools":{}}}
{"tools":[{"name":"get_greeting","description":"Returns a friendly greeting with the current server time", "...": "..."}]}

get_greeting shows up with its description and input schema. That’s the proof the workflow is a real MCP server, not just an HTTP endpoint that happens to respond.

Connecting it is one question; what it can reach once connected is a separate one. If you’re wiring n8n into Claude Code, you’re handing the agent a tool that can run whatever that workflow does. That reach — read vs write, allow vs deny — is its own decision, and I covered it in Claude Code MCP permissions.

Connect Claude Code

Claude Code speaks MCP over SSE, so registration is one command:

claude mcp add --transport sse n8n-local http://localhost:5678/mcp/claude-hello/sse

This writes a local-scope entry to .claude.json for the current project. Check it:

claude mcp get n8n-local
# Status: ✔ Connected

Connected. Claude Code sees the server and the get_greeting tool is exposed. I haven’t yet driven a full tools/call execution through it (see below), so I’m claiming the connection and the tool listing, not the round-trip run. To undo it: claude mcp remove n8n-local -s local.

What I haven’t tested yet

I scoped this to one direction and one transport. Three things I want to measure before claiming anything about them:

The fix in one table

SymptomCauseFix
404 This webhook is not registered for GET requestsUsing the bare /mcp/{path} (a v2 endpoint) on a v1 MCP Server TriggerGET /mcp/{path}/sse to open the stream, POST /mcp/{path}/messages for calls
Client connects but no tools appearNo tool node wired into the trigger, or the wrong connection typeConnect the tool over the ai_tool connection, not main
claude mcp add succeeds but shows disconnectedWorkflow not activated, so the webhook isn’t registeredActivate the workflow (POST /api/v1/workflows/{id}/activate)

If you only take one thing from this: when the MCP endpoint 404s and the message talks about GET vs DELETE, don’t change the method. On a v1 MCP Server Trigger, /mcp/{path} is the wrong endpoint — use /mcp/{path}/sse instead (and drop the suffix on v2). The URL is the bug, not the method.

Drafted and tested with AI assistance, then reviewed before publishing. The setup above was run on the versions listed, not summarized from docs.