MCP, Coding Agents und agentische Workflow-Entwicklung

MCP, Coding Agents und Workflow-Entwicklung

0:00 Bisher haben Sie Workflows gebaut, in denen KI mitarbeitet. Jetzt drehen wir die Richtung um: Ein KI-Assistent baut Workflows für Sie. Technisch geht das über das Model Context Protocol, und n8n bringt dafür einen eigenen Server mit. Der Gedanke, den ich Ihnen mitgeben möchte: Ein Coding Agent an der eigenen Instanz ist wie ein Kollege mit Schreibrecht.

0:21 Man gibt ihm einen Schlüssel — und es kommt sehr darauf an, welchen. Dieses Modul zeigt, wie man ihn ausstellt, was er öffnet, und, ebenso wichtig, wie man ihn wieder einzieht.

MCP, Coding Agents und agentische Workflow-Entwicklung

0:32 Wir bleiben am fünften Tag. Zuerst klären wir, was MCP eigentlich ist und welche zwei Wege es in n8n gibt, es anzubieten — die verwechselt man leicht. Dann die instanzweite Schnittstelle im Detail: einrichten, freigeben, anmelden. Danach die Zusammenarbeit mit einem Coding Agent, einschließlich der offiziellen n8n Skills.

0:53 Und zum Schluss das Thema, das über den produktiven Einsatz entscheidet: Wie behält man die Kontrolle?

MCP als standardisierte Tool-Schnittstelle

1:00 Fangen wir mit der Einordnung an. MCP läuft in zwei Richtungen — n8n kann Werkzeuge anbieten, und n8n kann fremde Werkzeuge nutzen. Beides hat seinen Platz, und beides sollte man auseinanderhalten. Der eingebaute MCP-Server von n8n erlaubt unterstützten Clients eine gesicherte Verbindung zur eigenen Instanz. Verbundene Clients können Workflows suchen, mit freigegebenen Workflows arbeiten, sie auslösen und testen sowie Workflows und Data Tables erstellen und bearbeiten.

1:31 Lesen Sie diese Liste noch einmal: Das ist kein Nur-Lese-Zugriff, das ist Schreibrecht auf Ihre Automatisierung. Der Vergleich, der hier trägt: Sie geben einem externen Werkzeug einen Mitarbeiterzugang zu Ihrem Werkstattsystem. Das kann außerordentlich nützlich sein — es verlangt aber dieselbe Sorgfalt wie jeder andere Zugang auch.

1:51 Zwei Wege, und die Verwechslung ist der häufigste Anfangsfehler. Der instanzweite MCP-Zugang ist eine Verbindung je Instanz mit zentraler Anmeldung, bei der Sie Workflows einzeln freigeben — das ist der Weg, über den ein Coding Agent an Ihre Instanz kommt. Der MCP Server Trigger Node dagegen sitzt in einem einzelnen Workflow und bietet genau dessen eigene Werkzeuge an — das ist der Weg, wenn Sie selbst einen spezialisierten MCP-Server bauen wollen.

2:18 Und die Fußzeile nennt die dritte Richtung: Über das MCP Client Tool nutzt n8n umgekehrt fremde MCP-Server als Werkzeug eines Agenten. Vier Fähigkeiten. Workflows ausführen mit den Ausführungswerkzeugen. Workflows bauen und bearbeiten — und hier die Versionsangabe, die Sie sich merken sollten: verfügbar ab n8n 2.13.0. Wer auf einer älteren Version arbeitet, hat nur die ausführende Hälfte. Data Tables lesen und schreiben. Und Suchen über alle Workflows, die der Benutzer sehen darf.

2:49 Dieser letzte Punkt ist eine Ausnahme von der Freigaberegel, über die wir gleich sprechen — und er ist entschärft, weil die Suche nur Vorschauen liefert, nicht die vollständigen Workflow-Daten. Der erste Punkt ist die Verwechslung von eben: Die beiden Wege werden vermischt, und dann wundert man sich, dass der Trigger-Baustein nur einen Workflow anbietet.

