n8n-Workflows mit Claude und MCP bauen — statt sie zu klicken

Wer mit n8n arbeitet, kennt die Routine: Trigger ziehen, Knoten verbinden, JSON-Pfade in das richtige Feld kopieren, fünf Tabs offen, um die API-Doku des Drittsystems daneben zu haben. Das funktioniert — aber es skaliert nicht über die fünfte Variante hinaus. Seit der offizielle n8n-MCP-Server verfügbar ist und Claude ihn ansteuert, hat sich diese Arbeit für mich grundlegend verändert: ich beschreibe den Workflow in Prosa, Claude generiert ihn als SDK-Code, validiert ihn gegen das Schema und legt ihn fertig in n8n ab.

Ein paar Notizen aus mehreren Projekten der letzten Wochen.

Was der n8n-MCP-Server eigentlich tut

MCP — das Model Context Protocol — ist die Art, wie Sprachmodelle strukturiert mit externen Systemen reden. Der n8n-MCP-Server stellt das Workflow-SDK von n8n als Werkzeuge zur Verfügung. Konkret: Claude kann

• die SDK-Referenz lesen (get_sdk_reference),
• nach Knoten suchen (search_nodes) — z. B. „sevdesk”, „nextcloud”, „schedule trigger”,
• die exakten Typdefinitionen der Knotenparameter abrufen (get_node_types),
• den fertigen Code validieren (validate_workflow) und
• ihn als Workflow in n8n anlegen oder aktualisieren (create_workflow_from_code, update_workflow).

Das ist der entscheidende Punkt: Claude rät keine Parameter zusammen, sondern fragt das Schema explizit ab, schreibt typisierten Code dagegen und lässt ihn vor dem Deploy serverseitig prüfen.

Beispiel 1: sevdesk-Belegerfassung — als Prompt, nicht als Klick-Strecke

Der klassische Fall: ein Mittelständler bekommt 60–200 Belege pro Monat per E-Mail an info@. Statt diesen Workflow eine Stunde lang im UI zusammenzubauen, beschreibe ich ihn:

> Prompt an Claude (mit n8n-MCP):
„Bau mir einen Workflow, der die IMAP-Mailbox info@kunde.de pollt,
PDF-Anhänge extrahiert, an die sevdesk-API als Beleg-Entwurf hochlädt
und das Original in Nextcloud /buchhaltung/eingang/YYYY-MM ablegt.
Bei Fehlern → Slack-Nachricht in #buchhaltung."

Was Claude dann tatsächlich tut, sieht in den Tool-Calls so aus:

1. get_sdk_reference         → SDK-Patterns nachlesen
2. search_nodes(["imap", "sevdesk", "nextcloud", "slack"])
                             → passende Node-IDs holen
3. get_node_types([...])     → exakte Parameter-Schemata abrufen
4. (Code schreiben)          → Workflow als TypeScript-SDK-Code
5. validate_workflow(code)   → Schema-Check, ggf. Fix-Iteration
6. create_workflow_from_code → Workflow steht in n8n bereit

Das Ergebnis ist nicht „ein generierter Entwurf, den man dann nachbessert”. Es ist ein lauffähiger, validierter Workflow — weil der Validierungs-Schritt eben kein Lippenbekenntnis ist, sondern dasselbe Schema verwendet, das n8n beim Import durchläuft.

Beispiel 2: Nextcloud-Datenraum mit Verfallslogik

Ein zweites Projekt: ein Steuerberater nutzt Nextcloud als Mandanten-Datenraum. Anforderung: Dateien älter als 90 Tage wandern in ein verschlüsseltes Archiv, mit Audit-Eintrag.

Der Prompt:

„Täglich um 02:00: liste in Nextcloud alle Dateien unter /mandanten/
älter als 90 Tage. Verschiebe sie in /archiv/{mandant}/{jahr}/.
Schreibe pro Verschiebung eine Zeile in die Postgres-Tabelle
audit_log mit Datei-ID, Mandant, Hash, Zeitstempel. Am Ende des Laufs
eine Slack-Zusammenfassung an @berater."

