Grundlagen & Glossar · Stand: 18. Oktober 2026

Model Context Protocol: Wie MCP Daten und Werkzeuge verbindet

Das Model Context Protocol (MCP) ist ein offenes Protokoll, über das KI-Anwendungen auf externe Datenquellen und Werkzeuge zugreifen können. Es beschreibt die gemeinsame Schnittstelle zwischen Anwendung und angebundenem Server. Welche Daten ein Nutzer sehen darf, welche Aktion ausgeführt werden soll und ob eine Antwort fachlich stimmt, müssen die beteiligten Systeme zusätzlich klären.

MCP ist damit weder ein Sprachmodell noch eine Datenbank. Auch die Auswahl des Kontexts und die Verwendung des Modells bleiben Aufgaben der KI-Anwendung. Dieser Artikel erklärt die Rollen, einen kontrollierten Aufruf und die Grenzen anhand des Spezifikationsstands 2026-07-28. MCP-Spezifikation, Architekturübersicht.

Welches Integrationsproblem MCP adressiert

Eine KI-Anwendung soll beispielsweise einen Vorgang anhand freigegebener Unternehmensdaten erklären. Die Informationen liegen jedoch in einem Fachsystem, während die Anwendung einen eigenen Aufruf- und Kontextmechanismus besitzt. Ohne gemeinsame Schnittstelle müssen Entwickler diese Verbindung für die jeweilige Kombination herstellen und pflegen.

MCP soll die Anwendungsseite dieser Anbindung vereinheitlichen. Ein Server beschreibt seine verfügbaren Daten und Funktionen in einer gemeinsamen Form; passende Anwendungen können damit arbeiten. Der ursprüngliche Zweck war bereits bei der Einführung durch Anthropic die Überwindung solcher getrennten Einzelintegrationen.

Der Nutzen hängt von der Perspektive ab: Entwickler können eine standardisierte Anbindung implementieren, KI-Anwendungen erhalten zusätzliche Daten- und Werkzeugangebote, und Nutzer können damit freigegebene Informationen verwenden oder erlaubte Aktionen auslösen. Daraus folgt keine feste Zeitersparnis. Datenzugang, fachliche Feldbedeutung, Berechtigungen, Fehlerbehandlung und Betrieb müssen weiterhin zur Aufgabe passen. Eine standardisierte Verbindung repariert weder widersprüchliche Daten noch fehlende Rechte.

Host, Client und Server haben unterschiedliche Aufgaben

Der Begriff „MCP-Server“ bezeichnet ein Programm, das Kontext oder Funktionen bereitstellt. Es kann lokal auf dem Rechner oder entfernt laufen. Der Name sagt noch nichts darüber aus, ob ein Cloudanbieter den Betrieb übernimmt.

Das Sprachmodell ist also nicht selbst der MCP-Client. Die Anwendung verarbeitet seine Vorschläge und lässt den passenden Client die Kommunikation übernehmen. Diese Trennung folgt der offiziellen MCP-Architektur.

Tools, Resources und Prompts

Server können drei grundlegende Arten von Angeboten bereitstellen. Die folgenden Beispiele sind frei gewählte Modelle, keine vorhandenen eBiz-Konnektoren:

Ein Tool muss keine Daten verändern. Auch eine reine Abfrage kann als Tool angeboten werden. Umgekehrt macht ein harmloser Funktionsname eine schreibende Operation nicht ungefährlich. Entscheidend sind die tatsächliche Implementierung und die erteilten Rechte. Die drei Angebotsarten sind in der Spezifikation getrennt beschrieben.

Die Grafik ordnet die Angebote dem Server zu und zeigt den Client innerhalb des Hosts. Sie stellt die Zugriffsprüfung als eigene Entscheidung dar; den vollständigen Weg bis ins Fachsystem erläutert das anschließende Beispiel.

Ein Leseaufruf und eine Änderung als Modell

Gedankliches Beispiel: Eine Mitarbeiterin möchte wissen, warum ein Servicevorgang noch offen ist. Eine KI-Anwendung darf dafür eine begrenzte Datenansicht lesen. Anschließend soll sie gegebenenfalls einen Rückrufauftrag anlegen. Die folgenden Schritte beschreiben einen möglichen Entwurf, keine getestete Produktintegration.

