Travel-MCP-Architektur-Konfigurator: Kerndaten
- Ausgabe
- Referenzmuster, keine Produktkonfiguration
- Kernprinzip
- Domänengrenzen vor Serveranzahl
- Risikotreiber
- Seiteneffekt, Datenklasse, Geldwert, Reversibilität
- MCP-Rolle
- Vermittlung, nicht Fachsystem of record
Konfiguration und Ergebnis
Wählen Sie Domänen und Kontrollniveau. Die Ausgabe ordnet MCP-Komponenten um die bestehenden Systems of Record an; sie erfindet keine neue Buchungswahrheit.
Warum Domänengrenzen entscheidend sind
Ein einzelner Universalserver erzeugt breite Berechtigungen, gekoppelte Releases und schwer prüfbare Fehlerdomänen. Getrennte Server sind dagegen nicht automatisch sicher. Maßgeblich sind konsistente Verantwortungsbereiche: Produkt und Verfügbarkeit, Offer und Pricing, Order und Servicing, Identität, Payment sowie Dokumente.
Die Servergrenze sollte dort liegen, wo Datenverantwortung, Freigaberegeln oder Ausfallverhalten wechseln. Ein Gateway kann Discovery, Richtlinien und Telemetrie bündeln, darf aber nicht unbemerkt zum zweiten Autorisierungssystem werden.
Trust Boundaries und Identität
Die Identität des Menschen, des MCP-Clients, des Workloads und des nachgelagerten Fachsystems sind verschiedene Subjekte. Token Passthrough verwischt diese Grenzen und ist in den MCP-Sicherheitsleitlinien ausdrücklich problematisch. Remote-HTTP-Server benötigen ressourcengebundene Tokens und eine Validierung der Audience.
Transaktionale Muster
Für Buchungen empfiehlt sich eine Zustandsfolge aus Suche, Angebotserzeugung, Revalidierung, expliziter Bestätigung und idempotenter Ausführung. Das Sprachmodell darf die fachliche Zustandsmaschine nicht ersetzen. Preis, Verfügbarkeit, Tarifregeln und Zahlungsstatus werden vom zuständigen System of Record bestätigt.
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.