Model Context Protocol (MCP) verständlich erklärt – mit n8n-Beispiel

Wer KI-Agenten baut, kennt das Problem: Für jede Funktion eines angebundenen Dienstes muss ein eigenes Werkzeug definiert werden. Ein Kalendereintrag suchen, anlegen, ändern, löschen – das sind schnell vier separate Bausteine, und das nur für einen einzigen Dienst. Mit vielen Anbindungen wächst der Wartungsaufwand entsprechend. Das Model Context Protocol (MCP) verfolgt einen anderen Ansatz: Es standardisiert, wie ein Sprachmodell mit einem Dienst kommuniziert – und reduziert die Zahl der nötigen Bausteine drastisch. Dieser Beitrag fasst Konzept und ein konkretes Praxisbeispiel mit n8n zusammen.

Was MCP überhaupt löst

Die Grundidee des Model Context Protocol steckt im Namen: Ein Sprachmodell soll den Kontext einer Anwendung verstehen. Konkret heißt das: Was kann diese Anwendung? Wofür ist sie da? Und wie führe ich Aktionen darin aus?

Klassisch bindet man beim Agentenbau jedes Tool einzeln an – jede Funktion ist ein eigener Baustein. Bei Google Calendar etwa: ein Tool zum Suchen von Einträgen, eines zum Aktualisieren, eines zum Löschen, eines zum Erstellen. Vier Funktionen für einen Dienst. Bei komplexen Agenten mit vielen angebundenen Diensten summiert sich das schnell zu Dutzenden von Bausteinen.

Server, Client und das einheitliche Schema

MCP arbeitet mit zwei Rollen:

• MCP-Server: schaltet sich vor den eigentlichen Dienst (z. B. Airbnb oder Google Calendar) und beschreibt, wie man mit diesem Dienst interagieren kann.
• MCP-Client: sitzt im Agenten und ruft die Funktionen des Servers ab und auf.

In der aktuellen Umsetzung – etwa in n8n – genügen dafür zwei Schritte statt vieler Einzel-Tools:

1. List Tools (auflisten): Der Agent fragt den Server, welche Funktionen verfügbar sind.
2. Execute Tool (ausführen): Der Agent ruft eine konkrete Funktion mit den passenden Parametern auf.

Entscheidend ist das einheitliche Schema. Egal welcher Dienst dahintersteckt: Die Antwort auf eine List-Tools-Abfrage ist immer gleich aufgebaut. Sie enthält pro Funktion den Namen, eine Beschreibung und ein Schema mit den erlaubten Parametern. Inhalte und Parameter unterscheiden sich von Dienst zu Dienst – die Struktur bleibt konstant. Genau das ist es, was das Protokoll vorgibt und standardisiert.

Ein Beispiel mit dem Airbnb-Tool

Fragt man den Agenten, welche Möglichkeiten das Airbnb-Tool bietet, holt er sich die Funktionsliste selbst über das List-Tools-Tool. Zurück kommen unter anderem:

• Airbnb Search: Suche nach Angeboten mit Filtern und Paginierung – etwa Standort, Check-in- und Check-out-Datum, Anzahl Erwachsene, Kinder, Babys und Haustiere sowie Preisspanne.
• Airbnb Listing Details: detaillierte Informationen zu einem bestimmten Angebot über dessen Listing-ID.

Der Agent musste hier nichts vorgegeben bekommen – er hat sich die verfügbaren Funktionen, deren Beschreibungen und das Parameter-Schema selbst beschafft. Im Schema sieht man zum Beispiel ein Textfeld location (Stadt, Bundesland etc.), die Datumsfelder für Check-in und Check-out, die Zahl der Erwachsenen sowie Mindest- und Höchstpreis.

Stellt man dann eine konkrete Anfrage – etwa eine Unterkunft in Bangkok für sechs Personen bis maximal 50 Euro pro Nacht –, läuft der Agent zweistufig: Er ruft erst List Tools auf (er hat sich nichts gemerkt, da kein Memory aktiv ist), erkennt anhand des Schemas die nötigen Parameter und führt die Suche über Execute Tool aus. Das Ergebnis – etwa eine Unterkunft mit drei Betten für ca. 35 Euro pro Nacht – kommt zurück, und das mit nur zwei hinzugefügten Tools. Würde Airbnb mehr Funktionen anbieten, etwa zum Verwalten eigener Inserate, ließen sich diese über dasselbe Schema abbilden, ohne weitere Bausteine zu definieren.

So bauen Sie MCP in n8n nach

Die folgenden Schritte zeigen die Einrichtung am Airbnb-Beispiel. Es eignet sich gut zum Ausprobieren, weil dafür kein API-Schlüssel nötig ist.

