n8n MCP Server erstellen: sicher an Claude anbinden

Ein n8n MCP Server ist schnell gebaut: Trigger anlegen, ein paar Werkzeuge anhängen, Zugangsschlüssel setzen. Die meisten Anleitungen hören genau dort auf. In der Praxis entscheidet aber nicht das Einrichten über den Nutzen, sondern die Frage, was ein Sprachmodell über diesen Server tun darf und was nicht.

Ich beschreibe hier den Aufbau, mit dem ich Blogartikel aus Claude heraus in mein CMS schreibe: Claude legt Entwürfe an, prüft vorhandene Artikel und veröffentlicht erst nach meiner Freigabe. Das Muster lässt sich auf jedes System mit einer API übertragen, ob CRM, Ticketsystem oder Wissensdatenbank.

Was ist ein n8n MCP Server?

Das Model Context Protocol ist ein offener Standard, über den KI-Anwendungen wie Claude externe Werkzeuge und Daten ansprechen. Ein MCP-Server stellt diese Werkzeuge bereit, ein MCP-Client wie Claude Code oder Claude.ai ruft sie auf.

In n8n übernimmt der Node MCP Server Trigger die Rolle des Servers. Er stellt eine URL bereit, unter der Clients die angehängten Werkzeuge abrufen und ausführen können. Der MCP Server Trigger spricht SSE und Streamable HTTP; für Claude Code und Claude.ai nutzt man Streamable HTTP. Jedes Werkzeug ist ein eigener Node, zum Beispiel ein HTTP-Request-Tool oder ein Aufruf eines anderen Workflows. Den Werkzeugnamen und die Werkzeugbeschreibung sieht das Modell; daraus entscheidet es, wann es welches Werkzeug nutzt.

MCP Server Trigger, MCP Client Tool und n8n-Instanz-MCP: Was ist was?

In n8n tauchen drei MCP-Bausteine auf, die leicht verwechselt werden:

• MCP Server Trigger: macht einen einzelnen Workflow mit seinen angehängten Werkzeugen zu einem MCP-Server. Um diesen Node geht es in diesem Artikel.
• MCP Client Tool: der umgekehrte Weg. Ein AI-Agent-Node in n8n nutzt damit Werkzeuge eines externen MCP-Servers.
• n8n-Instanz-MCP: der eingebaute MCP-Zugang der gesamten n8n-Instanz. Darüber können Clients wie Claude Workflows suchen, bauen oder ausführen. Er ist kein eng geschnittener Server für eine Aufgabe, sondern ein Zugang zur Instanz.

Wer ein Modell gezielt mit einem einzelnen Fremdsystem arbeiten lassen will, baut einen eigenen Server mit dem MCP Server Trigger.

Warum ein eigener MCP-Server statt direktem API-Zugriff?

Man könnte einem Agenten auch einfach den API-Schlüssel des CMS geben. Dann hängt alles am Prompt: Steht dort „veröffentliche nichts ohne Rückfrage“, ist das eine Bitte, keine Grenze. Ein falsch verstandener Auftrag oder eine präparierte Eingabe reicht, und der Agent tut, was der Schlüssel erlaubt.

Ein eigener MCP-Server dreht das um:

• Das Modell sieht nur Werkzeuge, keine Zugangsschlüssel. Der Zugangsschlüssel für das Zielsystem liegt in den n8n-Credentials (gespeicherte Zugangsdaten). Claude bekommt ihn nie zu sehen.
• Jedes Werkzeug ist eine feste Aufgabe. „Entwurf anlegen“ kann keine Artikel löschen, weil es technisch nur einen bestimmten Endpunkt mit einer bestimmten Methode aufruft.
• Der Zugang ist getrennt austauschbar. Der Zugangsschlüssel für den MCP-Endpunkt ist ein anderer als der für das CMS. Muss einer erneuert werden, bleibt der andere unberührt.

Die Cloud Security Alliance empfiehlt in ihrem Leitfaden-Entwurf zu MCP-Sicherheit, Berechtigungen für MCP auf Ebene einzelner Tools festzulegen. Das ist dasselbe Prinzip: Rechte über Berechtigungen durchsetzen statt über Prompts, und pro Aufgabe nur die Zugangsschlüssel vergeben, die sie braucht.

Aufbau: ein Werkzeug pro Aufgabe

Mein Blog-Server hat drei Werkzeuge, alle als HTTP-Request-Tool gegen die REST-API des CMS:

1. Artikel auflisten – liest veröffentlichte Artikel und Entwürfe. Claude nutzt das, um Dubletten zu vermeiden und passende interne Links zu finden.
2. Entwurf anlegen – schreibt einen neuen Artikel ausdrücklich als Entwurf. Die Werkzeugbeschreibung legt Felder, Längen und Formatregeln fest.
3. Veröffentlichen – setzt einen vorhandenen Entwurf über seine ID auf veröffentlicht. Es überträgt keine Inhalte. Laut Beschreibung soll Claude es nur nach meiner ausdrücklichen Bestätigung im Gespräch aufrufen.