1. Aufgabe und Zugriff begrenzen. Die Anwendung kennt die Nutzeridentität und den erlaubten Datenbereich. Im Beispiel sind nur Vorgänge des zuständigen Teams zugänglich; andere Teams und unnötige personenbezogene Felder bleiben ausgeschlossen.
2. Verfügbare Fähigkeiten bestimmen. Der Client kann Serverinformationen abfragen und über tools/list die angebotenen Werkzeuge samt Eingabeschema erhalten. Die Anwendung erkennt beispielsweise ein Lesewerkzeug mit einer Vorgangs-ID als Pflichtangabe.
3. Lesen freigeben und aufrufen. Die Oberfläche macht Datenbereich und beabsichtigten Zugriff verständlich. Nach der erforderlichen Zustimmung lässt der Host den passenden Client tools/call mit dem Werkzeugnamen und zulässigen Argumenten senden. Serverseitig wird die Berechtigung geprüft; erst dann erfolgt die Abfrage des Fachsystems.
4. Ergebnis zurückführen. Der Server gibt das Ergebnis an den Client zurück. Der Host übernimmt den erlaubten Inhalt in den Anwendungskontext. Die Antwort soll den festgestellten Status und seine Quelle wiedergeben. Ein fehlender oder widersprüchlicher Datensatz muss als solcher erkennbar bleiben.
5. Die Anschlussaktion getrennt entscheiden. Aus einer Leseberechtigung folgt im Modell kein Recht, einen Rückrufauftrag anzulegen. Die Anwendung zeigt Empfänger, Vorgang und Inhalt der geplanten Änderung. Erst eine eigene menschliche Freigabe und das dafür eingerichtete Schreibrecht erlauben den zweiten Werkzeugaufruf.
6. Die Ausführung bestätigen. Die Anwendung zeigt das tatsächlich zurückgemeldete Ergebnis. Ein vorgeschlagener oder gesendeter Auftrag ist noch kein Beleg, dass das Zielsystem ihn erfolgreich gespeichert hat.

MCP liefert für den Austausch JSON-RPC-2.0-Nachrichten. Davon zu unterscheiden ist der Transport: stdio verwendet Ein- und Ausgabeströme zwischen lokalen Prozessen; Streamable HTTP ermöglicht Kommunikation über HTTP. Ein identischer fachlicher Werkzeugaufruf kann damit in unterschiedlichen Betriebsumgebungen eingebunden sein. Architektur: Daten- und Transportschicht.

Im hier verwendeten Stand trägt jede Anfrage die relevanten Protokoll- und Fähigkeitsangaben selbst. Ein Client kann zuerst server/discover verwenden, um unterstützte Versionen und Fähigkeiten zu erfahren. Der Server muss diese Methode unterstützen; der Client muss sie nicht vor jedem anderen Aufruf verwenden. Das ist kein vorgeschalteter Pflicht-Handshake. Architektur: Discovery.

Auch optionale Änderungsbenachrichtigungen machen den Kontext nicht automatisch vollständig aktuell. Laut Architektur werden sie nach bestem Bemühen übertragen; insbesondere bei Verbindungswechseln können Hinweise fehlen. Anwendungen müssen ihre Aktualisierungsstrategie entsprechend gestalten. Architektur: Benachrichtigungen.

Welche Aufgaben eine Anbindung erschließen kann

Persönliche Arbeitsinformationen, Unternehmensdaten und ausführende Werkzeuge stellen unterschiedliche Anforderungen. Ein Assistent könnte freigegebene Termin- oder Dokumentinformationen lesen. Eine Fachanwendung könnte Kennzahlen aus einer begrenzten Datenansicht abfragen. Eine Entwicklungsumgebung könnte Projektkontext erhalten, ein Designwerkzeug einen Entwurf bereitstellen oder ein angeschlossenes Ausführungssystem einen ausdrücklich erlaubten Auftrag übernehmen.

Diese Aufgabenklassen nennt auch die offizielle Einführung. Zum offenen Ökosystem gehören Host-Anwendungen, Server und Sprach-SDKs verschiedener Anbieter und Projektteams. Ob ein konkretes Produkt einen bestimmten Fall unterstützt, ist damit noch nicht beantwortet. Prüfen Sie gemeinsam: Protokollversion, tatsächlich angebotene Funktionen, unterstützte Erweiterungen und die Rechte des jeweiligen Nutzers. Die Unterstützung von MCP im Allgemeinen bedeutet nicht, dass jede Kombination aus Host, SDK und Server sofort zusammenarbeitet.

Für einen Entwicklungsprozess ist außerdem entscheidend, welche Aufgabe die Anbindung unterstützt und wer Änderungen prüft. Diese weitergehende Frage behandelt der Beitrag zu KI in der Softwareentwicklung.

APIs, RAG und weitere Standards einordnen

MCP ersetzt nicht jede andere Schnittstelle. Ein Server kann intern eine Fachsystem-API aufrufen; ein Host kann einen vom Modell vorgeschlagenen Funktionsaufruf, auch Function Calling genannt, über MCP vermitteln. Die gemeinsame Integrationsschnittstelle und die konkrete Funktion sind verschiedene Ebenen.