1. Umgebungsvariable setzen: Setzen Sie N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGE auf true. Das erlaubt Community-Nodes den Zugriff auf Tools. Bei einer Docker-Installation (z. B. auf einem Hetzner-Server) tragen Sie das im Abschnitt environment der docker-compose-Datei ein und starten die Instanz neu.
2. AI-Agent anlegen: Erstellen Sie einen AI-Agent und hinterlegen Sie ein Modell (im Video GPT-4.1 Mini).
3. Community-Node installieren: Unter Settings → Community Nodes installieren Sie das Paket n8n-nodes-mcp und bestätigen den Hinweis zur Installation ungeprüften Codes aus öffentlichen Quellen.
4. MCP-Client-Tool hinzufügen: Über das Plus bei Tools nach „MCP“ suchen. Achtung: Nicht mit dem hauseigenen MCP Client Tool von n8n verwechseln – die Community-Variante ist am Box-Symbol erkennbar und derzeit umfangreicher.
5. Zugangsdaten anlegen: Als Verbindungsart stehen Command Line, Server-Sent Events und HTTP Streamable zur Wahl. Im Beispiel bleibt es bei Command Line. Die richtigen Werte stehen im Repository des jeweiligen MCP-Servers im Abschnitt zur Installation. Für Airbnb: Command npx, Argumente Schritt für Schritt eingetragen – -y, das Paket @openbnb/mcp-server-airbnb und optional --ignore-robots-txt.

Hinweis zu robots.txt: Die Option --ignore-robots-txt übergeht die Zugriffsregeln einer Website. Für eine Demo ist das vertretbar – in Produktivumgebungen sollten Sie die robots.txt der jeweiligen Dienste respektieren.

Die beiden Operationen einrichten

Anschließend brauchen Sie zwei MCP-Client-Tools mit unterschiedlichen Operationen:

• List Tools: Benennen Sie das Tool z. B. „Airbnb List Tools“ und geben Sie als Beschreibung an, dass es zum Abrufen aller verfügbaren Airbnb-Tools dient. Ein Test-Klick (Execute Step) sollte die bekannte Funktionsliste mit Namen, Beschreibung und Schema zurückgeben.
• Execute Tool: Ein zweites MCP-Client-Tool mit der Operation Execute Tool. Beschreibung: zum Ausführen von Airbnb-Tools, auflistbar über das List-Tools-Tool. Den Tool-Namen übergeben Sie als Expression, sodass der Agent selbst entscheidet, welche Funktion er aufruft; die Tool-Parameter lassen Sie frei, damit er sie selbst bestimmt.

Nach dem Aufräumen und Speichern lässt sich der Agent testen – etwa erneut mit der Bangkok-Anfrage. Er holt sich die Funktionsliste, gibt sie an das Modell zurück, entscheidet sich für die Suche und liefert passende Unterkünfte. Genau das Verhalten aus dem Konzeptteil, jetzt im eigenen Workflow.

Über n8n hinaus – und ein Wort zur Sicherheit

MCP beschränkt sich nicht auf Automatisierungsplattformen. Auch Desktop-Anwendungen wie Claude Desktop lassen sich mit MCP-Servern verbinden. Damit kann man im Chat Aufgaben an lokal installierte Programme delegieren – ein viel zitiertes Beispiel ist die Steuerung der 3D-Software Blender per MCP, bei der eine Person ohne Blender-Kenntnisse Renderings erstellt. Der MCP-Server läuft dabei lokal, das Sprachmodell selbst weiterhin über den Cloud-Dienst.

Bei aller Begeisterung gilt: MCP ist eine junge Entwicklung. Es gibt bereits Sicherheitsbedenken, und es wurden Sicherheitslücken gefunden. Gerade in Produktivumgebungen ist die Technologie mit Vorsicht zu genießen – es lohnt sich, die weitere Entwicklung zu beobachten, bevor man kritische Prozesse darauf aufsetzt.

Fazit

Das Model Context Protocol ist ein pragmatischer Standardisierungsansatz: Ein Sprachmodell lernt über einen MCP-Server selbst, was ein Dienst kann und wie man ihn anspricht – statt jede Funktion einzeln vorzudefinieren. Für komplexe KI-Agenten bedeutet das spürbar weniger Bausteine und Wartungsaufwand, im n8n-Beispiel genügen zwei Schritte: auflisten und ausführen. Der Ansatz ist überzeugend, aber noch jung. Wer ihn ausprobiert, sollte mit unkritischen Diensten beginnen und in Produktivumgebungen die offenen Sicherheitsfragen ernst nehmen.

Quelle: Model Context Protocol (MCP): Erklärung & n8n Tutorial (Deutsch) – YouTube-Kanal Philip Thomas.