cd ../writing
Engineering Jul 3, 2026 4 min read

I Connected Claude to My n8n — Here's Why It Changed How I Work

The automations Claude used to only describe, it can now build and fix from the chat.

Safwan Siddiq
Safwan Siddiq
Automation engineer · KL

My handwritten-note transcriber had been erroring for a while. Some credential issue I couldn’t pin down, and I’d poked at it a few times without getting anywhere. The week I connected Claude to n8n, I pointed Claude Code at the broken workflow. It read the workflow directly and found the credential problem I’d been missing, then fixed it in place. I never left the chat to do it.

Then I asked it to build something bigger. My blog runs off my Obsidian vault, and I wanted a workflow to handle publishing. The one-shot build got me about 95% of the way there. The rest was fine-tuning the frontmatter format and getting the GitHub and Netlify syncing right. But the shape of the whole thing appeared in n8n from a description, which is not how I’d built anything before.

Why I bothered

The context-switching was the thing that wore me down. n8n is where my automations live. Claude is where I work out the logic and think through the problem. The two never touched. Claude could tell me what to build but it couldn’t build anything, so every session ended with me hand-translating its output into n8n.

I wanted to describe what I needed and have Claude go do it, instead of handing me a set of instructions to follow myself.

MCP is what closes that gap. It’s the Model Context Protocol, a standard that lets an AI tool call into an external service through a real API connection rather than poking at a UI. n8n shipped a native MCP server in v1.88. Claude connects to your instance over that, and from then on it can read and operate the thing.

What it lets Claude do

More than I expected, once it was connected:

  • List and search workflows. Find any workflow by name or description.
  • Read a workflow’s details. Understand what it does, how it fires, which nodes it uses.
  • Build a workflow from a description. You say what you want, Claude writes and validates the workflow code, then creates it in n8n.
  • Edit an existing workflow. Change one node without disturbing the rest.
  • Run a workflow. Trigger a test and read back the result inside the same conversation.
  • Publish a workflow. Flip a draft to active when it’s ready.
  • List credentials. See which integrations are wired up, without exposing any secrets, so Claude can reuse them.

Reading and running are the two I lean on, which I didn’t see coming. The transcriber fix only happened because Claude could read the actual workflow and its credential setup, not my description of it. Being able to say “run that in test mode and tell me what came back,” and get an answer, takes a whole layer of tab-switching out of building.

This is worth it if n8n is already a core tool for you. If you build the odd automation now and then, the setup cost probably isn’t. For me it’s most of my week, so it paid off fast.

Setting it up

Simpler than I thought. The MCP server ships inside n8n now, nothing extra to install. You switch it on in settings under Instance-level MCP, generate an access token, and you get back an endpoint URL and a bearer token. Those two are what Claude needs.

From there it splits by which Claude you’re using.

Claude Code (CLI): one command, claude mcp add with your URL and token. That’s the setup, and it’s the stronger option for building.

Claude desktop app: you add it under Settings, Connectors, Add custom connector. It uses OAuth rather than the bearer token, and on self-hosted n8n there’s a known bug where the connection looks like it worked and then fails quietly. The documented fix is to edit claude_desktop_config.json yourself and use a package called mcp-remote to pass the bearer token through.

Two things bite self-hosted setups: that OAuth bug, and Nginx buffering responses by default, which breaks MCP’s streaming. I didn’t hit either of them. I’d read about both while researching the install, so I handed them to Claude Code up front as context and let it account for them while it set things up. The Nginx fix, for the record, is proxy_buffering off and gzip off in the proxy config.

If you want to do the same

  1. Get on n8n v1.88 or later. The feature doesn’t exist before that.
  2. Your instance needs to be on HTTPS. Both Claude paths require it.
  3. Use an owner or admin account. MCP settings are locked to those roles.
  4. Turn on Instance-level MCP, generate the token, and copy it straight away. n8n shows it in full once.
  5. Connect with whichever path fits.

The n8n MCP docs cover the official steps. The self-hosted gotchas above aren’t in there, so if you’re self-hosting, feed them to Claude Code before it starts and let it work around them.

Worth saying plainly: n8n itself points you at Claude Code over the desktop app for building, because Claude Code is better at generating and validating the workflow code n8n uses under the hood. The desktop app is fine for looking at workflows and triggering them. For building something involved from scratch, Claude Code does the better job.

The catch

One prompt does not give you one working workflow, not for anything past trivial. The blog CMS went build, test, fix, test, then another round of that before it ran the way I wanted.

How well it worked came down to context, not prompt wording. Before Claude Code starts, it needs the real constraints, like which credential to use and exactly what the frontmatter should look like. Give it those up front and the build lands close. Leave them out and you’re in the prompt-test-troubleshoot loop for a while. The setups that went smoothly were the ones where I’d told it what to watch for, which is the same reason the OAuth and Nginx issues never touched me.

Where I’d stop

One thing I wouldn’t do yet: point this at a client’s own n8n if it’s handling personal or sensitive data. It’s a live MCP connection into a running system. If the wrong person got access to it, they could do a lot of damage quickly. On my own instance that risk is mine to carry. On a client’s, it isn’t, and I’m not comfortable putting it there.

Where this leaves me

The loop is tighter now. I describe what I want, Claude changes the actual system, I check the result, and most of the time I’m correcting rather than building from nothing. It’s still beta and it shows. Tokens expire and the OAuth path on self-hosted is fiddly. None of that has made me turn it off. My transcriber works again, my blog publishes straight from Obsidian, and both of those got sorted in a chat window.

Found this useful? Reply by email — I read every one. $ get in touch →
// keep reading