MCP erklärt: Wie KI-Anwendungen Daten und Werkzeuge anbinden

Was das Model Context Protocol verbindet

MCP steht für Model Context Protocol. Es standardisiert Teile dieses Austauschs, darunter Beschreibungen und Aufrufe angebotener Fähigkeiten. Der Server kann dahinter weiterhin eine Datei, Datenbank oder normale API verwenden.

Stell dir eine KI-Anwendung vor, die eine freigegebene Projektnotiz lesen soll. Statt jede Verbindung ausschließlich als individuelle Sonderlösung aufzubauen, kann die Anwendung einen unterstützten MCP-Server nutzen. Dieser beschreibt, welche Daten oder Funktionen er anbietet.

Der Standard entscheidet nicht für dich, welches Modell geeignet ist, welche Daten verwendet werden dürfen oder ob ein Ergebnis stimmt. Auch eine neue Modellversion macht einen bestehenden Client nicht automatisch mit jeder Serverfunktion kompatibel. Die verbreitete Steckeranalogie hilft beim Einstieg, hat hier aber klare Grenzen.

Host, Client und Server an einem Beispiel

Der Host kann mehrere Clients für mehrere Server verwalten. Das Sprachmodell arbeitet innerhalb dieses Anwendungsablaufs; es ist nicht allein wegen seiner Textantwort der MCP-Client. Ein konkretes Host-Beispiel zeigt die Anleitung „MCP in LM Studio einrichten“; Verbindung, Werkzeugaufruf und Freigaben werden dort getrennt geprüft.

„Server“ beschreibt hier die Rolle des Programms. Es kann lokal auf deinem Rechner oder entfernt laufen. Ein lokaler Server bedeutet wiederum nicht automatisch, dass das vom Host verwendete Modell ebenfalls lokal rechnet.

Unsere erfundene Notiz heißt Orion-Lernprobe, hat die Kennung TW-MCP-011 und den Status geprueft. Die eigenen Rollenkarten als JSON halten diese Zuordnung fest. Sie sind keine importierbare MCP-Konfiguration und enthalten keine Kontozugänge.

Tools, Resources und Prompts unterscheiden

Die offizielle Architektur nennt drei zentrale Fähigkeiten, die Server anbieten können. Nicht jeder Server oder Client muss jede Fähigkeit in derselben Weise unterstützen.

Ein Tool kann Daten lesen oder eine Veränderung auslösen. Die Kategorie „Tool“ bedeutet nicht automatisch „schreibend“, aber auch nicht automatisch „ungefährlich“. Entscheidend sind die tatsächliche Implementierung und der zugelassene Umfang.

Eine Beschreibung hilft dem Host, die Fähigkeit einzuordnen. Sie ersetzt keine serverseitige Eingabeprüfung oder Kontoberechtigung. Auch ein verständlicher Werkzeugname beweist nicht, dass ausschließlich der versprochene Datensatz gelesen wird.

Vom Werkzeugangebot zum kontrollierten Aufruf

Für den eigenen Lernfall lässt sich der Ablauf ohne echte Verbindung planen: Der Host kennt den gewählten Server, der Client erfährt dessen unterstützte Fähigkeiten und die Anwendung kann ein passendes Werkzeug mit geprüften Argumenten aufrufen. Das Ergebnis kommt als zusätzlicher Kontext zurück.

Ziel: Die fiktive Orion-Lernnotiz lesen.
Server: Eigener begrenzter Lernnotiz-Server.
Werkzeug: lernnotiz_lesen.
Erlaubte Kennung: TW-MCP-011.
Erwartete Fakten: Titel Orion-Lernprobe, Status geprueft.
Nicht erlaubt: andere Notizen, Schreiben, Versenden oder neue Verbindungen.
Fehlende Angabe: offen lassen, nichts ergänzen.

Bevor du einen echten Zugang verwendest, kontrolliere angebotene Funktionen und die Daten, die zurückkommen. Ein erfolgreiches Verbindungszeichen bestätigt noch nicht den fachlichen Erfolg des Aufrufs.

Die Lektion zeigt, wie du einen MCP-Zugang kontrolliert einrichten kannst. Für diesen Artikel wurde nur der eigene Rollen- und Aufrufplan erstellt, kein Server verbunden und kein Tool ausgeführt.

MCP, API und Skill haben unterschiedliche Aufgaben

Eine API stellt eine Schnittstelle zu einem System bereit. Ein MCP-Server kann eine solche API für eine KI-Anwendung zugänglich machen und seine Fähigkeiten in einem gemeinsamen Format beschreiben. Die eigentliche fachliche Logik und die Rechte des Zielsystems verschwinden dadurch nicht. Plane den gesamten KI-Ablauf, bevor du zusätzliche Werkzeuge freigibst: Eingang, erlaubte Aktionen und menschliche Prüfung müssen zusammenpassen.

Ein Skill bündelt dagegen Anweisungen und gegebenenfalls unterstützende Dateien für wiederkehrende Aufgaben. Er kann erklären, wie ein Agent ein vorhandenes Werkzeug sinnvoll verwendet. Er schafft dadurch nicht automatisch einen neuen technischen Zugang.

Wenn du Skills als wiederverwendbare Arbeitsanweisung einordnen möchtest, beginne mit einem kleinen Ablauf und klaren Grenzen. Skill und MCP können zusammenarbeiten; sie sind keine austauschbaren Bezeichnungen für dieselbe Komponente.

MCP verwaltet auch nicht automatisch das gesamte Gesprächsgedächtnis. Die offizielle Architektur grenzt den Kontextaustausch vom Umgang des Hosts mit LLM und Kontext ab. Ein Serveranschluss ist deshalb kein universelles „einmal verbinden, alles funktioniert“-Versprechen.

Zugriff und Protokollversion vor dem Einsatz prüfen

Die hier vollständig gelesene Architekturversion 2026-07-28 beschreibt zustandslose Anfragen mit Metadaten und die Erkennung über server/discover. Ältere Erklärungen mit einem allgemeinen initialize-Handshake lassen sich nicht unverändert auf diese Version übertragen. Prüfe, welche Version Host, Client und Server tatsächlich unterstützen.

Für den Transport unterscheidet die Architektur stdio als lokale Prozesskommunikation und streamable HTTP für HTTP-basierte Verbindungen. Transport, Anmeldung und die erlaubte fachliche Aktion sind verschiedene Prüffragen. „Lokal“ oder „OAuth“ ist allein keine vollständige Sicherheitsbewertung.

• Betreiber und Herkunft des Servers feststellen.
• Benötigte Daten und Werkzeuge bewusst begrenzen.
• Rechte des verbundenen Kontos und der Laufzeit prüfen.
• Schreibende Außenwirkungen gesondert freigeben.
• Fremde Daten als Quellen behandeln, nicht als neue Berechtigungsanweisung.

Ein konkretes Beispiel ist, die vier MCP-Wege von n8n unterscheiden zu können. Dort führen ähnlich benannte Verbindungen zu unterschiedlichen Richtungen und Rechten.

Stand: 20. Oktober 2026. Rollenkarte und Beispiele sind eigene Lernhilfen. Es wurden keine Programme installiert, Zugänge erweitert oder echte MCP-Anfragen gesendet.