n8ns offizieller MCP verbraucht 41x mehr Token. Trotzdem nutze ich weiter die Community-Version.

Ich habe n8ns offizielles MCP am Tag des Launches getestet. Ich wollte einen Terminbuchungs-Agent für Google Calendar, nichts Ausgefallenes. 4 Minuten später hatte es 80 bis 90% des Dings eigenständig aufgebaut, Nodes platziert, Verbindungen verdrahtet, fast fertig. Das fast hat mir den Rest des Nachmittags gefressen. Ein korruptes Phantom-Feld, das ich nicht sauber löschen konnte. Eine falsch verdrahtete Calendar-ID, die den Node bei jedem Lauf zum Absturz brachte. Ein zu langsames Modell, das ich am Ende austauschen musste. Das Gerüst war umsonst. Es zu reparieren dauerte 6 Mal länger, als wenn ich es selbst gebaut hätte.

Die 41x machen eine gute Schlagzeile. Aber diese Zahl versteckt das eigentliche Thema, und das eigentliche Thema hat nichts damit zu tun, dass ein Tool ein anderes schlägt. Das native MCP und das Community-MCP konkurrieren nicht. Sie besetzen zwei Etagen eines Handwerks, das sich unter unseren Füßen verschoben hat, und die meisten Leute, die über den Benchmark streiten, haben nicht bemerkt, dass sich der Boden bewegt hat.

Eine Sache muss ich klarstellen, bevor wir weitermachen. Das ist kein neutraler Labortest zweier MCP-Server. Ich habe das native hands-on für ein paar Builds laufen lassen, das Community-MCP nutze ich seit Monaten, und die 41x sind jemand anderes Messung, nicht meine. Worüber ich sprechen kann, ist das darunterliegende Muster, weil diesen Teil habe ich von Anfang bis Ende durchlebt.

Vier Minuten zum Bauen. Fünfundzwanzig zum Reparieren (lol)

Zurück zu diesem Calendar-Agent, weil die Details wichtiger sind als die Zusammenfassung.

Das native MCP generiert eine TypeScript SDK-Repräsentation des Workflows statt rohem JSON, was angenehmer zu handhaben ist. Es platzierte den Trigger, den AI-Agent-Node, das Google Calendar Tool, das Credentials-Gerüst. Es verband sie in einer Reihenfolge, die Sinn machte. Für einen ersten Durchgang beeindruckend.

Dann stieß ich auf das Phantom-Feld. Irgendwo in der generierten Config war eine übriggebliebene Property, korrupt, von nichts Sichtbarem referenziert, und der Editor weigerte sich, mich sie entfernen zu lassen, ohne zu meckern. n8ns eigene Canvas wollte den Workflow damit nicht validieren, und das MCP sah es nicht als Problem, weil aus Sicht des Agents der Workflow vollständig aussah.

Das ist der Teil, bei dem es sich lohnt, einen Moment zu verweilen. Der Agent dachte, er wäre fertig. Der Workflow lief nicht. Diese beiden Zustände koexistierten fröhlich, und nichts im Generierungsschritt überbrückte sie.

Als nächstes: die Calendar-ID. Der Agent hatte einen Platzhalter verdrahtet, wo die echte Kalender-Kennung hingehörte, was fair ist, er kann meinen Kalender nicht kennen. Aber er verdrahtete ihn in ein Feld, das den ganzen Node bei der Ausführung zum Absturz brachte, statt sanft mit einer klaren Nachricht zu versagen. Also sagte der erste Lauf nicht "fehlende Calendar-ID", sondern etwas Generisches über den Node, und ich suchte eine Weile am falschen Ort.

Und das Modell. Der Agent hatte ein Modell für den AI-Node gewählt, das technisch gültig und schmerzhaft langsam für einen interaktiven Buchungsflow war. Es auszutauschen war 30 Sekunden Arbeit, sobald ich es bemerkte, aber es zu bemerken bedeutete, das Ding laufen zu lassen, es laggen zu sehen und zu realisieren, dass der Agent für "funktioniert" und nicht für "funktioniert mit brauchbarer Geschwindigkeit" optimiert hatte.

