Was ist das Model Context Protocol (MCP)? Der Standard, der KI mit Werkzeugen und Daten verbindet

Das Model Context Protocol (MCP) ist ein offener Standard, der KI‑Anwendungen ermöglicht, über eine einheitliche Schnittstelle mit externen Werkzeugen, Daten, Eingabeaufforderungen und anderen Fähigkeiten zu verbinden. Anstatt für jede Modell‑und‑System‑Kombination eine eigene Integration zu bauen, können Entwickler ein gemeinsames Protokoll zwischen einem KI‑Host und einem MCP‑Server implementieren.

MCP wird häufig als universeller Connector für KI beschrieben, aber die Analogie ist unvollständig. Das Protokoll überträgt nicht nur Daten. Es definiert, wie Teilnehmer Fähigkeiten etablieren, Ressourcen und Aktionen bereitstellen, strukturierte Nachrichten austauschen und Sicherheitsgrenzen wahren. Das macht es zu einem wichtigen Bestandteil der entstehenden Infrastruktur für KI‑Assistenten und Agenten.

Warum MCP existiert

Ein Modell kann von allein keine privaten Unternehmensdokumente einsehen, ein lokales Repository prüfen, eine Live‑Datenbank abfragen oder einen internen Dienst aufrufen. Entwickler haben diese Fähigkeiten historisch über einmalige Plugins und anwendungsspezifische APIs angebunden.

Dieser Ansatz erzeugt ein Integrationsproblem. Wenn zehn KI‑Anwendungen jeweils mit zehn Systemen verbunden werden müssen, kann es dazu führen, dass Teams Dutzende maßgeschneiderter Adapter pflegen. Jeder Adapter kann Werkzeuge, Kontext, Authentifizierung, Fehler und Updates unterschiedlich darstellen.

MCP schafft einen gemeinsamen Vertrag. Eine MCP‑kompatible Anwendung kann mit MCP‑Servern kommunizieren, die Fähigkeiten in einem bekannten Format bereitstellen. Die offizielle Model Context Protocol‑Spezifikation definiert das Protokoll, während einzelne Hosts und Server entscheiden, welche Funktionen und Sicherheitsrichtlinien sie unterstützen.

Die MCP‑Architektur

MCP trennt die Konversation und Modelllogik der KI‑Anwendung von der Integrationslogik, die für jede Datenquelle oder jeden Dienst erforderlich ist. Der Host kann mehrere Client‑Verbindungen gleichzeitig aufrechterhalten – eine für einen Dateisystem‑Server, eine für einen Datenbank‑Server und eine weitere für eine Business‑Anwendung – und dabei deren Fähigkeiten dem Modell über eine einheitliche Schnittstelle bereitstellen.

Der Server ist nicht zwingend ein entfernter Internet‑Dienst. Er kann lokal neben einer Desktop‑Anwendung, innerhalb eines Firmennetzwerks oder als Remote‑Dienst laufen. Diese Bereitstellungswahl ändert den Transport‑ und Vertrauensbereich, jedoch nicht die zentrale Beziehung: Ein Client entdeckt Fähigkeiten von einem Server und tauscht strukturierte Nachrichten mit ihm aus.

MCP verwendet eine Host‑Client‑Server‑Architektur.

• Host: die KI‑Anwendung, mit der der Nutzer interagiert, z. B. ein Assistent, eine Programmierumgebung oder eine Agenturplattform.
• Client: ein Protokoll‑Komponente, die vom Host erstellt wird, um eine Verbindung zu einem bestimmten MCP‑Server aufrechtzuerhalten.
• Server: ein Programm, das ausgewählte Werkzeuge, Ressourcen oder Eingabeaufforderungen für MCP‑Clients bereitstellt.

Ein Host kann gleichzeitig mit mehreren Servern verbunden sein. Ein Server könnte Zugriff auf ein Dateirepository bieten, ein anderer auf ein Projekt‑Management‑System und ein dritter auf eine interne Datenbank. Der Host bleibt verantwortlich für die Benutzererfahrung, die Modell‑Orchestrierung, die Einwilligung und die in den Modell‑Kontext eingebrachten Informationen.

Nachrichten werden nach JSON‑RPC‑Konventionen strukturiert. Während der Initialisierung verhandeln die Teilnehmer Protokollversionen und -fähigkeiten. Diese Verhandlung ist wichtig, weil Clients und Server nicht jede optionale Funktion implementieren müssen.

Werkzeuge, Ressourcen und Eingabeaufforderungen

MCP organisiert von Servern bereitgestellte Fähigkeiten in mehrere Primitive. Die drei bekanntesten sind Werkzeuge, Ressourcen und Eingabeaufforderungen.

Werkzeuge

