Model Context Protocol: Grundlagen, Funktionsweise und Einordnung

1. Das Integrationsproblem, das MCP adressiert

Sprachmodelle erzeugen Ausgaben aus ihrem Trainingswissen und dem aktuell bereitgestellten Kontext. Unternehmensdaten, Echtzeitbestände und ausführbare Geschäftsprozesse liegen jedoch außerhalb des Modells. Ohne definierte Schnittstelle kennt ein Modell weder den aktuellen Reisepreis noch darf es eine Buchung ändern. Frühe KI-Integrationen lösten dieses Problem mit proprietären Funktionsaufrufen pro Produkt. Jede Kombination aus KI-Host und Fachsystem benötigte eigene Schemas, Authentifizierung und Fehlerbehandlung.

MCP reduziert diese Kopplung, indem Server ihre Capabilities über ein standardisiertes Protokoll veröffentlichen. Ein CRM-Server kann dadurch grundsätzlich von mehreren MCP-fähigen Hosts genutzt werden. Das N-mal-M-Problem verschwindet nicht vollständig: Die fachliche Anbindung an CRM, ERP oder Buchungssystem bleibt. Standardisiert wird die Außenseite dieser Adapter und damit ein wesentlicher Teil der Wiederverwendung.

2. Protokoll statt Plattform oder Produkt

MCP ist weder ein Sprachmodell noch eine Agentenplattform, Datenbank oder universelle API. Ein Protokoll definiert Rollen, Nachrichten und zulässige Zustandsübergänge. Die normative Spezifikation beschreibt unter anderem JSON-RPC-Nachrichten, Initialisierung, Capabilities, Tools, Ressourcen, Prompts und Transportmechanismen.

Diese Abgrenzung schützt vor falschen Erwartungen. MCP entscheidet nicht, welches Tool ein Modell wählen soll, ob eine Modellantwort wahr ist oder wie ein Unternehmen seine Prozesse organisiert. Planung, Gedächtnis und Nutzeroberfläche gehören zum Host; fachliche Wahrheit und Transaktionslogik bleiben in den angebundenen Systemen.

3. Host, Client und Server

Der Host ist die Anwendung, in der Nutzer und Modell interagieren. Er verwaltet Sicherheitsentscheidungen, Modellkontext und in der Regel einen MCP-Client pro Serververbindung. Der Client implementiert die Protokollbeziehung: Er initialisiert, handelt Capabilities aus, listet Angebote und sendet Aufrufe.

Der Server beschreibt und realisiert eine fachlich begrenzte Menge von Capabilities. Er validiert Eingaben, autorisiert die konkrete Identität und vermittelt zum Backend. Die Verbindung je Server ist zugleich eine Sicherheitsgrenze: Informationen eines Servers dürfen nicht unkontrolliert in eine andere Vertrauensdomäne übertragen werden.

4. Tools, Ressourcen und Prompts

Tools sind aufrufbare Operationen mit strukturierten Eingaben. Sie können lesen, berechnen oder Nebenwirkungen erzeugen. Ressourcen sind URI-adressierbare Kontextobjekte wie Richtlinien, Dokumente oder dynamische Fachansichten. Prompts sind vom Nutzer auswählbare Vorlagen für wiederkehrende Interaktionen.

Die Unterscheidung folgt dem Kontrollmodell. Ein Modell kann ein Tool auswählen; eine Anwendung oder ein Nutzer entscheidet über Ressourcen; ein Prompt wird explizit ausgewählt. Eine Tarifregel als versteckter Prompt wäre unsicher. Eine verbindliche Buchung als scheinbar harmlose Ressource würde ihre Nebenwirkung verschleiern.

5. Lifecycle und Capability Negotiation

Die Initialisierung ist der erste reguläre Austausch. Client und Server nennen Protokollversion, Implementierungsinformationen und unterstützte Capabilities. Erst nach erfolgreicher Aushandlung beginnt der Betrieb. Nicht angekündigte Funktionen dürfen nicht vorausgesetzt werden.