3:10 Der zweite ist ein Halbschritt: Die Freigabe wird instanzweit erteilt und je Workflow vergessen — dazu gleich mehr. Der dritte ist ein Netzwerkproblem: Der Client sitzt in der Cloud, die Instanz ist von außen nicht erreichbar. Und der vierte ist eine Betriebsfalle, auf die die Dokumentation eigens hinweist: Ein Reverse Proxy entfernt die MCP-Header, und dann funktioniert gar nichts — ohne dass irgendetwas auf die Ursache zeigt.

Die instanzweite MCP-Schnittstelle

3:35 Jetzt zur Einrichtung. Und dabei ist die wichtigste Erkenntnis: Freigeben ist eine Einzelentscheidung, keine Einstellung. Sie schalten nicht einen Schalter um und sind fertig. Fünf Schritte. Aktivieren Sie unter Settings, Instance-level MCP den Zugang — das darf nur, wer Instanzeigentümer oder Admin ist. Wählen Sie über Connect den Client und entscheiden Sie sich für OAuth oder einen API-Schlüssel.

4:01 Kennzeichnen Sie dann jeden Workflow einzeln als Available in MCP — das ist der Schritt, den man nicht überspringen kann und auch nicht sollte. Bestätigen Sie nach dem Verbinden den Zugriff in n8n. Und prüfen Sie unter Connected clients, welche Rechte tatsächlich erteilt wurden. Die Fußzeile nennt die Version: Das Einrichten je Client gibt es ab n8n 2.33.0.

4:24 Vier Punkte, und sie beschreiben die Grenzen sehr genau. Es gibt keine pauschale Freigabe aller Workflows — nur die einzeln markierten. Die Ausnahme ist die Suche: Sie sieht alles, was der Benutzer sehen darf, liefert aber nur Vorschauen. Und jetzt der Punkt, den man kennen muss: Der Zugang ist nicht je Client abgegrenzt.

4:43 Alle Clients, die Sie verbinden, sehen dieselbe Auswahl — Sie können also nicht dem einen Assistenten diese und dem anderen jene Workflows geben. Die Sichtbarkeit bleibt immerhin benutzerbezogen: Jeder sieht nur, worauf er ohnehin Zugriff hat. Vier Punkte zur Anmeldung. OAuth ist der empfohlene Weg und erlaubt Rechte je Client — das ist der wesentliche Vorteil.

5:06 Ein API-Schlüssel ist ein persönliches Token an Ihrem Benutzerkonto; er funktioniert, hängt aber an Ihnen persönlich. Und daraus folgt ein praktisches Detail: Nur OAuth-Clients erscheinen in der Liste der verbundenen Clients. Wer mit API-Schlüssel arbeitet, taucht dort nicht auf — Sie sehen also nicht, wer verbunden ist. Entziehen trennt einen Client sofort; er muss sich vollständig neu anmelden.

5:30 Das ist der Notausschalter, den man kennen sollte. Der erste Punkt ist der wichtigste dieser Folie und ein echter Fallstrick: Das Ausführungswerkzeug läuft standardmäßig produktiv — es führt also die veröffentlichte Version aus. Wenn Ihr Assistent „mal eben testen" will, testet er möglicherweise gegen echte Systeme. Es gibt einen manuellen Modus, aber der ist nicht die Voreinstellung.

5:54 Der zweite: Der API-Schlüssel wird geteilt und hängt doch an einer Person. Der dritte ist ein Betriebsdetail: Abschalten trennt alle Clients auf einmal. Und der vierte: Wer die Funktion vollständig entfernen will, braucht dafür eine Umgebungsvariable.

Workflows mit Coding Agents entwickeln

6:09 Jetzt zur eigentlichen Arbeit. Und hier gibt es eine Beobachtung, die n8n selbst gemacht hat: Ein Coding Agent kennt das Protokoll — aber er kennt nicht Ihre Konventionen. n8n Skills sind Fähigkeitsmodule aus einem eigenen Repository. Sie geben einem Coding Agent das Wissen über n8n-Konventionen — Expressions, Node-Konfiguration, Fehlerbehandlung —, das er über das Protokoll allein nicht hat.