4 Minuten für das Gerüst. 25, um es tatsächlich zum Laufen zu bringen. Das Verhältnis ist die Geschichte.

Der Flaschenhals ist nur umgezogen

Hier ist die Beobachtung, und es ist eine Beobachtung, kein Gesetz, da ich das bei einer Handvoll Builds und nicht bei tausend durchgespielt habe.

Einen n8n-Workflow zu generieren kostete früher echte Zeit. Du öffnetest die Canvas, erinnertest dich, welchen Trigger du brauchtest, zogst Nodes, verdrahtetest sie, schautest Node-Properties nach, die du vergessen hattest. Diese Kosten sind kollabiert. Es sind jetzt Minuten, manchmal weniger.

Die Kosten für das Verifizieren dieses Workflows, das Debuggen und die Überwachung, wenn er abdriftet, sind nicht kollabiert. Sie sind genau da, wo sie waren. Vielleicht etwas schlimmer, weil der Workflow, den du jetzt verifizierst, nicht von dir gebaut wurde, also trägst du nicht das mentale Modell davon, wie er zusammengesetzt wurde.

Wenn eine Kostenstelle auf nahezu null fällt und die danebenliegende fest bleibt, konzentriert sich die echte Arbeit auf die, die sich nicht bewegt hat. Das ist keine Erkenntnis, das ist Arithmetik.

Also haben die drei Dinge, die früher "n8n können" ausmachten, nicht gleichermaßen überlebt. Die Nodes auswendig zu kennen ist weg, das hält jetzt der Agent. Sie von Hand zu verdrahten ist auch weg. Aber das Verifizieren und Debuggen dessen, was herauskam, ist noch da, und es trägt jetzt das Gewicht, das sich die anderen beiden früher geteilt haben.

Ich bin nicht der Erste, der das beschreibt. Viele haben es getan, in Stücken. Manche nennen es Delegation, manche Orchestrierung, manche Supervision. Builder auf X sagen bereits Dinge wie "Ich baue keine n8n-Workflows mehr von Hand, dieses MCP hat alles verändert." Ein Guide von UI Bakery sagt es klar: das n8n MCP kann die Erstellung beschleunigen, aber es entfernt nicht die Notwendigkeit für Governance, Testing und Review. Die Intuition ist überall. Was gefehlt hat, ist eine klare Form. Drei Säulen, zwei davon Substitutionen, eine davon ein Stau. Diese Asymmetrie ist der ganze Punkt, also lass mich sie durchgehen.

Säule 1: Die Spezifikation ersetzte Node-Wissen

Die alte Fähigkeit war Gedächtnis. Du wusstest, dass der Schedule-Trigger scheduleTrigger und nicht schedule hieß, dass er ein interval hier und eine rule dort nahm, dass der HTTP Request Node etwa 200 Properties hatte und du nur 8 davon je angerührt hast, aber du wusstest, welche 8.

Dieses Wissen ist jetzt das Problem des Agents, nicht deins. Was wie purer Gewinn klingt, bis du liest, was n8n selbst in seiner MCP-Ankündigung sagt: wenn du ein erfahrener Builder bist, sei explizit darüber, welche Nodes zu verwenden sind. Lies das nochmal. Die offizielle Anleitung für guten Output ist, dass du die Nodes bereits gut genug kennen musst, um sie zu benennen.

Also verschwand der Wert nicht. Er migrierte. Er zog aus deinem Gedächtnis in die Qualität der Spezifikation, die du schreibst. Eine präzise Spezifikation, die den Trigger benennt, die Nodes benennt, die Datenform angibt, bringt dir einen Workflow, der leichte Reparaturen braucht. Eine vage Spezifikation bringt dir einen selbstbewussten, plausiblen, falschen Workflow.

Und hier ist das ehrliche Korollar, weil diese Säule eine scharfe Kante hat. Eine vage Spezifikation wurde früher früh erwischt. Die Reibung beim händischen Verdrahten von Nodes war nervig, aber sie war auch eine Prüfung - du bemerktest, dass die Datenform nicht passte, weil du derjenige warst, der den Output mit dem Input verband. Diese Reibung ist weg. Also produziert eine schlechte Spezifikation jetzt schneller denn je einen schlechten Workflow, ohne etwas dazwischen, das dich verlangsamt und zum Hinschauen bringt. Geschwindigkeit ist hier nicht immer dein Freund.