Ein Werkzeug ist eine ausführbare Funktion, die die KI‑Anwendung aufrufen kann. Beispiele sind das Durchsuchen einer Kundendatenbank, das Erstellen eines Tickets, das Ausführen einer Abfrage oder das Abrufen des aktuellen Inventars. Eine Werkzeugdefinition enthält einen Namen, eine Beschreibung und ein Eingabeschema, damit Modell und Laufzeit wissen, welche Argumente erwartet werden.

Der Einsatz von Werkzeugen kann externe Systeme verändern, daher sollten Hosts aussagekräftige Beschreibungen anzeigen, Eingaben validieren, Berechtigungen anwenden und bei folgenreichen Aktionen eine Bestätigung verlangen.

Ressourcen

Eine Ressource ist ein Kontext, den eine Anwendung lesen kann, z. B. eine Datei, einen Datenbankeintrag, eine Dokumentationsseite oder einen erzeugten Bericht. Ressourcen verwenden Kennungen und können Metadaten wie einen Namen und Medientyp bereitstellen. Sie geben Hosts eine standardisierte Möglichkeit, Informationen zu entdecken und abzurufen, ohne vorzugeben, dass jeder Lesevorgang eine Aktion ist.

Eingabeaufforderungen

Eingabeaufforderungen sind wiederverwendbare Vorlagen oder Workflows, die ein Server dem Host zur Verfügung stellt. Sie können Nutzern helfen, eine Fähigkeit korrekt aufzurufen, strukturierte Argumente bereitzustellen oder domänenspezifische Anweisungen mit relevantem Kontext zu kombinieren.

MCP unterstützt auch Fähigkeiten in die entgegengesetzte Richtung. Je nach Verhandlung kann ein Server den Host auffordern, Modell‑Vervollständigungen oder Benutzereingaben zu erhalten. Das wichtige Gestaltungsprinzip ist die explizite Verhandlung von Fähigkeiten, anstatt anzunehmen, dass jeder Teilnehmer jede Operation ausführen kann.

Was geschieht während eines MCP‑Werkzeugaufrufs?

Betrachten Sie einen KI‑Code‑Assistenten, der mit einem Repository‑Analyse‑Server verbunden ist.

1. Der Host verbindet sich mit dem MCP‑Server und verhandelt unterstützte Fähigkeiten.
2. Der Client fordert die Liste der verfügbaren Werkzeuge an.
3. Der Server gibt strukturierte Werkzeugdefinitionen zurück, einschließlich ihrer Eingabeschemata.
4. Der Host stellt dem Modell ausgewählte Werkzeugbeschreibungen zur Verfügung.
5. Das Modell schlägt einen Werkzeugaufruf vor, z. B. die Suche nach Verweisen auf eine Funktion.
6. Der Host prüft die Richtlinie und bittet bei Bedarf den Benutzer um Genehmigung.
7. Der Client sendet die validierte Anfrage an den Server.
8. Der Server führt die Operation aus und gibt strukturierte Inhalte oder einen Fehler zurück.
9. Der Host entscheidet, welchen Teil des Ergebnisses er dem Modell für den nächsten Schritt zur Verfügung stellt.

MCP standardisiert den Austausch, entscheidet jedoch nicht, ob dem Modell vertraut werden kann, ein Werkzeug aufzurufen. Diese Entscheidung liegt beim Host und seiner Richtlinienebene.

MCP ersetzt keine APIs

Ein MCP‑Server kapselt oft bestehende APIs, Software‑Development‑Kits, Befehlszeilen‑Tools oder Datenbank‑Treiber. Diese zugrunde liegenden Schnittstellen führen nach wie vor die eigentliche Arbeit aus. MCP fügt darüber eine KI‑orientierte Entdeckungs‑ und Interaktionsebene hinzu.

Diese Unterscheidung erklärt, warum MCP eine Ergänzung zu REST, GraphQL und anderen Anwendungs‑Schnittstellen darstellt. Ein Zahlungsdienst kann seine ausgereifte API beibehalten, während ein MCP‑Server ein sorgfältig begrenztes Teilset von Operationen mit modellfreundlichen Beschreibungen und Schemata bereitstellt.

MCP vs. Funktionsaufruf

Funktions‑ oder Werkzeugaufruf ist eine Modell‑Fähigkeit: Das Modell kann eine strukturierte Anfrage zurückgeben, um eine Funktion aufzurufen. MCP ist ein Protokoll zum Entdecken und Kommunizieren mit Anbietern von Werkzeugen und Kontext.

Die beiden arbeiten häufig zusammen. Ein MCP‑Server teilt dem Host mit, welche Werkzeuge existieren. Der Host präsentiert ausgewählte Definitionen einem Modell. Das Modell erzeugt einen Werkzeugaufruf. Der Host verwendet dann MCP, um diese Anfrage an den entsprechenden Server zu senden.

MCP vs. Agent2Agent

MCP verbindet eine KI‑Anwendung mit Fähigkeiten und Kontext. Agent2Agent, oder A2A, konzentriert sich auf die Kommunikation zwischen autonomen Agenten, die verschiedenen Systemen oder Organisationen gehören können.