RAG verbindet die Suche nach relevanten Quellen mit der Erzeugung einer Antwort. MCP kann einer solchen Anwendung einen Daten- oder Suchzugang bereitstellen. Welche Dokumente gefunden, ausgewählt und als Antwortgrundlage verwendet werden, entscheidet weiterhin das Retrieval-/Generierungsverfahren. LangChain: Retrieval und RAG.

Weitere Begriffe helfen bei der Abgrenzung: A2A beschreibt die Kommunikation mit anderen Agenten beziehungsweise agentischen Systemen. Skills bündeln Anweisungen und Ressourcen für Aufgaben. Ein Skill ist deshalb nicht schon ein MCP-Werkzeug und eine Agentenkommunikation nicht automatisch ein Datenzugriff. Das Language Server Protocol (LSP) war ein Vorbild für die Standardisierung über viele Werkzeuge hinweg; daraus folgt keine technische Gleichsetzung der Protokolle. A2A-Grundbegriffe, MCP-Spezifikation.

Was Erweiterungen hinzufügen

MCP Apps ergänzen den Austausch um interaktive HTML-Oberflächen. Ein Werkzeug kann auf eine UI-Ressource verweisen, die ein unterstützender Host etwa als Formular oder Visualisierung einbettet. Dafür muss der Host die Erweiterung tatsächlich unterstützen. Die Oberfläche läuft in einer vom Host kontrollierten Sandbox; erlaubte Zugriffe und Werkzeugaktionen bleiben gesondert zu begrenzen. Eine Sandbox ist keine pauschale Aussage über jede spätere Datenverwendung. MCP Apps: Funktionsweise und Sicherheitsmodell.

Tasks behandeln längere asynchrone Vorgänge als optionale Erweiterung. Die Spezifikation führt außerdem Skills over MCP als Erweiterungsebene für strukturierte Anweisungen auf. Solche Erweiterungen gehören nicht automatisch zu jeder Implementierung des Kernprotokolls. Für beide Seiten muss passende ausdrückliche Unterstützung feststehen. MCP-Spezifikation: Erweiterungen.

Rechte und Vertrauen bleiben eigene Aufgaben

Eine gültige Protokollnachricht beantwortet noch nicht die Frage, ob ein Zugriff erlaubt oder eine Handlung sinnvoll ist. Die Spezifikation verlangt unter anderem verständliche Zustimmung, Kontrolle über Daten und Vorsicht bei Werkzeugaufrufen. Sie erklärt ausdrücklich, dass das Protokoll diese Sicherheitsprinzipien nicht selbst erzwingen kann. MCP: Sicherheits- und Vertrauensgrundsätze.

Prüfen Sie daher nicht nur die Verbindung, sondern die Vertrauensgrenzen: Wer betreibt den Server? Welche Daten gelangen an ihn? Welche Funktionen kann er ausführen? Welche zusätzlichen Adapter und Testwerkzeuge laufen mit welchen Rechten? Eine Schwachstelle in einem solchen Programm ist von einem Problem im Protokoll oder in der Modellverarbeitung zu unterscheiden.

Besondere Aufmerksamkeit verdienen Beschreibungen und Rückgaben. Bei Tool Poisoning werden manipulierte Anweisungen beispielsweise in Werkzeugbeschreibungen versteckt. Prompt Injection bezeichnet den Versuch, die Verarbeitung durch fremde Anweisungen im eingelesenen Inhalt zu beeinflussen. Den Zusammenhang erläutert die ursprüngliche Sicherheitsanalyse von Invariant. Für den Entwurf bedeutet das: Eine gelesene Beschreibung oder ein fachlicher Datensatz darf nicht ungeprüft die Zugriffsregeln verändern. Die Spezifikation warnt entsprechend davor, Angaben zum Werkzeugverhalten ohne passende Vertrauensbasis zu übernehmen. MCP: Tool Safety.

HTTP-Autorisierung und lokale Prozesse unterscheiden

Der beschriebene MCP-Autorisierungsablauf gilt für HTTP-basierte Transporte. Autorisierung ist als Protokollfähigkeit optional; unterstützt eine Implementierung den vorgesehenen Ablauf, gelten dessen Vorgaben. Für stdio sieht die Spezifikation stattdessen Anmeldeinformationen aus der Prozessumgebung vor. Ein pauschales „Jeder MCP-Server benötigt OAuth“ wäre deshalb falsch. Das bedeutet keinesfalls, dass lokale Prozesse ohne begrenzte Rechte betrieben werden sollten. MCP-Autorisierung: Geltungsbereich.