Claude fragt den n8n-MCP-Server nach den nextcloud.list, nextcloud.move, postgres.insert und slack.message Knoten, holt sich die Typen, baut den Workflow, validiert ihn. Was vorher ein halber Tag im UI war, ist als Pull-Request mit dem SDK-Code in der git-History erledigt — und damit endlich review-fähig.

Genau dieser Punkt — Workflows als Code im Git statt als JSON-Export im Email-Anhang — ist für mich der größte praktische Gewinn.

Was sich konkret verändert

Im Vergleich zur klassischen UI-Pflege:

• Reproduzierbarkeit. Der Workflow lebt als TypeScript-Datei im Repo. git blame sagt, wer was geändert hat und warum.
• Review-fähig. Pull-Request, Diff, Approval. Statt: „kannst du nochmal in n8n schauen, ob das so passt?”
• Wiederverwendung. Ein Prompt-Pattern für die sevdesk-Anbindung lässt sich auf lexoffice umbiegen, indem man dem Modell sagt: „dasselbe, aber mit lexoffice statt sevdesk”.
• Geschwindigkeit. Was vorher ein halber Tag war, dauert 20 Minuten — wovon 15 für ehrliches Testen draufgehen, nicht für das Zusammenklicken.

Wo es nicht passt

Damit das nicht nach Werbeprospekt klingt:

• Knoten ohne SDK-Definition. Sehr neue Drittanbieter-Knoten, die noch nicht über das SDK abbildbar sind, klickt man weiter im UI. Das ist eine schrumpfende Restmenge, aber sie existiert.
• Workflows mit massiver Verzweigungslogik. Wenn der Flow 30 IF-Knoten und manuelle Routing-Tabellen hat, ist das Modell zwar fähig, aber das Review wird teurer als das selbst Bauen. Bei dieser Komplexität gehört eine Überarbeitung der Logik vor die Werkzeugfrage.
• Spontan-Workflows. Wenn ein Mitarbeiter „mal kurz” einen Trigger zusammenklicken will, ist das UI weiterhin schneller. Das Code-Vorgehen lohnt sich ab dem Moment, in dem ein Workflow länger als drei Wochen leben soll.

Ein realistischer Aufbau

Was sich in mehreren Projekten als robust gezeigt hat:

• n8n in Docker auf einer Coolify-Instanz (siehe Coolify auf Hetzner).
• Claude API-Zugang mit eigenem Workspace, getrennt von Entwicklungs-Workspaces.
• n8n-MCP-Server lokal angebunden — der spricht direkt mit der n8n-Instanz.
• workflows/-Verzeichnis im Git-Repo mit dem generierten SDK-Code pro Workflow. Deploy passiert über update_workflow aus einer einfachen CI-Stage.
• Eine Audit-Tabelle in Postgres, in die jede Workflow-Ausführung protokolliert wird — unabhängig davon, ob der Workflow per Hand oder per Claude entstanden ist.

Der letzte Punkt ist nicht verhandelbar. Automatisierung ohne Protokoll wird genau dann teuer, wenn jemand fragt „wer hat das gemacht?”.

Faustregel

Wenn ein Prozess heute mehr als eine Stunde Klick-Arbeit im n8n-UI pro Woche kostet, oder wenn er reviewfähig sein muss, lohnt sich der Wechsel zu Claude + n8n-MCP fast immer. Unterhalb davon: lassen, der Aufbau frisst den Nutzen. Oberhalb von zwei Tagen pro Woche: erst recht — dann reden wir nicht über einen Workflow, sondern über ein internes Produkt.

Wer wissen will, ob ein konkreter Automatisierungsbedarf in diese Kategorie fällt, schaue ich mir gern in einer Stunde an. Auch mit klarem Nein, wenn das Werkzeug nicht passt.