n8n als agentischer MCP-Hub: Wenn Workflow-Automatisierung denken lernt

Workflow-Automatisierung war lange einfach. Trigger feuert, einzelne Schritte werden ausgeführt, Daten wandern von A nach B. Jede Verzweigung ist vorbestimmt. Jedes Ergebnis ist gescriptet. Der Mensch entwirft den Flow, die Maschine führt ihn aus.

KI-Agenten arbeiten anders. Sie beobachten den Kontext, denken darüber nach, wählen ein Tool, handeln, beobachten das Ergebnis und entscheiden, was als Nächstes zu tun ist. Es gibt keinen vorbestimmten Pfad. Der Agent findet es selbst heraus.

Lange haben diese beiden Welten - deterministische Automatisierung und agentisches Reasoning - getrennt voneinander existiert. Die n8n-Workflows für Geschäftsprozesse auf der einen Seite, die KI-Agenten in Chat-Interfaces oder Developer-Tools auf der anderen. Sie haben selten miteinander kommuniziert.

Das ändert sich. n8n unterstützt das Model Context Protocol jetzt auf beiden Seiten: Es kann MCP-Server als Tools für seine KI-Agenten nutzen, und es kann eigene Workflows als MCP-Server für externe KI-Agenten bereitstellen. Diese bidirektionale MCP-Fähigkeit verwandelt n8n von einer Workflow-Engine in etwas Interessanteres - einen agentischen Automatisierungs-Hub.

Dieser Beitrag behandelt, was das bedeutet, wie es funktioniert und wo es tatsächlich sinnvoll ist.

Kurzer Rückblick: Wo wir zuletzt standen

Wir haben sowohl n8n als auch MCP in anderen Blogposts ausführlich behandelt. Für alle, die beim Thema neu sind, die Kurzversion:

MCP (Model Context Protocol) ist ein offener Standard von Anthropic, der definiert, wie KI-Anwendungen externe Tools entdecken und aufrufen. Man kann es sich als universellen Stecker zwischen einem KI-Modell und den Fähigkeiten vorstellen, die man ihm geben möchte - Datenbankabfragen, API-Aufrufe, Dateioperationen, alles Mögliche. Das Protokoll kümmert sich um Tool-Discovery, strukturierte Ein-/Ausgabe und Authentifizierung. Die Grundlagen haben wir in unserem MCP-Erklärungspost behandelt.

n8n ist eine Open-Source-Plattform für Workflow-Automatisierung, mit der man komplexe Automatisierungen visuell bauen kann. Sie unterstützt über 400 Integrationen, kann selbst gehostet werden und hat stetig KI-Fähigkeiten ausgebaut. Die Kernfunktionen haben wir in unserem n8n-Überblick behandelt, das Sicherheits-Hardening in unserem n8n-2.0-Beitrag.

Was wir noch nicht im Detail behandelt haben, sind der MCP Server Trigger und das MCP Client Tool, welche etwa im April 2025 eingeführt wurden. Unser n8n-Beitrag erwähnte "n8n tools as MCP Server endpoints" als Stichpunkt, ging aber nie darauf ein, was es tatsächlich bedeutet, n8n als bidirektionalen MCP-Hub zu nutzen.

Die MCP-Nodes gibt es schon eine Weile. Die Frage ist, was man mit ihnen machen kann, wenn man beide Seiten kombiniert - und genau darum geht es in diesem Beitrag.

Warum das wichtig ist: Die Agenten-Lücke

Viele Teams stoßen auf das gleiche Problem, wenn sie anfangen, KI-Agenten für Business-Use-Cases zu bauen: Das Modell kann denken, aber es kann nichts tun.

Ein Sprachmodell versteht vielleicht, dass eine Kundenanfrage einen CRM-Lookup erfordert, dann eine Statusprüfung im Ticketsystem, und dann eine Antwort-E-Mail. Es kann diese Schritte planen. Aber ohne Tools kann es nur beschreiben, was passieren sollte. Es kann den CRM-Aufruf nicht tatsächlich machen, das Ticket nicht prüfen und die E-Mail nicht senden.

Das ist die Agenten-Lücke: die Distanz zwischen dem, worüber eine KI nachdenken kann, und dem, was sie tatsächlich ausführen kann.

MCP schließt eine Seite dieser Lücke, indem es einen Standard bietet und Tools für KI-Agenten bereitstellt. Aber man braucht trotzdem etwas, das diese Tools hostet und orchestriert, die Authentifizierung handhabt, Datenflüsse verwaltet und alles mit den tatsächlichen Geschäftssystemen verbindet.

Genau hier kommt n8n ins Spiel. Nicht als dünner Wrapper um ein Modell, sondern als operatives Rückgrat, das Agenten Zugang zu realen Fähigkeiten gibt.

n8n als MCP-Client: KI-Agenten echte Tools geben

Der MCP Client Tool Node ermöglicht es, externe MCP-Server mit n8ns AI Agent Node zu verbinden. Einmal verbunden, kann der Agent die Tools, die der MCP-Server anbietet, entdecken und sie während seines Reasoning-Prozesses nach Bedarf aufrufen.

