n8n-Workflows per KI beschreiben und direkt ausführen: was der MCP-Server wirklich verändert

In den meisten Mittelstandsprojekten ist der Engpass bei Prozessautomatisierung nicht das Fehlen eines passenden Tools — n8n gibt es seit Jahren, läuft stabil, und die Community-Edition kostet bei Selbstbetrieb auf einem Hetzner-Server nichts außer Rechenzeit. Der Engpass ist die Übersetzungsarbeit: aus einer prosaischen Fachbeschreibung wie „Wenn eine Rechnung in Stripe als bezahlt markiert wird, soll ein PDF erstellt und per E-Mail an den Steuerberater gehen” einen funktionierenden Workflow zu bauen. Das dauert nicht Stunden wegen technischer Komplexität, sondern wegen der vielen kleinen Entscheidungen: welcher Node-Typ, welches Feld, welcher HTTP-Header, welche Fehlerbehandlung. Genau diesen Aufwand nimmt der offizielle n8n-MCP-Server weg — und das in einem Ausmaß, das ich nach einigen Wochen produktivem Einsatz als strukturellen Unterschied bezeichnen würde, nicht als Komfortgewinn.

Was MCP hier überhaupt bedeutet

Das Model Context Protocol (MCP) ist ein offener Standard, der es LLM-Clients wie Claude oder einem IDE-Agenten erlaubt, externe Werkzeuge mit definierten Schemata aufzurufen. Statt dass Sie Claude einen langen System-Prompt mit einer n8n-Node-Dokumentation hineinwürgen, registriert der MCP-Server seine Fähigkeiten einmalig, und der Agent ruft sie zur Laufzeit ab. Das klingt nach Infrastruktur-Detail, ist aber entscheidend: Claude weiß im Moment der Anfrage, welche Nodes existieren, welche Parameter Pflicht sind, welche Typen erwartet werden — und kann das Ergebnis validieren, bevor es n8n erreicht.

Konkret registriert der n8n-MCP-Server Werkzeuge wie get_node_schema, validate_workflow, und create_workflow. Ein Agent, der auf diesen Server zeigt, kann damit:

• die verfügbaren Node-Typen und ihre Parameter abfragen,
• einen generierten Workflow gegen das Schema prüfen, ohne ihn einzuspielen,
• und bei Erfolg direkt einen neuen Workflow in der n8n-Instanz anlegen.

Einrichtung in zehn Minuten

Die Einrichtung ist ehrlich gesagt der unkomplizierte Teil. Voraussetzung ist eine laufende n8n-Instanz (ab Version 1.x, Selbstbetrieb oder Cloud) und ein API-Key aus den n8n-Einstellungen. Dann registriert man den MCP-Server in der Claude Desktop-App oder in der eigenen IDE-Konfiguration.

Für Claude Desktop sieht der Eintrag in ~/Library/Application Support/Claude/claude_desktop_config.json so aus:

{
  "mcpServers": {
    "n8n": {
      "command": "npx",
      "args": ["-y", "@n8n/mcp-server"],
      "env": {
        "N8N_API_URL": "https://n8n.ihre-domain.de/api/v1",
        "N8N_API_KEY": "ihr-api-key-hier"
      }
    }
  }
}

Nach einem Neustart von Claude ist der Server aktiv. Kein eigener Prozess, kein Port, kein Reverse-Proxy-Eintrag — npx zieht das Paket bei Bedarf und startet es im Hintergrund. In der Praxis mache ich das bei Kundenprojekten so: Der API-Key wird einmal in der Konfiguration hinterlegt, und danach arbeite ich direkt in Claude, ohne die n8n-Oberfläche auch nur zu öffnen.

Wie ein typisches Gespräch mit Claude aussieht

Ich beschreibe das Ziel in einem oder zwei Sätzen, ohne Node-Namen oder technische Details:

„Erstelle einen Workflow, der stündlich die Shopify-Bestellungen der letzten Stunde abruft, bei jeder Bestellung mit Status fulfilled eine Zeile in eine Google-Tabelle schreibt und einen Slack-Kanal benachrichtigt, falls mehr als zehn Zeilen in einem Durchlauf hinzukommen.”