Löschen gibt es bewusst nicht. Was nicht als Werkzeug existiert, kann das Modell nicht aufrufen.

Die Werkzeugbeschreibung ist dabei mehr als Dokumentation. Sie ist der Vertrag zwischen Modell und System: Je genauer dort steht, welche Felder Pflicht sind, welche Werte erlaubt sind und wann das Werkzeug nicht benutzt werden soll, desto seltener landen fehlerhafte Aufrufe beim Zielsystem. Eine technische Grenze ist sie aber nicht: Die Beschreibung ist Prompt-Text und damit nur eine weiche Regel. Denselben Ansatz nutze ich in meiner Wissensbasis mit RAG und MCP, wo die Werkzeugbeschreibung wie eine öffentliche API behandelt wird.

Schritt für Schritt: n8n MCP Server einrichten

1. Workflow anlegen und den MCP Server Trigger hinzufügen. Unter Path einen sprechenden Pfad wählen, etwa blog-cms. Die vollständige URL zeigt der Node selbst an; es gibt eine Test-URL für die Entwicklung und eine Produktions-URL für den Betrieb.
2. Authentifizierung am Trigger setzen. Bearer Auth wählen und eine Credential mit einem zufälligen, langen Zugangsschlüssel anlegen, zum Beispiel mit openssl rand -hex 32 erzeugt. Ohne Authentifizierung ist der Endpunkt eine offene Tür zu allem, was die Werkzeuge können.
3. Werkzeuge anhängen. Für REST-APIs eignet sich das HTTP-Request-Tool. Parameter, die das Modell befüllen soll, werden mit $fromAI() markiert; alles andere wird fest eingetragen, etwa Methode, Endpunkt und den Status, z. B. status=draft.
4. Eine eigene Credential für das Zielsystem anlegen. Im CMS einen Zugangsschlüssel erzeugen, der nur die Rechte hat, die die Werkzeuge brauchen. Bei mir: lesen, anlegen und aktualisieren, aber nicht löschen.
5. Werkzeugbeschreibungen schreiben. Kurz sagen, was das Werkzeug tut, wann es benutzt werden soll, welche Eingaben erwartet werden und was es ausdrücklich nicht tut.
6. Workflow veröffentlichen. In n8n 2.x heißt das Publish; erst dann ist die Produktions-URL erreichbar.

Rechte pro Werkzeug begrenzen

Bevor du den ersten Node anlegst, kläre, welche Aktion welchen Schaden anrichten kann. Ich teile Werkzeuge in drei Stufen ein:

• Lesen ist unkritisch und darf frei genutzt werden.
• Anlegen als Entwurf verändert nichts Öffentliches. Fehler bleiben unsichtbar, bis ein Mensch sie prüft.
• Veröffentlichen wirkt nach außen. Dieses Werkzeug bekommt eine Regel in der Beschreibung: erst den Titel nennen, dann auf Bestätigung warten. Das ist eine weiche Regel, auf die sich das Modell in der Regel einlässt, die es technisch aber nicht erzwingt.

Für eine harte Grenze braucht es eine Freigabe außerhalb des Modells. Für Agenten-Workflows in n8n gibt es Human-in-the-loop für Tool-Aufrufe. Für Tools hinter dem MCP Server Trigger greift das nicht. Dort setzt man die Freigabe im Client: in Claude.ai die Tool-Berechtigung nicht auf „Always allow“ stellen, in Claude Code den Aufruf nicht vorab erlauben. Alternativ baut man die Freigabe in einen Sub-Workflow ein, den das Werkzeug aufruft, etwa eine Slack-Nachricht mit Warten auf Antwort. Bei meiner Leistungsnachweis-Automation läuft die Freigabe zum Beispiel über eine Slack-Reaktion, bevor Dokumente erzeugt werden.

Zwei Details, die leicht übersehen werden:

• Eingaben, die in URLs landen, bereinigen. Mein Veröffentlichen-Werkzeug entfernt aus der übergebenen ID alles außer Kleinbuchstaben und Ziffern, bevor sie Teil des Pfads wird.
• Zugangsschlüssel nicht doppelt nutzen. Der Zugangsschlüssel, mit dem die Website beim Build Artikel liest, ist ein anderer als der des MCP-Servers. So lässt sich jeder Zugang einzeln entziehen.

Mit Claude Code, Claude.ai und Claude Desktop verbinden

In Claude Code reicht ein Befehl. Der Zugangsschlüssel wird nur für den eigenen Benutzer gespeichert und landet nicht im Projekt-Repository:

claude mcp add --scope user --transport http blog-cms \
  https://n8n.example.com/mcp/blog-cms \
  --header "Authorization: Bearer <SCHLÜSSEL>"

In Claude.ai wird der Server als benutzerdefinierter Connector eingetragen. Für Server, die einen eigenen Zugangsschlüssel statt OAuth verwenden, ist die Option Keine Anmeldung vorgesehen; den Zugangsschlüssel trägt man darunter als Request-Header ein, in der Form Bearer <SCHLÜSSEL>. Request-Header sind derzeit Beta und nicht in jedem Konto verfügbar. Nachträglich ändern lassen sie sich nur, indem man den Connector neu anlegt. Eigene Header-Namen außerhalb der angebotenen Liste müssen von Anthropic freigegeben werden, deshalb lohnt es sich, am Trigger einen Standard-Header zu verwenden.

In Claude Desktop bindet man den Server ebenfalls als Custom Connector ein oder startet lokal eine Brücke mit mcp-remote, die den entfernten Server für die Desktop-App erreichbar macht.

Danach testen, bevor man sich auf den Server verlässt: einmal mit falschem Zugangsschlüssel (muss abgewiesen werden), einmal mit richtigem Zugangsschlüssel die Werkzeugliste abrufen, dann ein lesendes Werkzeug aufrufen.

Betrieb hinter einem Reverse Proxy

Läuft n8n hinter einem Reverse Proxy, braucht der MCP-Endpunkt zwei Einstellungen. Erstens muss das Proxy-Buffering aus sein, damit gestreamte Antworten sofort beim Client ankommen. Zweitens müssen bei mehreren Webhook-Replicas alle Anfragen an /mcp* auf dieselbe Replica gehen. Die n8n-Dokumentation zeigt das für nginx. Ich betreibe n8n hinter Caddy; die Caddy-Variante habe ich nicht gegen die Doku geprüft, die Anforderungen sind aber dieselben.

Typische Fehler: wenn der n8n MCP Server Trigger nicht funktioniert

Diese Fehler sind mir beim Aufbau tatsächlich begegnet:

• 404 auf der MCP-URL. Der Workflow ist nicht veröffentlicht. In n8n 2.x speichert Save nur; erst Publish macht die Produktions-URL erreichbar. Achtung: Ein Import über die Kommandozeile setzt einen Workflow ebenfalls wieder auf inaktiv. Abhilfe schafft danach n8n publish:workflow --id=<ID>; im Multi-Main- oder Queue-Betrieb kann der Import mit --activeState=fromJson den Status aus der Datei übernehmen (Doku).
• Claude sieht die Werkzeugliste, aber jeder Aufruf scheitert mit „Authorization failed“. Dann fehlt nicht der MCP-Zugangsschlüssel, sondern die Credential des Zielsystems in den Werkzeug-Nodes. Die Executions in n8n zeigen den Statuscode des Zielsystems: 401 bedeutet fehlender oder falscher Zugangsschlüssel, 403 fehlende Rechte.
• Header wird gesendet, aber leer. Steht der Zugangsschlüssel in einer Shell-Variable, ist sie in einem neuen Terminal leer. Dann wird nur „Bearer“ gespeichert. Prüfen mit claude mcp get blog-cms.
• Claude.ai fordert eine Anmeldung bei n8n. Das passiert auch, wenn am Trigger Authentication auf None steht. n8n führt das als bekannte Einschränkung.
• Rechte testen, ohne etwas zu verändern. Ein Aufruf mit einer erfundenen ID verrät einiges, aber nicht alles: 403 heißt, das Recht fehlt. 404 kann bedeuten, dass nur die Ressource fehlt, aber auch, dass die API fehlende Rechte verschleiert; das ist nach HTTP-Standard (RFC 9110) erlaubt. Verlässlich ist nur ein Aufruf auf eine bekannte Ressource in einer Testumgebung.

Wann sich ein eigener MCP-Server lohnt

Sinnvoll ist er, sobald ein Modell regelmäßig mit einem System arbeiten soll, das Folgen nach außen hat: Inhalte veröffentlichen, Kunden anschreiben, Daten im CRM ändern. Dann ist die Begrenzung über Werkzeuge der Unterschied zwischen einem Assistenten, dem man Aufgaben übergibt, und einem, den man ständig beaufsichtigen muss. Wie Agenten über MCP mehrere Datenquellen kombinieren, beschreibt der Beitrag Agentic RAG mit MCP; wo Claude bei sicherheitsnahen Analysen an Grenzen stößt, zeigt Reverse Engineering mit Claude.

Für einmalige Abfragen oder reine Lesezugriffe auf unkritische Daten ist der Aufwand oft größer als der Nutzen. Dort genügt häufig ein fertiger MCP-Server des jeweiligen Anbieters, sofern dessen Rechte zur Aufgabe passen.