Das Setup ist unkompliziert. Man fügt einen AI Agent Node zum Workflow hinzu, verbindet ein Sprachmodell (OpenAI, Anthropic, ein lokales Modell über Ollama - alles möglich) und hängt dann einen oder mehrere MCP Client Tool Nodes als Sub-Nodes an. Jedes MCP Client Tool zeigt auf einen externen MCP-Server-Endpunkt.

Wenn der Agent eine Aufgabe erhält, sieht er alle verfügbaren Tools der verbundenen MCP-Server. Er entscheidet, welche Tools er basierend auf der Aufgabe nutzt, ruft sie auf, verarbeitet die Ergebnisse und denkt weiter, bis die Aufgabe erledigt ist. Das ist keine sequenzielle Automatisierung - das ist agentisches Reasoning mit echtem Tool-Zugang.

Ein paar Punkte, die es wert sind, hervorgehoben zu werden:

Tool-Auswahl: Man kann alle Tools eines MCP-Servers freigeben, bestimmte auswählen oder einzelne ausschließen. Das ist wichtig, wenn ein MCP-Server Tools anbietet, die für den vorgesehenen Einsatzzweck des Agenten irrelevant oder zu mächtig sind. Wenn ein Server sowohl Lese- als auch Schreiboperationen bereitstellt, möchte man dem Agenten vielleicht nur Lesezugriff geben.

Authentifizierung: Der Node unterstützt Bearer-Tokens, benutzerdefinierte Header und OAuth2. Das bedeutet, dass man sich mit MCP-Servern verbinden kann, die hinter Authentifizierungsschichten sitzen, ohne Credentials im Workflow selbst offenzulegen.

Transport: Der Node unterstützt derzeit SSE (Server-Sent Events), was veraltet ist, und Streamable HTTP Endpunkte. Wenn der MCP-Server den neueren Streamable HTTP Transport spricht, kommt n8n damit klar. Stdio wird nicht unterstützt, was Sinn ergibt - n8n ist eine serverseitige Plattform, kein lokales Desktop-Tool.

Die praktische Konsequenz: Wenn bereits MCP-Server in der Infrastruktur laufen - für Datenbankzugriff, Dokumentensuche, Ticketsysteme, Monitoring-Tools - kann man sie jetzt in n8n-Agenten einbinden, ohne eigenen Integrationscode zu schreiben. Der MCP-Server kümmert sich um die Tool-Logik, n8n um die Orchestrierung, und das Sprachmodell um das Reasoning.

n8n als MCP-Server: Workflows für externe KI-Agenten bereitstellen

Hier wird es besonders interessant. Der MCP Server Trigger Node macht das Umgekehrte: Er verwandelt n8n selbst in einen MCP-Server.

Jeder n8n-Workflow, der mit einem MCP Server Trigger beginnt, wird zu einem Tool, das externe MCP-Clients entdecken und aufrufen können. Das bedeutet, KI-Agenten, die in Claude Desktop, VS Code, Cursor oder jedem anderen MCP-kompatiblen Client laufen, können n8n-Workflows als Tools nutzen.

Man muss sich überlegen, was das ermöglicht. Es gibt womöglich jahrelang gewachsene Automatisierungs-Workflows in n8n - Kunden-Onboarding-Prozesse, Daten-Enrichment-Pipelines, Berichtsgeneratoren, Deployment-Skripte, Freigabeprozesse. Mit dem MCP Server Trigger werden diese Workflows zu Tools, die jeder KI-Agent im Unternehmen nutzen kann.

Ein Entwickler, der Claude um Hilfe bittet, kann den internen Deployment-Workflow auslösen. Ein Support-Agent in einem KI-gestützten Chat kann den Kunden-Status-Lookup-Flow aufrufen. Ein Produktmanager, der einen KI-Assistenten nutzt, kann die neuesten Metriken über einen Reporting-Workflow abrufen. Alles über MCP, alles ohne dass jemand wissen muss, wie der Workflow intern aufgebaut ist.

Was wir nach außen bereitstellen, kontrollieren wir selbst. Jeder Workflow, der den MCP Server Trigger nutzt, wird zu einem separaten Tool mit eigenem Namen, Beschreibung und Input-Schema. Externe Agenten sehen nur, was wir bewusst veröffentlichen.

Das bidirektionale Muster: n8n in der Mitte

Die eigentliche Stärke zeigt sich, wenn wir beide Richtungen kombinieren. n8n sitzt in der Mitte - konsumiert MCP-Server auf der einen Seite und ist selbst MCP-Server auf der anderen.

Auf der eingehenden Seite nutzen n8ns KI-Agenten MCP Client Tools, um auf externe Fähigkeiten zuzugreifen: Datenbankabfragen, Such-APIs, Monitoring-Systeme, alles, was über MCP bereitgestellt wird. Auf der ausgehenden Seite stellt n8n eigene Workflows als MCP-Tools für externe Agenten bereit.