Dieses Modell erlaubt unterschiedliche Implementierungsstände. Ein Client kann Roots, Sampling oder Elicitation unterstützen; ein Server Tools, Ressourcen, Prompts, Logging, Completions oder Tasks. Die Capability-Liste ist ein Laufzeitvertrag, kein statischer Marketingtext.

6. stdio und Streamable HTTP

stdio verbindet einen lokal gestarteten Serverprozess über Standard-Ein- und -Ausgabe. Es eignet sich für Desktop- und Entwicklungswerkzeuge, verlangt aber minimale Prozessrechte. stdout ist ausschließlich dem Protokoll vorbehalten; Logs gehören auf stderr.

Streamable HTTP stellt einen entfernten MCP-Endpunkt bereit und kann SSE zum Streaming verwenden. Es eignet sich für gemeinsam genutzte Dienste, erweitert aber die Angriffsfläche. HTTPS, Origin-Prüfung, OAuth-basierte Autorisierung, Sessionregeln und Schutz vor DNS-Rebinding werden Teil der Architektur.

7. Unternehmenswert und Governance

Der strategische Wert liegt in einem kuratierten Capability-Katalog, der unabhängig von einer einzelnen Modelloberfläche betrieben werden kann. Ein Reiseunternehmen kann Verfügbarkeit, Richtlinien und Kundenservicefunktionen mehreren Assistenten anbieten, ohne den Kern jedes Mal neu zu integrieren.

Wiederverwendung setzt Governance voraus: eindeutige Namen, Eigentümer, Datenklassen, Scopes, Versionen, SLOs und Deprecation. Ohne diese Regeln entsteht statt eines Standards lediglich ein neuer Wildwuchs aus schlecht beschriebenen Tools.

8. Grenzen, Risiken und ein sinnvoller Einstieg

MCP behebt keine schlechte Datenqualität, unklaren Prozesse oder fehlenden Objektberechtigungen. Modelle können Tools falsch auswählen, Ressourcen können Prompt Injection enthalten und Server können überprivilegiert sein. Jede Schicht benötigt eigene Kontrollen.

Ein guter Einstieg ist ein häufiger, lesender Anwendungsfall mit stabiler Quelle, klarer Nutzergruppe und messbarer Baseline. Erst wenn Trefferqualität, Rechte, Latenz und Nutzerführung funktionieren, folgen vorbereitende oder schreibende Aktionen. So wird MCP als Architekturentscheidung geprüft und nicht als Selbstzweck eingeführt.

Kompakte Referenz und minimales Tool-Schema

{
  "name": "search_offers",
  "description": "Sucht Reiseangebote; das Ergebnis ist keine Buchungsbestätigung.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "destination": { "type": "string", "minLength": 2 },
      "date_from": { "type": "string", "format": "date" },
      "date_to": { "type": "string", "format": "date" },
      "travellers": { "type": "integer", "minimum": 1 },
      "max_price": { "type": "number", "exclusiveMinimum": 0 },
      "currency": { "type": "string", "pattern": "^[A-Z]{3}$" }
    },
    "required": ["destination", "date_from", "date_to", "travellers"]
  }
}

Das Beispiel ist bewusst lesend und begrenzt. Produktion ergänzt Ergebnis-Schema, Autorisierungsregel, Limits, Fehlerklassen und Frischeangaben.

Tools, Ressourcen und Prompts im Vergleich

Die Primitive verteilen Kontrolle unterschiedlich zwischen Nutzer, Anwendung, Modell und Server. Produktbeschreibung kann Ressource sein; Live-Verfügbarkeit benötigt eine Operation mit Quelle und Zeitpunkt.

JSON-RPC vom Entdecken zum Aufruf

{
  "jsonrpc": "2.0", "id": 17, "method": "tools/list", "params": {}
}

{
  "jsonrpc": "2.0",
  "id": 18,
  "method": "tools/call",
  "params": {
    "name": "search_offers",
    "arguments": {
      "destination": "JP",
      "date_from": "2026-09-10",
      "date_to": "2026-09-20",
      "travellers": 2,
      "max_price": 4000,
      "currency": "EUR"
    }
  }
}

Nach Initialisierung und Capability-Aushandlung fragt der Client Tools ab. Der Server validiert Identität, Objektzugriff und Fachregeln bei jedem Aufruf erneut.