Claude fragt bei Unklarheiten nach — Shopify-Store-URL? Welche Spalten? Welcher Slack-Kanal? — und liefert dann einen validierten Workflow, den es direkt einspielt. Was früher dreißig Minuten gekostet hat (Node suchen, Parameter nachlesen, testen, debuggen, wiederholen), dauert jetzt drei bis fünf Minuten, inklusive der Rückfragen.

Das ist kein Marketingversprechen. Ich habe in den vergangenen Wochen für zwei Kunden zusammen gut fünfzehn Workflows auf diese Weise erstellt: Rechnungsautomatisierung mit Lexoffice, Datentransfers zwischen einem ERP-System und einem Reporting-Tool, Slack-Benachrichtigungen aus Monitoring-Webhooks. Der einzige Fall, in dem ich nennenswert nachgebessert habe, war ein Workflow mit einer verschachtelten Schleife, bei dem Claude eine unnötig komplexe Struktur gewählt hatte — dazu gleich mehr.

Worauf man achten muss

Der MCP-Server ersetzt das Denken nicht. Zwei Schwachstellen sind mir regelmäßig aufgefallen:

Komplexität schleicht sich ein. Claude hat die Tendenz, Sonderfälle mit zusätzlichen Nodes abzubilden, wo ein einziger Function-Node mit zwanzig Zeilen JavaScript sauberer wäre. Wer das Ergebnis nicht reviewed, hat nach einem halben Jahr einen Workflow-Katalog, der schwer zu warten ist. Ich schaue jedes Ergebnis kurz an, bevor ich es als „fertig” betrachte — nicht wegen Fehler, sondern wegen Struktur.

Credentials müssen manuell verknüpft werden. Der MCP-Server kann einen Workflow anlegen und Nodes mit dem richtigen Credential-Typ konfigurieren, aber die eigentlichen Zugangsdaten liegen in n8n und werden nicht automatisch zugewiesen. Das ist kein Bug, das ist Absicht — Credentials sollen nicht über API-Calls exponiert werden. In der Praxis bedeutet es: nach dem Anlegen eines Workflows kurz in die Oberfläche, Credentials verknüpfen, fertig.

Versionsabhängigkeiten. Nodes ändern sich zwischen n8n-Versionen. Ein Schema, das Claude heute kennt, kann in drei Monaten andere Pflichtfelder haben. Das ist kein n8n-spezifisches Problem, aber bei Automatisierungsprojekten mit langem Lebenszyklus sollte man n8n-Updates kontrolliert einspielen und nicht auf „immer aktuell” setzen.

Warum das für Mittelstandsprojekte besonders relevant ist

Das Wort „Automatisierung” löst bei vielen Mittelständlern ein bestimmtes Bild aus: ein IT-Projekt mit Laufzeit, Lasten­heft und Budgetfreigabe. Was ich stattdessen anbieten kann, ist ein anderes Modell: ein kurzes Gespräch über den Prozess, ein Workflow in derselben Woche, Anpassungen in Echtzeit.

Das funktioniert nur, weil die Werkzeuge mitgewachsen sind. Vor zwei Jahren hat n8n selbst das Versprechen „drag and drop für jeden” gegeben — realistisch war es für technisch versierte Anwender, nicht für alle. Heute erledige ich den technischen Teil per KI, und der Kunde muss nur noch den Prozess beschreiben. Der Unterschied ist nicht akademisch: Ein Beispiel aus dem letzten Monat, ein Handelsunternehmen mit fünfzehn Mitarbeitern, wollte Bestelleingänge aus zwei Kanälen zusammenführen und in ein gemeinsames Google Sheet übertragen. Früher wäre das eine halbe Woche Arbeit mit Rückfragen gewesen. Es hat neunzig Minuten gedauert, inklusive Test mit echten Daten.

MCP macht n8n nicht automatisch zum richtigen Werkzeug für jeden Anwendungsfall. Für komplexe, zustandsbehaftete Prozesse mit Transaktionsanforderungen braucht es mehr als einen Workflow-Builder. Aber für die Klasse von Aufgaben, bei denen n8n sowieso das richtige Werkzeug war, ist die Zeit-von-Idee-zu-laufendem-Workflow jetzt um eine Größenordnung kürzer.

Wer n8n bereits betreibt, sollte den MCP-Server diese Woche ausprobieren. Zehn Minuten Einrichtung, und man sieht sofort, ob es den eigenen Arbeitsfluss verändert. Bei mir hat es das.