6:34 Das ist eine bemerkenswerte Einsicht: Der Zugang allein reicht nicht. Ein Assistent, der Workflows bauen kann, aber nicht weiß, wie Expressions in n8n geschrieben werden, produziert etwas, das plausibel aussieht und nicht läuft. Die Skills schließen genau diese Lücke — und sie tun es zum richtigen Zeitpunkt, nämlich bevor der Agent handelt.

6:55 Vier Bestandteile. Dreizehn Fähigkeitsmodule zu Sub-Workflows, Expressions, Schleifen, Agenten, Fehlerbehandlung und Debugging — Sie erkennen die Themen dieses Seminars wieder. Über fünfzig Referenzdokumente und Beispiele mit Entscheidungsbäumen. Hooks, die vor wirkungsvollen Aufrufen die passende Anleitung laden — das ist der clevere Teil: Die Anleitung kommt nicht auf Vorrat, sondern im Moment des Bedarfs.

7:20 Und ein vierzehntes Meta-Modul, das zum jeweils passenden Modul führt. Alles ist einfaches Markdown, lesbar und abwandelbar — Sie können also Ihre eigenen Hauskonventionen dazuschreiben. Fünf Schritte, und sie beschreiben eine Arbeitsteilung, keine Delegation. Schreiben Sie die Aufgabe als Spezifikation auf, nicht als Wunsch — der Unterschied ist, dass eine Spezifikation prüfbare Aussagen enthält.

7:45 Lassen Sie den Agenten einen Plan vorlegen, bevor er baut. Lesen Sie den erzeugten Workflow — Bausteine, Verbindungen, Fehlerpfade. Testen Sie mit angehefteten Daten, nicht gegen Produktionssysteme; die Technik aus Modul zwei ist hier Ihr Schutz. Und veröffentlichen Sie erst danach selbst. Dieses „selbst" ist wichtig: Der letzte Schritt bleibt bei Ihnen.

8:08 Der erste Punkt ist der verführerischste: Der Entwurf sieht plausibel aus und wird deshalb nicht gelesen. Ein sauber angeordneter Workflow mit sinnvollen Namen erzeugt Vertrauen, das er sich nicht verdient hat. Der zweite ist eine Folge fehlender Spezifikation: Der Agent baut ohne Fehlerpfade, weil niemand danach gefragt hat.

8:26 Der dritte ist der übersprungene Schutz: Getestet wird gegen die echte Schnittstelle, weil es schneller ging. Und der vierte erklärt, warum die Skills existieren: Die Konventionen des Hauses stehen nirgends, also folgt der Agent seinen eigenen.

Kontrolle behalten

8:41 Zum Abschluss die nüchterne Betrachtung. Alles, was der Agent darf, darf er auch versehentlich. Das ist kein Misstrauen gegenüber der Technik — das ist dieselbe Regel, die für jeden Zugang gilt. Vier Stellen, und keine davon ist ein Prompt. Die Auswahl der freigegebenen Workflows. Die Rechte, die dem Client beim Verbinden erteilt wurden.

9:02 Die Trennung zwischen Entwicklungs- und Produktionsinstanz — darüber sprechen wir morgen ausführlich, und dieses Modul ist ein Argument dafür. Und die Regel, dass Veröffentlichen eine menschliche Handlung bleibt. Diese vier zusammen sind Ihr Sicherheitsnetz. Beachten Sie die Parallele zum Agenten-Modul von gestern: Auch dort lag die Grenze nicht im Modell, sondern in den Berechtigungen drumherum. Das Muster wiederholt sich.

9:28 Seit n8n 2.34 lassen sich außerdem eigenständige Agenten aus dem Agent Builder für MCP-Clients bereitstellen. Diese Agenten sind etwas anderes als klassische Workflows und auch etwas anderes als der AI-Agent-Baustein, den wir gestern gebaut haben — es ist eine eigene Gattung mit eigener Oberfläche. Und jetzt der Satz, der in jede Projektplanung gehört: Die Funktion steht im Preview-Status.

9:52 Die Dokumentation sagt ausdrücklich, dass sie sich ändern kann und nicht für produktive Workflows verwendet werden sollte. Ansehen: unbedingt. Einplanen: noch nicht. Fünf Schritte, und dieses Kapitel gehört zu den am häufigsten vergessenen. Öffnen Sie unter Settings die verbundenen Clients. Prüfen Sie über View all die Zugriffsebene je Client.