Der vollständige Lebenszyklus einer MCP-Verbindung

Eine Verbindung beginnt nicht mit einem Tool-Aufruf. Client und Server initialisieren die Sitzung, handeln Protokollversion und optionale Capabilities aus und wechseln erst nach der `initialized`-Notification in den regulären Betrieb. Der Client darf keine Funktion voraussetzen, die der Server nicht angekündigt hat; umgekehrt darf der Server Clientfunktionen wie Sampling oder Elicitation nur verwenden, wenn sie ausgehandelt wurden. Diese Aushandlung ist ein Laufzeitvertrag und muss in der Kompatibilitätsmatrix getestet werden.

Discovery folgt nach der Initialisierung. Listen können sich ändern, wenn der Server dies als Capability unterstützt. Eine geänderte Toolbeschreibung ist dabei nicht nur Dokumentation: Sie kann die Auswahlentscheidung eines Modells verändern. Namen, Beschreibungen und Schemas benötigen daher Versionierung, Regressionstests und einen kontrollierten Rollout wie andere öffentliche Verträge. Beim Shutdown werden laufende Operationen begrenzt beendet, Sessions freigegeben und unvollständige Fachvorgänge so dokumentiert, dass ein späterer Zustandsabgleich möglich bleibt.

Host, Client und Server tragen unterschiedliche Verantwortung

Der Host ist die Nutzer- und Policy-Grenze. Er entscheidet, welche Server verbunden werden, welche Tools ein Modell im aktuellen Aufgabenkontext sehen darf, welche Ergebnisse in den Modellkontext gelangen und wann eine menschliche Bestätigung erforderlich ist. Ein MCP-Client ist dagegen die protokollführende Beziehung zu genau einem Server. Er verwaltet Nachrichten, Capabilities und gegebenenfalls Session-Informationen, ist aber nicht automatisch die gesamte Anwendung.

Der Server verantwortet die wahrheitsgemäße Beschreibung seiner Fähigkeiten, Schema- und Rechteprüfung, kontrollierte Ausführung und begrenzte Ergebnisse. Das angeschlossene CRS, GDS, PMS, Order- oder Payment-System bleibt häufig System of Record. Es entscheidet über Bestand, Preis, Objektstatus und Geschäftsregeln. Diese Aufteilung ist für Fehleranalyse entscheidend: Eine falsche Tool-Auswahl, ein Protokollfehler, ein abgelehnter Fachzustand und ein Lieferantenausfall benötigen unterschiedliche Diagnose und Wiederherstellung.

Fehler sind Teil des Vertrags

Ein produktives Tool unterscheidet mindestens ungültige Eingabe, fehlende Berechtigung, nicht gefundenes Objekt, fachlichen Konflikt, temporären Downstream-Ausfall und unbekannten internen Fehler. Ein abgelaufenes Hotel-Offer ist kein generischer Serverfehler. Es ist ein erwartbarer Fachkonflikt, auf den der Client mit Revalidierung oder einer neuen Suche reagieren kann. Eine fremde Buchung darf dagegen keine Detailinformation preisgeben; je nach Policy wird der Zugriff abgelehnt oder das Objekt absichtlich wie nicht vorhanden behandelt.

Wiederholbarkeit wird pro Operation definiert. Lesende Suche kann unter Grenzen erneut versucht werden. Eine Order-Erzeugung benötigt eine Idempotency-ID und einen Statusabgleich, weil ein Timeout nach erfolgreicher Backendaktion eintreten kann. Das Protokoll allein liefert keine verteilte ACID-Transaktion. Teilbestätigungen, Kompensation und manuelle Eskalation bleiben fachliche Architekturaufgaben, die im Tool-Ergebnis explizit abgebildet werden müssen.

Wann MCP sinnvoll ist und wann nicht

MCP ist besonders plausibel, wenn mehrere KI-Anwendungen dieselben kuratierten Fähigkeiten zur Laufzeit entdecken sollen, Nutzerintentionen variieren und eine gemeinsame Governance-Schicht für Beschreibungen, Rechte und Ergebnisse benötigt wird. Ein Travel-Tech-Anbieter kann beispielsweise Angebotssuche, Repricing und Order-Lesen als stabile Capabilities mehreren Hosts bereitstellen, während die internen Lieferanten-APIs verborgen und unabhängig versioniert bleiben.

