Was ist das Model Context Protocol (MCP)?
Das Model Context Protocol (MCP) ist ein offener Standard, über den KI-Anwendungen externe Daten abrufen und Werkzeuge aufrufen können. Ein MCP-Server beschreibt, welche Informationen und Funktionen er bereitstellt. Die KI-Anwendung kann dieses Angebot abfragen, eine passende Funktion auswählen und das Ergebnis in ihre Antwort einbeziehen. So erhält ein Sprachmodell Zugang zu Informationen, die erst nach seinem Training entstanden sind.
„Context“ meint die Informationen, die dem Modell für seine aktuelle Aufgabe zur Verfügung stehen. Dazu können deine Frage, bisherige Nachrichten und Ergebnisse externer Abfragen gehören. Ob das Modell eine bestimmte Information bekommt, entscheidet die Anwendung. Sie kann einen kurzen Ausschnitt übergeben, obwohl im angeschlossenen System ein ganzes Archiv liegt.
Wozu braucht eine KI ein eigenes Protokoll?
Ein Sprachmodell kann eine plausible Antwort formulieren, auch wenn ihm für die Frage eine entscheidende Angabe fehlt. Braucht es den aktuellen Stand aus einer Anwendung, muss Software die richtige Datenquelle ansprechen, die Anfrage übersetzen und das Ergebnis zurückliefern. Solche Verbindungen ließen sich schon vor MCP programmieren. Dabei musste oft für jede Kombination aus KI-Anwendung und Datenquelle eine eigene Integration gepflegt werden.
Mit MCP kann ein Anbieter seine Funktionen einmal für verschiedene kompatible Clients beschreiben. Umgekehrt kann eine KI-Anwendung mehrere MCP-Server nach demselben Verfahren ansprechen. Die Arbeit am jeweiligen Datenbestand bleibt bestehen. Jemand muss festlegen, welche Abfragen sinnvoll sind, was die zurückgegebenen Felder bedeuten und wer sie lesen darf. Der Standard spart vor allem dort Arbeit, wo diese Integration mehrfach verwendet wird.
Anthropic stellte das Model Context Protocol 2024 vor. Seit 2025 gehört MCP zu den Gründungsprojekten der Agentic AI Foundation unter dem Dach der Linux Foundation. Die Spezifikation ist öffentlich. Entwickler können eigene Clients und Server implementieren und selbst entscheiden, mit welchem Sprachmodell sie diese kombinieren.
Wie funktioniert MCP?
Welche Aufgaben haben Host, Client und Server?
Der MCP-Host ist die Anwendung, mit der du arbeitest. Das kann eine Chatoberfläche, eine Entwicklungsumgebung oder eine Fachanwendung sein. Der Host verwaltet den Dialog mit dem Modell und bestimmt, welche externen Funktionen in diesem Dialog zur Verfügung stehen. In ihm läuft der MCP-Client. Dieser übernimmt den Austausch mit einem bestimmten MCP-Server. Ein Host kann für verschiedene Server jeweils einen eigenen Client verwalten.
| Komponente | Zuständigkeit |
|---|---|
| Host | Zeigt die Benutzeroberfläche, verwaltet den Modellkontext und entscheidet, welche Ergebnisse das Sprachmodell erhält. |
| Client | Fragt die Fähigkeiten eines MCP-Servers ab, sendet Anfragen und ordnet die Antworten den jeweiligen Aufrufen zu. |
| Server | Veröffentlicht die verfügbaren Ressourcen oder Funktionen und bearbeitet die eingehenden MCP-Anfragen. |
| Angeschlossenes Fachsystem | Verwaltet die eigentlichen Daten und Geschäftsregeln. Der MCP-Server kann auf eine bestehende API, eine Datenbank oder lokale Dateien zugreifen. |
„Server“ bezeichnet hier eine Rolle. Die Software kann auf deinem eigenen Rechner laufen oder über ein Netzwerk erreichbar sein. Das Sprachmodell kann an einem anderen Ort laufen. Die wichtigste Aufgabe des Servers besteht häufig darin, eine fachliche Anfrage in einen Aufruf an ein bereits vorhandenes System zu übersetzen.
Wie findet die KI ein verfügbares Werkzeug?
Bevor die Anwendung ein Werkzeug anbieten kann, braucht sie dessen Beschreibung. Mit tools/list fragt der Client beim Server die verfügbaren Tools ab. Zu einem Werkzeug gehören sein Name und ein Eingabeschema. Die Beschreibung soll der Anwendung und dem Modell vermitteln, welches Anliegen das Werkzeug bearbeiten kann. Das Schema hält in maschinenlesbarer Form fest, welche Argumente erwartet werden.
Für eine Aufgabe mit externem Zugriff kann das Modell einen Aufruf mit passenden Argumenten vorschlagen. Der Host entscheidet, ob der Aufruf zulässig ist oder ob er dir zuerst eine Bestätigung anzeigt. Über den Client gelangt der Aufruf mit tools/call zum Server. Dieser prüft die Anfrage, führt die vorgesehene Operation aus und gibt das Ergebnis zurück. Nun kann der Host den Inhalt anzeigen oder dem Sprachmodell für die nächste Antwort übergeben.
Welche Daten ein Werkzeug erwartet, steht in seinem inputSchema. Das Schema kann Pflichtfelder und zulässige Datentypen festlegen. Für strukturierte Ergebnisse kann der Anbieter zusätzlich ein outputSchema veröffentlichen. Damit kann der Host die Rückgabe prüfen und einzelne Felder direkt anzeigen. Ob ein angegebener Wert in der Sache stimmt, muss das Fachsystem entscheiden. Eine formal gültige Zahl kann fachlich falsch sein.
Eine erfolgreiche Übertragung und ein fachlich erfolgreicher Auftrag sind zwei unterschiedliche Ergebnisse. Der Server kann die Anfrage korrekt empfangen und als Werkzeugergebnis melden, dass sich die gewünschte Aktion nicht ausführen ließ. Solche Fehler kann er mit isError kennzeichnen. Der Host muss diese Rückmeldung auswerten, bevor er dir eine abgeschlossene Aktion bestätigt.
Was sind Tools, Resources und Prompts in MCP?
MCP-Server können drei Arten von Funktionen anbieten. Für die Auswahl zählt, was die KI-Anwendung mit dem Angebot tun soll. Will sie gezielt einen Inhalt lesen, eine Operation ausführen oder eine vorbereitete Anweisung abrufen? Ein Server kann sich auf eine dieser Aufgaben beschränken.
| Serverfunktion | Was der Client erhält | Wichtige Methoden |
|---|---|---|
| Tools (Werkzeuge) | Eine aufrufbare Funktion mit benannten Eingaben. Der Aufruf kann Informationen liefern oder Daten verändern. | tools/list und tools/call |
| Resources (Ressourcen) | Adressierbare Inhalte. Jede Ressource hat eine eindeutige Kennung, die URI. | resources/list und resources/read |
| Prompts (Vorlagen) | Vorbereitete Nachrichten, die der Host abrufen und für den Modelldialog verwenden kann. Eine Vorlage kann Argumente annehmen. | prompts/list und prompts/get |
Wann ist eine Ressource sinnvoll, wann ein Tool?
Eine Ressource eignet sich für Inhalte, die sich über eine Adresse wiederfinden lassen. Der Client liest sie mit ihrer URI, einem Uniform Resource Identifier. Für die Anwendung ist das praktisch, wenn sie genau auf denselben Inhalt verweisen oder ihn später erneut abrufen will. Der Server kann außerdem Ressourcenvorlagen anbieten, wenn sich die Adresse erst aus einem Parameter ergibt.
Ein Tool passt, wenn der Server eine Operation mit bestimmten Eingaben ausführen soll. Auch eine reine Suchabfrage kann ein Tool sein. Der Unterschied liegt im Vertrag mit dem Client. Bei der Ressource benennt der Client den Inhalt, den er lesen möchte. Beim Tool nennt er eine Funktion und liefert die Argumente. Ob diese Funktion Daten verändern darf, ist eine separate Entscheidung.
Was bringt ein Prompt auf dem Server?
Ein MCP-Prompt macht eine vorbereitete Anweisung in mehreren kompatiblen Anwendungen nutzbar. Nutzer können eine Vorlage auswählen, der Client kann ihr Argumente mitgeben, und der Server liefert die fertigen Nachrichten zurück. Der Host entscheidet anschließend, wie er sie in den Dialog einfügt. Das Abrufen der Vorlage löst für sich genommen keine Modellantwort aus.
Das ist für Teams interessant, die für eine wiederkehrende Aufgabe dieselben Begriffe und dasselbe Ausgabeformat verwenden möchten. Die Qualität der Vorlage hängt weiterhin von der Aufgabenstellung ab. Wie man Eingaben formuliert und an ihren Ergebnissen prüft, beschreibt unser Beitrag zum Prompt Engineering.
MCP-Beispiel: Sind im Töpferkurs noch zwei Plätze frei?
Du möchtest am Samstag mit einer Freundin einen Töpferkurs besuchen. Auf der Kursseite steht „maximal zwölf Personen“. Im Chat des Veranstalters fragst du: „Sind im Anfängerkurs um zehn noch zwei Plätze frei?“ Der veröffentlichte Beschreibungstext verrät die Kapazität. Die Antwort auf deine Frage steht im Buchungssystem. Der Veranstalter hat dafür ein lesendes MCP-Tool eingerichtet.
| Schritt | Was in diesem Fall passiert |
|---|---|
| Kurs bestimmen | Der Assistent ordnet Titel, Datum und Uhrzeit einem konkreten Termin zu. Passen zwei Termine zur Anfrage, fragt er nach. |
| Belegung abfragen | Der Client ruft das vom Veranstalter definierte Werkzeug kursverfuegbarkeit mit der Terminkennung auf. Der Server liest den aktuellen Stand aus dem Buchungssystem. |
| Ergebnis auswerten | Zwölf Plätze sind vorgesehen. Neun sind fest gebucht, einer ist vorübergehend reserviert. Das Buchungssystem meldet zwei buchbare Plätze. |
| Antworten | „Ja, laut aktuellem Buchungsstand sind für diesen Termin zwei Plätze frei.“ Der Host kann den Zeitpunkt der Abfrage mit anzeigen. |
Was gewinnt die Antwort durch MCP? Der Assistent kann die Zahl aus dem zuständigen System beziehen. Würde er lediglich die neun festen Buchungen von zwölf abziehen, käme er auf drei freie Plätze. Dabei übersähe er die laufende Reservierung. Welcher Platz als buchbar gilt, weiß die Buchungssoftware. Ein gut entworfenes Tool liefert deshalb direkt die für den Nutzer relevante Zahl.
Deine nächste Nachricht lautet: „Dann melde uns beide an.“ Dafür braucht die Anwendung eine Schreibfunktion und die passende Berechtigung. Zwischen Auskunft und Anmeldung kann jemand den letzten freien Platz belegen. Das Buchungssystem muss beim Schreiben die Verfügbarkeit erneut prüfen und beide gewünschten Plätze verbindlich zuteilen können. Erst die erfolgreiche Buchungsbestätigung rechtfertigt die Antwort „Ihr seid angemeldet“. Mit reinem Lesezugriff kann der Assistent dir die Verfügbarkeit nennen und den Buchungsweg zeigen.
Was unterscheidet MCP von einer API, Function Calling und RAG?
Eine Application Programming Interface (API) legt fest, wie Software eine andere Anwendung ansprechen kann. MCP definiert eine gemeinsame Schnittstelle speziell für den Austausch zwischen KI-Anwendungen und Kontext- oder Werkzeuganbietern. In der Praxis kann ein MCP-Server eine vorhandene REST-API aufrufen. Der Betreiber pflegt die Übersetzung zwischen dem MCP-Werkzeug und den Endpunkten seines Dienstes.
| Begriff | Welche Frage beantwortet er? |
|---|---|
| API | Wie kann Software mit diesem konkreten Dienst Daten austauschen oder eine Funktion auslösen? |
| Function Calling | Wie teilt das Modell der Anwendung mit, welche Funktion es mit welchen Argumenten verwenden möchte? |
| MCP | Wie kann der Host bei unterschiedlichen Servern Angebote entdecken, Inhalte abrufen und Werkzeuge nach einem gemeinsamen Protokoll aufrufen? |
| Retrieval-Augmented Generation (RAG) | Wie findet die Anwendung passende Informationen und stellt sie dem Modell für eine darauf gestützte Antwort bereit? |
Wie spielen MCP und RAG zusammen?
Bei RAG sucht eine Anwendung zuerst nach relevanten Inhalten und gibt ausgewählte Fundstellen an das Modell weiter. Die Suche kann Stichwörter, Vektoren oder eine Kombination nutzen. Ein MCP-Server kann diese Suche als Werkzeug bereitstellen. Welche Dokumente im Suchindex stehen und nach welchen Kriterien die Treffer sortiert werden, bestimmt der Suchdienst.
Für die Qualität der Antwort lohnt es sich, die beiden Schritte getrennt zu betrachten. Hat die Suche das richtige Dokument in der gültigen Fassung gefunden? Hat das Sprachmodell die Fundstelle richtig wiedergegeben? Eine MCP-Verbindung kann technisch einwandfrei funktionieren, obwohl die Antwort auf einem überholten Dokument beruht. Um das nachzuvollziehen, helfen eine Quellenkennung und ein Änderungsdatum im Suchergebnis. Ob der Server diese Angaben liefert, hängt von seiner Implementierung ab.
Welche Rolle spielt MCP bei KI-Agenten?
Ein KI-Agent kann ein Ziel über mehrere Schritte verfolgen. Der Host gibt dafür Werkzeuge frei, verarbeitet die Zwischenergebnisse und entscheidet nach seinen Regeln, ob ein weiterer Aufruf erfolgen darf. MCP standardisiert die einzelnen Zugriffe. Die Planung, das Ende des Auftrags und die Entscheidung, wann ein Mensch eingreifen soll, liegen in der Anwendung. Mehr zur Rolle von Modellen und Agenten erklärt unser Grundlagenartikel über künstliche Intelligenz.
Wie verbindet man einen MCP-Server?
Für eine MCP-Anbindung brauchst du einen Host mit MCP-Unterstützung, einen passenden Server und Zugang zu den gewünschten Daten oder Funktionen. Welche Angaben du bei der Einrichtung brauchst, hängt vom Transport ab. Das Protokoll verwendet JSON-RPC 2.0 für die Nachrichten. Der Transport bestimmt, auf welchem Weg diese Nachrichten zum Server und zurück gelangen.
Lokal über stdio oder über Streamable HTTP
Bei stdio startet der Client den MCP-Server als lokalen Unterprozess. Er sendet Protokollnachrichten über die Standardeingabe und liest Antworten über die Standardausgabe. Für diese Verbindung ist kein eigener Netzwerkendpunkt nötig. Welche Dateien der Prozess erreichen kann, hängt unter anderem von den Rechten ab, unter denen er läuft. Ob er für seine Arbeit externe Dienste kontaktiert, bestimmt die Serversoftware.
Bei Streamable HTTP spricht der MCP-Client einen HTTP-Endpunkt an. Der Server kann eine gewöhnliche JSON-Antwort liefern oder für die Anfrage einen Ereignisstrom verwenden (Server-Sent Events, SSE). Dieser Transport eignet sich für zentral betriebene Dienste, auf die mehrere Clients zugreifen. Ob ein bestimmtes Werkzeug verfügbar ist, ergibt sich aus dem Angebot des Servers und den Rechten des jeweiligen Nutzers.
Warum spielt die Protokollversion eine Rolle?
Die MCP-Spezifikation trägt eine Datumskennung. In der am 12. November 2026 aktuellen Revision 2026-07-28 ist jede Anfrage auf Protokollebene in sich abgeschlossen. Der Client gibt die verwendete Version bei der Anfrage an. Mit server/discover kann er vorab erfahren, welche Protokollversionen und Fähigkeiten der Server unterstützt. Das erleichtert die Fehlersuche, wenn zwei Programme zwar MCP anbieten, aber unterschiedliche Revisionen beherrschen.
Ältere Anleitungen beschreiben häufig einen vorgeschalteten Austausch über initialize. Dieser Ablauf gehört zur früheren Revision 2025-11-25. Die Versionsangabe hilft daher schon vor der Installation eines Servers. Ein technisch erreichbarer Endpunkt und eine gemeinsame Protokollversion sind zwei verschiedene Voraussetzungen für den Austausch.
Wer entscheidet, auf welche Daten die KI zugreifen darf?
Der Host entscheidet, welche MCP-Server und Werkzeuge er einbindet. Der Server und das angeschlossene Fachsystem müssen prüfen, auf welche Inhalte der jeweilige Nutzer zugreifen darf. Eine Bestätigung im Chat kann die Zustimmung zu einer Aktion erfassen. Die erforderliche Berechtigung muss das zuständige System unabhängig davon durchsetzen.
Für den Zugriff auf geschützte MCP-Server über HTTP beschreibt die Spezifikation ein Autorisierungsverfahren auf Basis von OAuth 2.1. Der Client kann im Auftrag des Nutzers ein Zugriffstoken für den vorgesehenen MCP-Server erhalten. Der Server prüft, ob dieses Token für ihn bestimmt ist und die angeforderte Operation abdeckt. Die Anmeldung beantwortet die Frage nach der Identität. Die Autorisierung legt fest, welche Aktion mit dieser Identität erlaubt ist.
Darf ein abgerufenes Dokument der KI Anweisungen geben?
Ein MCP-Server kann Dokumente zurückgeben, die andere Personen bearbeitet haben. Darin können Aufforderungen stehen, die wie ein neuer Arbeitsauftrag klingen. Übernimmt ein Modell solche Anweisungen aus fremden Inhalten, spricht man von einer indirekten Prompt Injection. Für den Host bleibt der Auftrag des Nutzers maßgeblich. Eine Passage in einem Suchtreffer kann weder zusätzliche Berechtigungen erteilen noch die Freigabe für einen weiteren Werkzeugaufruf ersetzen.
Wie viele Daten gehören in den Modellkontext?
Die Datenmenge lässt sich schon vor der Übergabe an das Modell begrenzen. Bei einer Datenanalyse kann das Fachsystem eine Kennzahl berechnen und mit Einheit und Bezugszeitraum zurückgeben. Der Host benötigt dann häufig nur dieses Ergebnis. Einzelne Datensätze bleiben in der Quelle. Das spart Platz im Kontextfenster und erleichtert die Prüfung, welche Informationen die Anwendung tatsächlich weitergibt.
Was sieht der Modellanbieter?
Die Antwort hängt vom Weg der Daten ab. Ein lokaler MCP-Server kann Inhalte vom eigenen Rechner lesen. Nutzt der Host ein Sprachmodell in der Cloud und fügt diese Inhalte in dessen Kontext ein, werden sie bei der Modellanfrage an den Anbieter übertragen. Bei der Auswahl einer Integration sind deshalb zwei Fragen wichtig: Welche Daten darf der Server abrufen? Welchen Teil des Ergebnisses gibt der Host an welches Modell weiter?
Quelle: datenbasiert.de