Säule 2: Validierung ersetzte Konstruktion

Schau dir an, womit das native MCP tatsächlich ausgeliefert wurde. Nicht nur Workflow-Generierung. Es lieferte Tools für Validierung, für Testausführung, für die Generierung von Testdaten. Der Editor baute das Sicherheitsnetz in dasselbe Release wie das Ding, das das Sicherheitsnetz braucht. Das ist n8n, das dir in Produktentscheidungen statt in Worten sagt, dass Generieren nicht der Job ist.

Sie sagen es auch in Worten. Aus derselben Ankündigung: komplexe Workflows brauchen oft einen zweiten oder dritten Durchgang, sie glätten noch raue Kanten. Und drüben im n8n Community Forum eröffnete Ophir Prusak von n8n einen Feedback-Thread, in dem er Nutzer direkt fragt, wie zuverlässig die Workflow-Erstellung war, ob generierte Workflows nah an dem landen, was du von Hand bauen würdest, oder ob du viel Zeit damit verbringst, Dinge nachträglich zu reparieren. Das ist der Vendor, der aktiv fragt, wie viel vom Nachmittag das fast auffrisst.

Also ist die Fähigkeit nicht mehr, den Workflow zu produzieren. Es ist zu wissen, wie man das verhört, was der Agent dir gereicht hat. Fließen die Daten tatsächlich durch diesen Zweig. Führt der Fehlerweg irgendwohin. Hat er den richtigen Node gewählt oder nur einen Node, der läuft.

Ich argumentierte eine Version davon bereits im März, als ich darüber schrieb, wie ein Open-Source-Repo Claude Code in einen brauchbaren n8n-Architekten verwandelte. Das Ausliefern des nativen MCP brach diese Argumentation nicht. Falls überhaupt, bestätigte es sie, weil das native MCP mit seinen eigenen Validierungstools ankam, was dasselbe Eingeständnis aus der anderen Richtung ist.

Säule 3: Debugging und Supervision sind, wo der Job hingewandert ist

Das ist die Säule, die keine Substitution ist, und die Asymmetrie ist absichtlich. Die ersten beiden Säulen sind Dinge, die der Agent von deinem Teller genommen hat. Diese hier ist das Ding, das er auf deinen Teller gekippt hat. Es ist auch da, wo die meiste tatsächliche Arbeit jetzt lebt, also läuft dieser Abschnitt absichtlich länger als die anderen.

Geh zurück zu meinem Calendar-Agent. Das Phantom-Feld, die crashende Calendar-ID, das langsame Modell. Drei Ausfälle, und der Agent, der den Workflow generierte, hätte keinen davon reparieren können, weil er sie nicht sehen konnte. Das Phantom-Feld tauchte nicht in der Repräsentation des Agents auf. Der Crash existierte nur zur Ausführungszeit. Das langsame Modell offenbarte sich nur, wenn ein Mensch es laufen sah und das Laggen spürte. Generierung ist blind für alle drei.

Und das ist nicht nur mein Dienstag, der schiefgeht. Es gibt ein GitHub Issue im n8n Repo, Nummer 27718, wo das get_workflow_details Tool vom offiziellen MCP konsistent über 60 Sekunden timeout, wenn es durch einen externen Client wie claude.ai aufgerufen wird, während search_workflows in unter einer Sekunde antwortet. Die Ursache wurde zu einem Commit zurückverfolgt, der Sicherheitsverarbeitung hinzufügte. Das ist eine echte, datierte raue Kante am nativen MCP, die Art von Ding, die du nur findest, indem du darauf stößt.