Eine direkte API ist häufig besser, wenn ein bekannter Consumer einen deterministischen Ablauf mit hoher Frequenz ausführt, kein Modell eine Fähigkeit auswählen muss und maximale Effizienz entscheidend ist. Eine Workflow-Engine ist besser, wenn der Prozess vollständig regelbasiert und reproduzierbar ablaufen soll. Die belastbare Entscheidung vergleicht dieselbe Aufgabe hinsichtlich Korrektheit, Latenz, Kosten, Änderbarkeit, Sicherheitsgrenze und Betriebsaufwand – nicht Protokollnamen oder Demo-Eindruck.

Abnahmekriterien für ein belastbares MCP-System

Eine technische Demonstration belegt nur, dass ein Client einen Server erreichen und mindestens einen Aufruf ausführen kann. Eine belastbare Abnahme prüft zusätzlich Version Negotiation, Capability-Änderungen, Schema-Grenzen, falsche Tool-Auswahl, abgelehnte Identitäten, fremde Objekte, manipulierte Ressourcen, zu große Ergebnisse, Timeouts und doppelte Zustellung. Travel-Fälle ergänzen abgelaufene Offers, Repricing, Teilbestätigung, Lieferantenausfall und den Abbruch nach einer bereits ausgeführten Zahlung oder Buchung.

Die Messung trennt Modell, Hostpolicy, Client, MCP-Server und Fachsystem. Geeignete Kennzahlen sind Aufgabenabschluss, fachliche Korrektheit, unzulässige Aufrufe, notwendige Nutzerkorrekturen, korrekt erkannte veraltete Zustände, Latenz und Kosten pro erfolgreichem Vorgang. Ein gemeinsamer Trace verbindet Auswahl, Autorisierung und Backendwirkung, ohne unnötige Prompts, Tokens oder Passagierdaten zu speichern.

Produktionsfreigabe benötigt zudem einen benannten fachlichen und technischen Owner, Serviceziele, Alarmierung, Runbooks, Rollback, Deprecation und einen Kill Switch pro riskanter Capability. Erst wenn das System unter erwartbaren Fehlern sicher stoppt, einen autoritativen Zustand rekonstruieren kann und keine Zustimmung über geänderte Bedingungen hinweg wiederverwendet, ist der Schritt von der Protokollintegration zur verantwortbaren Betriebsfähigkeit vollzogen.

Wo MCP endet

MCP definiert weder Reisepreise noch Tarifregeln oder Datenschutzgrundlagen. NDC, OpenTravel, GTFS und proprietäre APIs bleiben fachliche Quellverträge. Der Server darf aus syntaktischer Kompatibilität keine semantische Gleichheit ableiten: Offer, Order, PNR, Ticket, Reservierung und Reiseplan besitzen je nach Standard und Anbieter unterschiedliche Zustände und Rechte.

Für deterministische Hochlastintegration kann eine direkte API geeigneter sein. MCP schafft Mehrwert, wenn mehrere KI-Hosts dieselben kontrollierten Fähigkeiten kontextabhängig nutzen. Produktionsreife ist erst belegt, wenn Capability-Vertrag, negative Autorisierungstests, Frische- und Fehlersemantik, Telemetrie, Rollback und sicherer Abschaltweg gemeinsam funktionieren.

FAQ zu Model Context Protocol: Grundlagen, Funktionsweise und Einordnung

Primärquellen und wissenschaftliche Einordnung

Die Darstellung folgt der versionierten MCP-Spezifikation. Normative Anforderungen werden von Architektur- und Betriebsempfehlungen getrennt; experimentelle Funktionen sind entsprechend gekennzeichnet.

• MCP-Spezifikation 2025-11-25 ↗
• Offizielle Architekturübersicht ↗
• MCP Schema Reference ↗
• JSON-RPC 2.0 ↗
• JSON Schema 2020-12 ↗