Model Context Protocol (MCP): Was es verbindet, wie es funktioniert und was es nicht garantiert

Definition: Was ist MCP?

Das Model Context Protocol, kurz MCP, ist ein offener Standard, der KI-Anwendungen mit externen Systemen verbinden soll, etwa mit Datenquellen und Tools. Diese allgemeine Beschreibung findet sich sowohl in der Ankündigung von Anthropic als auch in den bereitgestellten Referenzen zum Protokoll. Praktisch betrachtet geht es bei MCP um ein Integrationsproblem: Verschiedene Anwendungen müssen Informationen mit externen Diensten austauschen. Ein gemeinsames Protokoll soll verhindern, dass jede Verbindung eine völlig andere Schnittstelle benötigt.

Das Wort „Protokoll“ ist dabei wichtig. MCP ist für sich genommen weder ein Sprachmodell noch eine Datenbank oder eine Anwendung, die entscheidet, was zu tun ist. Es bezeichnet eine standardisierte Art, KI-Anwendungen mit anderen Systemen zu verbinden. Die für diesen Eintrag verfügbaren Unterlagen reichen aus, um diesen allgemeinen Geltungsbereich zu beschreiben. Sie genügen jedoch nicht, um die detaillierte Architektur, die Nachrichten oder die technischen Zuständigkeiten der einzelnen Komponenten verlässlich nachzuzeichnen. Deshalb schreibt diese Definition dem Protokoll keine Operationen oder Garantien zu, die durch die vorliegenden Quellen nicht belegt sind.

Für die Prüfung normativer Einzelheiten ist die offizielle Spezifikation die geeignete Referenz. Die daraus für diesen Eintrag abgerufenen Informationen bestätigen allerdings lediglich, dass es sich um ein offenes Protokoll zur Integration von KI-Anwendungen mit Daten und Tools handelt. Sie enthalten nicht die technischen Einzelheiten, die nötig wären, um den vollständigen Austauschablauf zu beschreiben. Diese Unterscheidung ist wichtig: Eine Spezifikation als Primärquelle zu erkennen, ist nicht dasselbe, wie ihren Inhalt im Detail überprüft zu haben.

Wie sich die Funktionsweise beschreiben lässt, ohne mehr zu behaupten, als wir wissen

Auf konzeptioneller Ebene soll eine MCP-Integration eine gemeinsame Möglichkeit schaffen, mit der eine KI-Anwendung mit externen Systemen interagieren kann. Die Anwendung, die Informationen oder Funktionen benötigt, verbindet sich über das Protokoll mit Systemen, die Daten oder Tools bereitstellen. Diese Beschreibung fasst den in den Quellen genannten Integrationszweck zusammen. Sie ist nicht als Spezifikation von Rollen, Transportwegen, Nachrichten oder verbindlichen Schritten zu verstehen.

Um genau zu beschreiben, wer eine Verbindung initiiert, welche Nachrichten ausgetauscht werden, wie Funktionen bekannt gemacht werden oder wie Ergebnisse zurückgegeben werden, muss der normative Text der einschlägigen Version herangezogen werden. Die bereitgestellten Auszüge beantworten diese Fragen nicht. Sie zeigen auch nicht, was ein Client implementieren oder ein Server veröffentlichen muss. Solche Einzelheiten als bestätigt darzustellen, würde eine allgemeine Beschreibung in eine technisch nicht belegte Erklärung verwandeln.

Es ist deshalb sinnvoll, zwei Ebenen auseinanderzuhalten. Die erste betrifft den Zweck: eine standardisierte Schnittstelle bereitzustellen, über die KI-Anwendungen mit Daten und Tools verbunden werden können. Die zweite betrifft die konkrete Implementierung: die Komponenten, Operationen und Bedingungen, mit denen eine MCP-Version diesen Zweck verwirklicht. Die verfügbaren Quellen stützen die erste Ebene. Die zweite muss in der Spezifikation überprüft werden, bevor sie als Entwicklungsleitfaden dienen kann.

Für alle, die eine Integration beurteilen, ergibt sich daraus eine einfache Konsequenz: Es reicht nicht, dass ein Produkt die Bezeichnung MCP verwendet. Zu prüfen ist, welche Version es implementiert, welche Funktionen es unterstützt und wie es Berechtigungen und Ergebnisse behandelt. Das ist eine Empfehlung für die Bewertung und keine Behauptung, MCP schreibe für all diese Aufgaben einen bestimmten Mechanismus vor.

Drei Anwendungsbeispiele – mit der nötigen Vorsicht

Die folgenden Szenarien veranschaulichen, welche Art von Bedarf eine standardisierte Verbindung zwischen einer KI-Anwendung und einem externen System begründen kann. Es handelt sich um konzeptionelle Beispiele, nicht um Implementierungsanleitungen und auch nicht um Behauptungen darüber, dass MCP eine bestimmte Funktion auf eine konkrete Weise definiert. Insbesondere belegen die verfügbaren Materialien nicht, welche genaue Schnittstelle ein Server in diesen Fällen anbieten müsste oder welche Operationen ein Client implementieren muss.