10:14 Entziehen Sie nicht mehr benötigte Verbindungen einzeln. Rotieren Sie API-Schlüssel gesondert — sie stehen nicht in dieser Liste, das hatten wir vorhin. Und prüfen Sie nach jedem Projekt, welche Workflows noch freigegeben sind. Die Fußzeile nennt die Wirkung: Ein entzogener Client ist sofort getrennt und muss sich vollständig neu anmelden. Das ist ein sauberer Schnitt — nutzen Sie ihn.

10:38 Der erste Punkt ist der Normalfall in Projekten: Der Zugang bleibt nach dem Projekt bestehen, weil niemand zuständig ist. Der zweite ist die schleichende Variante: Freigegebene Workflows werden nie wieder zurückgenommen — nach zwei Jahren ist faktisch alles freigegeben. Der dritte ist der gefährlichste: Der Agent arbeitet auf der Produktionsinstanz, weil dort die echten Daten liegen.

11:00 Und der vierte ist die Warnung von Folie zwanzig: Preview-Funktionen werden als belastbare Grundlage eingeplant. Das gilt übrigens für jede Preview-Funktion, die uns in diesem Seminar begegnet ist.

Übung

11:11 Jetzt verbinden Sie selbst einen Coding Agent mit der Kesselwerk-Instanz. Und Sie üben dabei etwas, das im Alltag fast nie geübt wird: das Aufräumen danach. Die Ersatzteilnachbestellung von Kesselwerk soll als neuer Workflow entstehen: Unterschreitet ein Bestand die Meldemenge, wird bei Teilehandel nachbestellt und der Vorgang festgehalten.

11:32 Das ist fachlich überschaubar und technisch genau die richtige Größe für einen Entwurf. Und Sie kennen inzwischen alle Bestandteile — Schwellenprüfung, API-Aufruf, Idempotenz. Das ist Absicht: Sie sollen beurteilen können, ob der Entwurf gut ist. Einen Entwurf zu einem Thema prüfen zu lassen, von dem man nichts versteht, ist keine Prüfung.

11:53 Das Lernziel: einen Coding Agent so einbinden, dass sein Zugriff in Umfang und Dauer begrenzt bleibt. Umfang und Dauer — beides zählt. Erfolgreich sind Sie, wenn genau ein Workflow freigegeben war, der Entwurf gelesen und mit angehefteten Daten getestet wurde, von Hand veröffentlicht wurde und der Zugang danach entzogen ist.

12:12 Wer früh fertig ist, installiert die n8n Skills und vergleicht den Entwurf mit und ohne sie. Dieser Vergleich ist aufschlussreich — Sie sehen unmittelbar, was Konventionswissen ausmacht. Siebzig Minuten, fünf Schritte. Aktivieren Sie MCP und verbinden Sie per OAuth genau einen Client. Kennzeichnen Sie genau einen Workflow als Available in MCP — genau einen, auch wenn es umständlich wirkt.

12:36 Übergeben Sie die Aufgabe als Spezifikation und fordern Sie einen Plan an, bevor gebaut wird. Lesen Sie den Entwurf, testen Sie mit angehefteten Daten und ergänzen Sie die Fehlerpfade, die fehlen werden. Und veröffentlichen Sie selbst — und entziehen Sie anschließend den Clientzugriff. Der letzte Halbsatz ist die eigentliche Übung.

12:57 Vier Fallen. Erstens: Es wird mehr freigegeben als nötig, weil die Suche ohnehin alles findet — dabei liefert die Suche nur Vorschauen, das ist ein Unterschied. Zweitens, und das kann wehtun: Der Agent führt den Workflow aus, und er läuft produktiv gegen Teilehandel; erinnern Sie sich an die Voreinstellung des Ausführungswerkzeugs.

13:17 Drittens: Der Entwurf wird übernommen, ohne die erzeugten Ausdrücke zu prüfen. Und viertens, der Grund für den fünften Schritt: Der Zugang bleibt bestehen, weil die Übung gefühlt mit dem Veröffentlichen endet. Tut sie aber nicht.