Hier ist der Teil, den zu akzeptieren mir eine Weile dauerte. Die Ausfallmodi eines agent-generierten n8n-Workflows sind nicht die Ausfallmodi, die du bekommst, wenn du ihn selbst baust, und dieser Unterschied ist das ganze Problem. Wenn du einen Workflow von Hand verdrahtest, sind die Bugs, die du produzierst, Bugs, die du dir vorstellen kannst, weil du sie gemacht hast, du kennst die Form deiner eigenen Fehler. Wenn ein Agent ihn generiert, kommen die Bugs aus einem Prozess, den du nicht durchgeführt hast, an Orten, die du nicht gewählt hast, ausgedrückt in einer Config-Repräsentation, die du nicht geschrieben hast. Es gibt einen Artikel auf flowgenius.in, der 5 verschiedene stille Ausfallmodi für das n8n MCP katalogisiert, Dinge wie der Prozess beendet sich ohne Log, Buffer Overflow im Event Stream, Timeouts, die wie Process Kills aussehen, Zombie-Prozesse, die sich im Queue-Modus stapeln. Keiner davon kündigt sich an, und keiner davon ist ein Fehler, den ein menschlicher Builder natürlich machen würde, also zeigt dein Debugging-Instinkt nicht mal in die richtige Richtung, wenn du anfängst.

Jemand kümmerte sich genug um das, um ein ganz separates MCP nur fürs Debugging zu bauen. James Tention schrieb darüber, warum er n8n-debug-mcp baute, und sein Grund war stumpf: Debugging frisst oft Stunden der Zeit. Du baust kein dediziertes Tool für ein Problem, das nicht das Problem ist.

Es gibt eine Zeile von einem Builder auf X, aisama.code, die die Form davon trifft. n8n fühlt sich einfach an, bis der Workflow aufhört, linear zu sein, und dann triffst du auf Retries, Branching Logic, Shared State, stille Ausfälle. Sein Punkt war, dass MCP Agents inspizieren und refactoren lässt, statt dass du dich durch Spaghetti-Canvases von Hand schleppst, was stimmt. Aber bemerke, was noch erforderlich ist: jemand muss die Inspektion lesen. Jemand muss wissen, dass ein stiller Ausfall überhaupt möglich ist. Der Agent generiert schnell, aber er kann nicht debuggen, was er nicht sehen kann, und einen Agent zu überwachen, der abgedriftet ist, bedeutet, n8n gut genug zu kennen, um Drift von Funktionieren zu unterscheiden.

Der Vorbehalt gehört genau hier hin, verteilt, nicht für das Ende aufgespart. Das Babysitting ist reduziert. Es ist nicht eliminiert. Der Agent entfernt eine Kategorie von Drecksarbeit, und wenn ich es so klingen ließ, als hätte sich nichts verbessert, wäre das unehrlich. Was sich geändert hat, ist, dass die Arbeit, die dir bleibt, die härtere Art ist. Weniger Tippen, mehr Lesen. Weniger Bauen, mehr Beurteilen.

(Nebenbemerkung, das Repo des Community-MCP stellt ein Prinzip auf, das irgendwo tätowiert werden sollte: vertraue niemals Defaults, Standard-Parameterwerte sind die Nummer-eins-Quelle von Runtime-Ausfällen. Ich habe mehr Zeit an einen Node verloren, der still mit einem Default lief, den ich nie gewählt hatte, als an jeden dramatischen Crash. Der dramatische Crash sagt dir wenigstens, wo du hinschauen sollst. Der Default sitzt einfach da und ist falsch.)

\

Zwei ehrliche Einwände

Andrew Green schreibt für den n8n Blog als Industrieanalyst, bezahlt von n8n, aber schreibt seine eigenen Meinungen, und er hat mir zwei Einwände gegen meine eigene These gereicht. Ich nehme beide, weil ihnen auszuweichen billig wäre.

Einwand eins: das hat n8n nicht demokratisiert. Greens Linie ist, dass alle anfingen, Vibe Coding zu machen, aber nur, wenn sie bereits wussten, wie man programmiert. Das sticht, weil es korrekt ist. Das MCP, nativ oder Community, upgradete die Leute, die bereits die Fähigkeit hatten. Der komplette Anfänger wird nicht davon gehoben, der komplette Anfänger generiert nur mehr Workflow, als er verstehen kann, und liefert die Lücke aus. Der verschobene Flaschenhals belohnt Expertise. Er produziert sie nicht. Wenn du n8n vorher nicht debuggen konntest, gab dir der Agent diese Fähigkeit nicht, er gab dir nur mehr Dinge, die du nicht debuggen konntest.