In allen drei Fällen sollte die Grenze zwischen der Nutzeranfrage, der KI-Anwendung und dem System, das die Daten vorhält oder die Aktion ausführt, klar bleiben. Eine bestehende Verbindung bedeutet nicht, dass jede Anfrage weitergeleitet oder jedes Ergebnis ungeprüft übernommen werden sollte.

MCP, API, Tool-Aufruf und Agent: unterschiedliche Konzepte

Eine API ist eine Schnittstelle, über die ein Programm Dienste oder Daten von einem anderen System anfordern kann. MCP wird den überprüften allgemeinen Beschreibungen zufolge als Integrationsstandard verstanden, der KI-Anwendungen mit externen Systemen verbindet. Die Begriffe sollten daher nicht gleichgesetzt werden: Eine API kann die Schnittstelle eines bestimmten Dienstes sein; MCP wird als offenes Protokoll beschrieben, das Verbindungen im Bereich der KI-Anwendungen standardisieren soll. Die verfügbaren Quellen erläutern nicht im Detail, wie die jeweilige MCP-Implementierung mit einer zugrunde liegenden API zusammenhängt.

Ein Tool-Aufruf durch ein Modell ist ein anderes Konzept. Er bezeichnet die Fähigkeit eines Modells oder einer Anwendung, die Nutzung einer Funktion vorzuschlagen. Das entspricht nicht automatisch MCP. Eine Anwendung kann einen eigenen Mechanismus für Tool-Aufrufe haben; ob ein Tool über ein gemeinsames Protokoll angebunden ist, betrifft eine andere Ebene der Integration. Dieser Vergleich ist konzeptionell und schreibt der Spezifikation keine normative Definition von Tool-Aufrufen zu.

Mit „Agent“ ist im allgemeinen technischen Sprachgebrauch oft ein System gemeint, das Schritte planen oder Aktionen ausführen kann, um ein Ziel zu erreichen. Das Verbindungsprotokoll ist nicht der Agent. Es kann Teil der Infrastruktur sein, die ein Agent oder eine Anwendung nutzt, um auf externe Systeme zuzugreifen. Ob eine verbundene Anwendung handeln darf, ob das Modell eine passende Aktion auswählt und ob das Ergebnis zuverlässig ist, sind davon getrennte Fragen.

Diese Unterscheidung verhindert einen häufigen Fehler: dem Protokoll das gesamte Verhalten einer Anwendung zuzuschreiben. Ein Protokoll kann eine Integrationsschnittstelle standardisieren. Die Anwendung entscheidet, wie sie diese Schnittstelle in ihr Produkt einbindet, und die Richtlinien des Systems bestimmen, welche Aktionen zulässig sind. Aus der allgemeinen Beschreibung von MCP geht nicht hervor, dass diese Ebenen auf eine einzige Weise geregelt sind.

Tools, Ressourcen und Prompts: Begriffe, die präzise definiert werden müssen

Der redaktionelle Vorschlag nennt „Tools“, „Ressourcen“ und „Prompts“ als Konzepte, die anhand der Spezifikation erklärt werden sollten. Die bereitgestellten Quellenauszüge enthalten jedoch keine technischen Definitionen dieser Begriffe. Sie reichen auch nicht aus, um festzustellen, ob jeder Begriff in der geprüften Version eine präzise normative Bedeutung hat. Es ist sinnvoll, sie als zu überprüfende Fachbegriffe zu kennzeichnen, aber hier keine technische Definition so darzustellen, als sei sie verifiziert.

Im allgemeinen Sprachgebrauch bezeichnet ein Tool häufig eine Funktion, mit der sich eine Operation ausführen lässt; eine Ressource steht oft für abrufbare Informationen; und ein Prompt ist üblicherweise eine Anweisung oder Textvorlage. Diese Beschreibungen dienen der sprachlichen Orientierung und sind keine Definitionen von MCP. In einer konkreten Implementierung können die operative Bedeutung, die Art der Ermittlung und die Nutzungsregeln in der Spezifikation oder im Produkt festgelegt sein. Vor Entwicklungsentscheidungen muss die normative Dokumentation diese Fragen klären.

Diese Vorsicht betrifft auch die vorangegangenen Beispiele. Die Suche in Dokumentation ähnelt dem Zugriff auf Informationen, der Abruf von Daten kann eine Abfrage beinhalten, und eine Aktion kann eine ausführbare Funktion erfordern. Diese konzeptionelle Zuordnung reicht jedoch nicht aus, um zu behaupten, dass ein bestimmter Anwendungsfall einer bestimmten MCP-Kategorie entspricht. Dafür müssen das spezifizierte Schema und Verhalten geprüft werden.