Das erzeugt ein Hub-Muster. n8n wird zum zentralen Punkt, an dem KI-Agenten-Fähigkeiten auf Geschäftsautomatisierung treffen.

Ein konkretes Szenario: Es gibt einen MCP-Server für das CRM, einen für das Ticketsystem und einen für die Wissensdatenbank. In n8n bauen wir einen KI-Agenten-Workflow, der sich über MCP Client Tools mit allen dreien verbindet. Dieser Agent kann über alle drei Systeme hinweg denken - einen Kunden im CRM finden, dessen offene Tickets prüfen, die Wissensdatenbank nach Lösungen durchsuchen und eine Antwort formulieren.

Dann stellen wir diesen gesamten Workflow als einzelnes MCP-Tool über den MCP Server Trigger bereit. Externe KI-Agenten sehen ein Tool: "Kundenanfrage lösen." Sie müssen nichts über die drei zugrundeliegenden Systeme wissen. Sie übergeben die Kundenfrage, und n8ns interner Agent erledigt das systemübergreifende Reasoning.

Das ist Komposition. Wir bauen komplexe Fähigkeiten intern und stellen sie extern als einfache Tools bereit. Die Komplexität bleibt in n8n. Die Schnittstelle bleibt sauber.

Worauf man achten sollte

Ein paar praktische Überlegungen, bevor wir alles verkabeln:

Latenz-Budgets: Jeder MCP-Tool-Aufruf fügt Netzwerk-Roundtrip-Zeit hinzu. Ein Agent, der drei Tool-Aufrufe nacheinander kettet, bevor er antwortet, akkumuliert diese Latenz. MCP-Server sollten auf schnelle Antworten ausgelegt sein. Wenn ein Tool zwanzig Sekunden braucht, sollte man überlegen, ob der Agent es synchron nutzen oder einen asynchronen Prozess anstoßen sollte.

Tool-Wildwuchs: Es ist verlockend, jeden Workflow als MCP-Server bereitzustellen. Das sollte vermieden werden. KI-Agenten performen besser mit einem fokussierten Set an Tools. Ein Modell mit Zugriff auf fünfzig Tools wird mehr Tokens darauf verwenden herauszufinden, welches es nutzen soll, und greift eher daneben. Das Tool-Set sollte für den jeweiligen Einsatzzweck des Agenten zugeschnitten werden.

Modellkosten: Agenten, die iterativ denken, verbrauchen mehr Tokens als ein einzelner Prompt-Response-Zyklus. Multi-Tool-Chains verstärken das. Wir sollten den Token-Verbrauch tracken und Routing-Strategien in Betracht ziehen.

Observability: Wenn das Reasoning eines Agenten mehrere MCP-Tool-Aufrufe über verschiedene Systeme hinweg umspannt, wird Debugging schwieriger. Jeder Tool-Aufruf sollte mit seinen Eingaben, Ausgaben und dem Timing geloggt werden. Ohne Observability wird ein fehlgeschlagener Agenten-Workflow zur Black Box.

Unser Take

Das alte mentale Modell war: Flow designen, Entscheidungsbäume abdecken, deployen. Das neue ist: Dem Agenten die richtigen Tools und ein klares Ziel geben, und ihn den Weg selbst finden lassen. Das heißt nicht, dass Agenten deterministische Workflows ersetzen - viele Prozesse sollten jedes Mal exakt gleich ablaufen. Aber für die Use Cases, die Ermessensentscheidungen, systemübergreifenden Kontext oder Situationen beinhalten, die sich nicht sauber in Entscheidungsbäume abbilden lassen, ist der agentische Ansatz die bessere Wahl.

Was n8n in diesem Bereich interessant macht, ist die niedrige Einstiegshürde. Wir müssen keine MCP-Server von Grund auf schreiben. Wir müssen keine Agenten-Orchestrierungs-Frameworks bauen. Wir verdrahten Nodes in einem visuellen Builder und bekommen einen Agenten, der tatsächlich Dinge tun kann. Das macht die Technologie zugänglich für Teams, die sonst nicht in den Aufbau agentischer Systeme investieren würden.

Die Einschränkung ist, dass n8ns Agenten-Fähigkeiten noch reifen. Komplexe mehrstufige Planung, fortgeschrittenes Memory-Management und ausgefeilte Fehlerbehandlung sind Bereiche, in denen ein maßgeschneidertes Agenten-Framework noch Vorteile hat. Aber für die achtzig Prozent der Use Cases, die diese Fähigkeiten nicht brauchen, kommen wir mit n8n schneller ans Ziel.

Unsere Empfehlung: Fangt mit ein oder zwei bestehenden Workflows an und stellt sie als MCP-Server bereit. Verbindet sie mit einem KI-Agenten, den ihr bereits nutzt, und testet, ob das Konzept für euer Team funktioniert. Wenn ja, baut schrittweise aus. Entwickelt interne Agenten, die MCP-Tools für systemübergreifende Aufgaben verwenden. Haltet das Tool-Set dabei überschaubar – und die Sicherheit im Blick.