Einwand zwei: MCP selbst verliert vielleicht das Rennen. Green denkt auch, dass MCP einen meteorischen Aufstieg hatte und dann verpuffte, wobei Skills das Momentum aufnahm. Er könnte recht haben, ich bin ehrlich nicht sicher, dass dieses Protokoll das ist, das wir alle in einem Jahr verwenden. Ich habe früher darüber geschrieben, warum CLIs oft MCP für Agent-Arbeit schlagen, also bin ich nicht hier, um eine Fahne für das Protokoll zu pflanzen.

Aber hier halte ich die Linie. Die Job-Verschiebung ist unabhängig vom Protokoll. Ob du mit n8n durch das native MCP, das Community-MCP, Skills, eine CLI oder was auch immer nächstes Quartal ausgeliefert wird, sprichst, die Arithmetik ändert sich nicht. Generierung wird billig, Verifikation bleibt teuer, die Arbeit konzentriert sich auf Verifikation. Die Protokoll-Debatte ist real und wert, geführt zu werden, es ist nur eine andere Debatte als diese.

Welches, und wann

Drei Referenzpunkte, keine Scorecard, da ich nicht alle drei bei Produktionsintensität über jedes Szenario laufen ließ.

Das native n8n MCP verdient seinen Platz, wenn du schnell scaffolden und nah am Editor bleiben willst. Es generiert die TypeScript SDK-Repräsentation, es liefert mit eingebauten Validierungs- und Test-Tools aus, und es gibt nichts Extra zu warten, weil es n8ns eigenes ist. Für den Weg von "Ich brauche einen Workflow" zu "Ich habe einen Entwurfs-Workflow" ist es gut.

Das Community-MCP, czlonkowskis n8n-mcp, verdient seinen Platz bei Coverage und Kosten. Es indexiert 1650+ Nodes, es macht Multi-Level-Validierung, und laut dem Benchmark seines eigenen Autors läuft es mit einem Bruchteil der Token-Kosten. Es ist auch das mit tausenden GitHub-Sternen und Monaten von Community-Hämmern dahinter. Wenn ich will, dass der Agent die volle Node-Oberfläche tatsächlich kennt, ist das das eine.

Und plain manuelles n8n verdient noch seinen Platz für atomares Debugging, den Moment, wo der Agent blind ist. Das Phantom-Feld, der stille Ausfallmodus, der Node, der auf einem Default läuft, den niemand gewählt hat. Du öffnest die Canvas selbst und schaust.

Ich deinstallierte keines der MCPs. Das ist die ehrliche Zusammenfassung. Sie lösen nicht dasselbe Problem, also beide zu behalten ist keine Unentschlossenheit, es ist nur das Tool an die Etage anzupassen, auf der ich an diesem Tag arbeite.

Der Job in einem Satz

Du baust keine n8n-Workflows mehr. Du schreibst die Spezifikation, du verifizierst, was der Agent produzierte, du springst ein, wo er blind ist. Drei Säulen, und ich bin mit dir durch jede mit den Belegen gegangen.

Die 41x, der native-gegen-Community-Kampf, das nächste Protokoll, das MCP ersetzt, all das ist Lärm, der auf der tatsächlichen Veränderung sitzt. Der Job verschwand nicht. Er zog eine Etage tiefer, an den Ort, den der Agent nicht sehen kann.

Momentan ist das Community-n8n-MCP das bessere. Das ist es wert, beobachtet zu werden, nicht sich damit abzufinden.

Quellen

• n8n Blog, "n8n's MCP server can now build workflows!" (April 2026) und "We need to re-learn what AI agent development tools are in 2026" von Andrew Green (Mai 2026)
• n8n Community Forum, Feedback-Thread eröffnet von Ophir Prusak zu MCP-Workflow-Erstellung
• GitHub, n8n Issue #27718 zu get_workflow_details MCP-Timeouts
• czlonkowski/n8n-mcp Repository, und der Token-Kosten-Benchmark veröffentlicht von Romuald Czlonkowski (@romualdcz)
• flowgenius.in zu stillen MCP-Ausfallmodi, James Tention zu n8n-debug-mcp, UI Bakerys n8n MCP Guide
• @on_punchman (aisama.code) und @editxshub auf X