Systeme der Wahrheit statt zentraler Datenillusion

Produktstammdaten können aus einem Veranstaltersystem stammen, Flugverfügbarkeit aus einem GDS oder Airline-Angebot, Hotelbestand aus CRS oder Channel Manager, Kundendaten aus CRM und Dokumente aus DMS. Dieselbe Reise erscheint in mehreren Systemen mit unterschiedlichen IDs und Aktualitätsständen.

Ein MCP-Server darf diese Unterschiede nicht verdecken. Für jedes Ausgabefeld braucht es Herkunft, Gültigkeit und fachliche Bedeutung. Ein aggregiertes Ergebnis muss Teilfehler ausweisen, statt eine unvollständige Antwort als vollständige Wahrheit zu präsentieren.

Sinnvolle Domänengrenzen

Servergrenzen sollten nicht mechanisch einer vorhandenen Anwendung entsprechen. Häufig sind fachliche Domänen wie Shopping, Offer, Order, Customer, Document, Payment und Operations stabiler als technische Produktsilos. Ein Domänenserver darf mehrere APIs verwenden, wenn er daraus eine kohärente Fähigkeit mit eindeutiger Verantwortung bildet.

Zu breite Server erhöhen Tool-Verwechslung, Berechtigungsumfang und Ausfallwirkung. Zu feine Server verlagern Fachlogik in den Agenten. Die geeignete Granularität liegt dort, wo Validierung, Rechte und Transaktionsverhalten serverseitig vollständig verantwortet werden können.

Identitäten und Mandanten durchgängig erhalten

Zwischen Reisebüro, Veranstalter, Hotel, Plattform und Lieferant existieren verschiedene Organisations- und Nutzeridentitäten. Ein technisches Sammelkonto zerstört die Nachvollziehbarkeit und kann Objektberechtigungen umgehen. Der Server muss Mandant, handelnde Person, delegierte Rolle und fachlichen Vorgang unterscheiden.

Tokens dürfen nicht ungeprüft an Downstream-Systeme weitergereicht werden. Audience, Scope und Objektzugriff sind an jeder Grenze zu prüfen. Wo ein Backend keine Nutzerdelegation unterstützt, braucht es kompensierende Kontrollen, eng begrenzte Servicekonten und ein vollständiges fachliches Audit.

Synchronität, Latenz und Ausfälle

Shopping-Aufrufe können viele Lieferanten fan-out ansprechen und deutlich länger dauern als ein Profillookup. Ein MCP-Tool benötigt deshalb Timeout, Cancellation, Ergebnislimit und eine definierte Teilfehlersemantik. Wiederholungen sind bei lesenden Aufrufen meist harmloser als bei Reservierung oder Zahlung.

Langlaufende Prozesse gehören in eine Job- oder Task-Infrastruktur mit Statusmodell. Der Agent sollte keinen Erfolg behaupten, solange das autoritative System nur eine Annahme bestätigt hat. Observability muss technische Spans mit Vorgang, Capability und Downstream-Korrelation verbinden.

Referenzfluss

Ein Host authentifiziert den Nutzer und öffnet für dessen Rolle zulässige MCP-Verbindungen. Der Shopping-Server fragt ausgewählte Quellen ab und liefert normalisierte, gekennzeichnete Offers. Ein Order-Server revalidiert das gewählte Angebot, erzeugt nach Bestätigung einen Auftrag und gibt die autoritative Order-ID zurück. Dokument- und Payment-Server bleiben getrennte Sicherheitsdomänen.

Diese Architektur reduziert Kopplung, macht aber keine verteilte Transaktion atomar. Teilfehler, Kompensation und manuelle Eskalation müssen als fachliche Zustände entworfen werden.

  • Host: Nutzerinteraktion und Zustimmung
  • Gateway: Policy, Routing und Rate Limits
  • Domänenserver: fachliche Verträge
  • Backends: autoritative Zustände
  • Telemetry: Ende-zu-Ende-Nachweis

FAQ zu Reise-IT-Systemlandschaft und MCP-Architektur

Soll jedes Backend einen eigenen MCP-Server erhalten?

Nein. Die Grenze sollte einer kohärenten Fachdomäne und Sicherheitsverantwortung folgen.

Ersetzt MCP ein API-Gateway?

Nein. Gatewayfunktionen wie Routing, Quotas und API-Schutz bleiben wertvoll; MCP ergänzt Capability-Semantik und KI-orientierte Interaktion.

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.