Beim unterstützten HTTP-Ablauf muss der Server prüfen, dass ein Token gerade für ihn bestimmt ist. Benötigt er zusätzlich Zugriff auf eine nachgelagerte API, ist deren Zugriffstoken getrennt zu beschaffen. Das vom MCP-Client erhaltene Token einfach weiterzureichen, ist ausdrücklich untersagt. Diese Trennung soll verhindern, dass eine Berechtigung für eine Schnittstelle stillschweigend an einer anderen verwendet wird. MCP: Tokenbindung und Token-Passthrough.

Den Protokollstand bei der Integration festhalten

Die Revision 2026-07-28 verändert den Kern gegenüber älteren Architekturtexten deutlich. Halten Sie deshalb für eine Integration nicht nur „MCP unterstützt“, sondern die tatsächlich verwendeten Versionen und Erweiterungen fest.

Maßgeblich sind die offizielle Releasebeschreibung und die zur Implementierung passende Spezifikation. Prüfen Sie bei einem Wechsel auch SDK-Migrationshinweise und Clientunterstützung. Ein Tutorial für eine ältere Version ist keine Zusage, dass seine Initialisierung und Sessionverwaltung unverändert zur neuen Fassung passen.

Mit einem begrenzten Server- oder Clientvorhaben beginnen

Wer Daten oder Werkzeuge bereitstellt, sollte zuerst eine kleine fachliche Fähigkeit definieren: erlaubte Eingaben, freigegebene Felder, erwartete Ergebnisse und klar erkennbare Fehler. Danach folgen passendes SDK, Transport, Identität und Berechtigungen. Ein gesamtes Fachsystem pauschal freizugeben, ist keine sinnvolle Abkürzung. Den technischen Einstieg bietet die offizielle Anleitung zum Serveraufbau.

Wer eine KI-Anwendung erweitert, muss auf der Hostseite entscheiden, welche Server angebunden werden, welche Angebote ins Modell gelangen und wie Zustimmung sowie Ergebnisse angezeigt werden. Auch unzulässige Argumente, verweigerter Zugriff und nicht erreichbare Systeme gehören in die Erprobung. Dafür gibt es einen getrennten Einstieg zur Cliententwicklung.

Die offiziellen Ressourcen erfüllen unterschiedliche Aufgaben: Die Spezifikation beschreibt die Anforderungen, die Dokumentation erklärt Konzepte und Umsetzung. Sprach-SDKs unterstützen die Implementierung, Referenzserver veranschaulichen Anbindungen, und der Inspector dient der Entwicklung und Prüfung von MCP-Servern. Ein erfolgreicher Inspector-Aufruf ersetzt keine fachliche Abnahme oder Sicherheitsprüfung. Ausgangspunkt ist das offizielle Projektverzeichnis.

Für das erste Vorhaben lässt sich eine einfache Abnahme vereinbaren: Ein berechtigter Nutzer erhält den erwarteten erlaubten Ausschnitt; ein unberechtigter Nutzer erhält ihn nicht. Ein fehlerhafter Aufruf erzeugt einen verständlichen Fehler. Eine vorgeschlagene Änderung wird erst nach der vorgesehenen Freigabe ausgeführt und anschließend anhand der Zielrückmeldung beurteilt. So wird aus einer funktionierenden Verbindung eine prüfbare Anwendung.

Offenes Projekt und organisatorischer Anschluss

Anthropic stellte MCP am 25. November 2024 vor. Das heutige offizielle Projektprofil beschreibt es als offenes Projekt bei der Linux Foundation. Die damalige Ankündigung ist eine historische Quelle; ihre Modell-, Tarif- und Produktangaben beschreiben nicht automatisch den heutigen Funktionsstand. Einführung von 2024, aktuelles Projektprofil.

Fragen lassen sich über die offiziellen GitHub Discussions einbringen. Für Beiträge verweist das Projekt auf seine Beitragsregeln. Ein Dokumentationsfehler, ein Fehler in einem SDK und ein Vorschlag für die Spezifikation gehören jeweils zum passenden Projektbereich. Offene Mitarbeit bedeutet nicht, dass jede fremde Erweiterung oder jeder Server offiziell geprüft ist.

Wenn Datenbasis, Verantwortlichkeiten oder ein begrenzter erster Anwendungsfall noch unklar sind, sollte die nächste Entscheidung dort ansetzen. Das Data-to-AI Assessment von eBiz erfasst dafür unter anderem Quellsysteme, Datenqualität, Governance und priorisierte Anwendungsfälle. Daraus lässt sich bestimmen, welche Daten eine MCP-Anbindung sinnvoll erschließen soll und welche Kontrollen sie braucht.