Building n8n workflows with Claude and MCP — instead of clicking them together

Anyone who works with n8n knows the routine: drag a trigger, wire up nodes, copy JSON paths into the right field, keep five browser tabs open for the third-party API docs. It works — but it does not scale past the fifth variation of the same idea. Since the official n8n MCP server appeared and Claude drives it, this part of my work has fundamentally changed: I describe the workflow in prose, Claude generates it as SDK code, validates it against the schema, and drops it into n8n ready to run.

A few notes from recent projects.

What the n8n MCP server actually does

MCP — the Model Context Protocol — is the structured way language models talk to external systems. The n8n MCP server exposes the n8n Workflow SDK as tools. Concretely, Claude can:

• read the SDK reference (get_sdk_reference),
• search for nodes (search_nodes) — e.g. “sevdesk”, “nextcloud”, “schedule trigger”,
• pull the exact type definitions of node parameters (get_node_types),
• validate the finished code (validate_workflow), and
• create or update the workflow in n8n (create_workflow_from_code, update_workflow).

That is the load-bearing point: Claude does not guess parameter names. It queries the schema, writes typed code against it, and has the server validate the result before deploy.

Example 1: sevdesk invoice capture — as a prompt, not a click-path

The classic case: an SMB receives 60–200 invoices a month at info@. Instead of building this in the UI for an hour, I describe it:

> Prompt to Claude (with the n8n MCP server attached):
"Build a workflow that polls the IMAP inbox info@client.de,
extracts PDF attachments, uploads them to the sevdesk API
as draft vouchers, and stores the original in Nextcloud
/accounting/inbox/YYYY-MM. On errors → Slack message in #accounting."

What Claude actually does, expressed in tool calls:

1. get_sdk_reference         → read SDK patterns
2. search_nodes(["imap", "sevdesk", "nextcloud", "slack"])
                             → find the matching node IDs
3. get_node_types([...])     → fetch exact parameter schemas
4. (write code)              → workflow as TypeScript SDK code
5. validate_workflow(code)   → schema check, fix-iteration if needed
6. create_workflow_from_code → workflow is live in n8n

The result is not “a draft you then clean up”. It is a runnable, validated workflow — because the validation step is not lip service; it uses the same schema n8n runs on import.

Example 2: a Nextcloud data room with expiry logic

A second project: a tax advisor uses Nextcloud as a client data room. Requirement: files older than 90 days move to an encrypted archive, with an audit entry.

The prompt:

"Daily at 02:00: list every file under /clients/ in Nextcloud
older than 90 days. Move it to /archive/{client}/{year}/.
For each move, append a row to the Postgres table audit_log
with file ID, client, hash, timestamp. End-of-run Slack summary
to @advisor."

Claude asks the n8n MCP server for the nextcloud.list, nextcloud.move, postgres.insert, and slack.message nodes, pulls the types, builds the workflow, validates it. What used to be half a day in the UI lands as a pull request with the SDK code in git history — and finally becomes reviewable.

This exact point — workflows as code in git, instead of JSON exports in email attachments — is the single biggest practical win for me.

What concretely changes

Compared to classic UI maintenance:

• Reproducibility. The workflow lives as a TypeScript file in the repo. git blame tells you who changed what and why.
• Reviewable. Pull request, diff, approval. Instead of: “can you look at n8n again and see if that’s right?”
• Reuse. A prompt pattern for the sevdesk integration becomes a lexoffice one by telling the model: “same workflow, lexoffice instead of sevdesk”.
• Speed. What used to be half a day takes 20 minutes — of which 15 are spent on honest testing, not on clicking nodes together.

Where it doesn’t fit

So this doesn’t read like a brochure:

• Nodes without an SDK definition. Very new third-party nodes that don’t map onto the SDK yet still get clicked together in the UI. That’s a shrinking remainder, but it exists.
• Workflows with heavy branching logic. If the flow has 30 IF nodes and manual routing tables, the model is capable, but the review becomes more expensive than building it yourself. At that complexity the right move is to redesign the logic before discussing tooling.
• Spontaneous workflows. If somebody just wants to “quickly wire up” a trigger, the UI is still faster. The code path starts paying off the moment a workflow needs to live longer than three weeks.

A realistic setup

What has held up across several projects:

• n8n in Docker on a Coolify instance (see also Astro, Next.js, or Angular in 2026 for the broader stack thinking).
• Claude API access in a dedicated workspace, separated from development workspaces.
• n8n MCP server wired locally — it talks straight to the n8n instance.
• A workflows/ directory in the git repo with the generated SDK code per workflow. Deploy runs update_workflow from a simple CI stage.
• An audit table in Postgres logging every workflow run — regardless of whether the workflow was hand-built or generated by Claude.

The last point is not optional. Automation without a trail becomes expensive the moment somebody asks “who did that?”.

Rule of thumb

If a process today eats more than an hour of click-work per week in the n8n UI, or if it needs to be reviewable, switching to Claude + n8n MCP almost always pays off. Below that line: skip it, the setup cost eats the gain. Above two days of work per week: don’t treat it as a workflow at all — that’s an internal product.

If you want to know whether a specific automation fits this band, I’ll look at it honestly in an hour. Including a clean no, if the tool doesn’t fit.