Ein praktisches System kann beides nutzen. Ein Agent könnte MCP verwenden, um auf seine Werkzeuge und Daten zuzugreifen, und dann A2A einsetzen, um eine größere Aufgabe an einen anderen Agenten zu delegieren. MCP beantwortet „Wie kann diese Anwendung diese Fähigkeit nutzen?“, A2A beantwortet „Wie können diese Agenten die Arbeit koordinieren?“

Sicherheitsrisiken und Kontrollen

Ein sicherer Host führt eine explizite Positivliste von Servern und Werkzeugen, zeigt eine aussagekräftige Zustimmung an, wenn Zugriff gewährt wird, und verknüpft jeden Aufruf mit dem Benutzer‑ oder Arbeitslast‑Identität, die ihn autorisiert hat. Werkzeugschemata sollten so eng sein, dass unerwartete Argumente abgelehnt werden, während Audit‑Logs den Server, die Fähigkeit, Eingaben, Ergebnisstatus und Genehmigungsweg protokollieren.

Zurückgegebene Ressourcen und Werkzeugergebnisse stellen ebenfalls eine Angriffsfläche für Prompt‑Injection dar. Ein über MCP gelesenes Dokument kann Text enthalten, der das Modell auffordert, seine Anweisungen zu ignorieren oder Daten zu exfiltrieren. Der Host muss die Unterscheidung zwischen nicht vertrauenswürdigem Inhalt und Systemrichtlinie wahren und sollte verhindern, dass die Ausgabe eines Servers stillschweigend die Berechtigungen eines anderen Servers erweitert.

Standardisierung verbessert die Interoperabilität, macht einen Server jedoch nicht vertrauenswürdig. Ein MCP‑Server kann sensible Daten, irreführende Werkzeugbeschreibungen, unsichere Aktionen oder kompromittierte Abhängigkeiten preisgeben. Nicht vertrauenswürdiger Inhalt, der über eine Ressource abgerufen wird, kann ebenfalls Prompt‑Injection‑Anweisungen enthalten, die das Modell manipulieren sollen.

Wichtige Kontrollen umfassen:

• Minimalprinzip: Gib jedem Server nur die Anmeldedaten und den Umfang, die für seinen Zweck nötig sind.
• Server‑Vertrauen: Überprüfe Quelle, Code, Eigentümerschaft und Aktualisierungspfad von Servern, bevor du sie verbindest.
• Benutzer‑Transparenz: Mache deutlich, welcher Server Daten erhält und welche Aktion er ausführt.
• Eingabevalidierung: Erzwinge Schemata und Geschäftsregeln außerhalb des Modells.
• Genehmigungsgrenzen: Bestätige sensible, externe, finanzielle oder destruktive Aktionen.
• Datenminimierung: Vermeide das Senden kompletter Dokumente oder Unterhaltungen, wenn nur ein kleiner Teil benötigt wird.
• Protokollierung und Widerruf: Zeichne Aufrufe auf, überwache Anomalien und ermögliche das einfache Deaktivieren von Anmeldedaten und Verbindungen.

Das MCP‑Projekt verfeinert weiterhin seine Architektur und Sicherheitsrichtlinien. Das 2026 specification update des Projekts zeigt, wie sich der Standard hin zu einfacherer Infrastruktur, Autorisierung und Produktionseinsatz entwickelt.

Wann sollten Entwickler MCP einsetzen?

MCP ist besonders geeignet, wenn mehrere KI‑Clients eine konsistente Verbindung zur gleichen Fähigkeit benötigen, Werkzeuge zur Laufzeit auffindbar sein sollen oder ein Team die KI‑Orchestrierung vom system‑spezifischen Integrationscode trennen möchte.

Ein direkter Funktionsaufruf kann für eine kleine Anwendung mit einem streng kontrollierten Backend einfacher bleiben. Die Einführung des Protokolls bringt eigenen Betriebsaufwand mit sich: Verwaltung des Server‑Lebenszyklus, Kompatibilitätstests, Authentifizierung, Beobachtbarkeit und Governance.

Was man über das Model Context Protocol (MCP) wissen sollte

MCP ist eine gemeinsame Sprache zwischen KI‑Anwendungen und den Werkzeugen sowie dem Kontext um sie herum. Sein Wert entsteht dadurch, dass isolierte Integrationskonventionen durch ein auffindbares, strukturiertes und erweiterbares Protokoll ersetzt werden.

Der Standard beseitigt nicht die Notwendigkeit sorgfältiger Technik. Hosts müssen weiterhin entscheiden, welchen Servern sie vertrauen, welche Fähigkeiten sie bereitstellen, welche Daten sie teilen und wann eine Person eine Aktion genehmigen muss. MCP macht Verbindungen portabel; Governance macht sie sicher und nützlich.