Grenzen, Sicherheit und häufige Missverständnisse

Ein Verbindungsstandard beweist für sich genommen nicht, dass jedes angeschlossene System sicher ist. Die Beschreibung von MCP als offenem Integrationsprotokoll belegt weder, dass alle Server vertrauenswürdig sind, noch dass Berechtigungen richtig konfiguriert sind oder eine Anwendung Daten angemessen schützt. Ein bereitgestellter Leitfaden spricht von „sicherem“ Zugriff. Diese werbliche Formulierung weist jedoch keine technische Garantie des Protokolls nach. Aus Gründen der Genauigkeit sollte sie nicht als gesicherte Eigenschaft wiederholt werden.

Aus dem Integrationszweck folgt auch nicht, dass Ergebnisse korrekt sind. Eine Verbindung kann den Zugriff auf Informationen und Tools erleichtern. Die Genauigkeit hängt unter anderem von den verfügbaren Daten, der Abfrage, der Anwendung und den durchgeführten Prüfungen ab. Insbesondere beweist der Empfang einer Antwort durch eine Anwendung nicht, dass diese aktuell, vollständig oder für die anfragende Person freigegeben ist.

Ein weiterer Fehler ist die Annahme einer automatischen Interoperabilität. Ein Standard soll eine gemeinsame Vorgehensweise ermöglichen; die praktische Kompatibilität muss dennoch zwischen Versionen und Implementierungen geprüft werden. Die verfügbaren Materialien beschreiben nicht, welche Kompatibilitätsbedingungen MCP verlangt oder welche konkreten Mechanismen es dafür vorsieht. Dieser Eintrag behauptet daher nicht, dass sich zwei Produkte, die das Protokoll erwähnen, ohne Anpassungen miteinander verbinden lassen.

Schließlich bedeutet das Bereitstellen einer Funktion nicht, dass das System entscheidet, wann sie eingesetzt werden soll. Die Verfügbarkeit eines externen Tools bestimmt nicht von selbst, ob eine Anwendung es aufruft, ob das Modell die richtige Funktion auswählt oder ob die Aktion angemessen ist. Auswahl, Autorisierung, Bestätigung und Fehlerbehandlung sind Entscheidungen der Produktgestaltung und Implementierung, die gesondert bewertet werden müssen – es sei denn, die einschlägige Spezifikation beschreibt einen konkreten Mechanismus.

Praktische Kriterien zur Bewertung einer Integration

Bevor MCP eingeführt wird, sollte zunächst feststehen, welches Problem gelöst werden soll: die Verbindung einer KI-Anwendung mit Daten, mit Tools oder mit beidem. Danach sind die konkreten Systeme und die Art der betroffenen Informationen oder Aktionen zu bestimmen. Für das Abrufen zugriffsbeschränkter Dokumente gelten andere Anforderungen als für eine Aktion, die Datensätze verändert. Ein Standard kann einen gemeinsamen Rahmen für die Verbindung bieten, ersetzt aber nicht die Risikoanalyse des jeweiligen Anwendungsfalls.

Im nächsten Schritt sollten die aktuelle Spezifikation und die Produktdokumentation geprüft werden. Zu verifizieren sind die Version, der tatsächliche Umfang der Implementierung und die angebotenen Funktionen. Insbesondere sollten dort die Definitionen und Operationen von Tools, Ressourcen und Prompts sowie die Rollen und der Nachrichtenaustausch nachgeschlagen werden. Für diesen Eintrag lagen nicht genügend verifizierbare Inhalte vor, um diese Einzelheiten zu klären. Er sollte deshalb nicht als Implementierungshandbuch verwendet werden.

Abschließend sollten sowohl der normale Betrieb als auch Fehlerfälle getestet werden: fehlende Daten, unzureichende Berechtigungen, unerwartete Ergebnisse und unerwünschte Aktionen. Es muss feststehen, wer Änderungen autorisieren darf, welche Informationen gespeichert werden und wie eine Antwort vor einer Handlung validiert wird. Diese Schritte sind vorsichtige Bewertungskriterien und keine MCP zugeschriebenen Garantien. Entscheidend ist, die Standardisierung der Verbindung von Sicherheit, Qualität und Verhalten der Anwendung zu trennen.

Als erste Anlaufstelle für die weitere Recherche eignet sich die offizielle Spezifikation der vorgesehenen Implementierungsversion. Umfragen und Leitfäden aus zweiter Hand können Kontext liefern oder Risiken diskutieren, ersetzen aber nicht die normative Quelle, wenn die genaue Bedeutung einer Operation geklärt werden muss. Die hier einbezogenen Sekundärquellen bestätigen, dass MCP als Integrationsschnittstelle oder -standard beschrieben wird; allein reichen sie nicht aus, um technische Einzelheiten zu belegen.

Verwandte Begriffe