Faktenfassung: Produkt, Offer und Order im Travel-MCP-Modell

Sachliche Zusammenfassung

Viele Fehlarchitekturen beginnen damit, Produkt, Angebot und Buchung als dasselbe Objekt zu behandeln. Für agentische Reiseprozesse müssen stabile Beschreibung, zeitgebundener Preis und rechtswirksamer Auftrag getrennt bleiben.

Produkt ist nicht Verfügbarkeit

Ein Produkt beschreibt grundsätzlich verkaufbare Leistungen, Merkmale, Regeln und Beziehungen. Daraus folgt weder, dass es für einen konkreten Termin verfügbar ist, noch dass ein angezeigter Preis noch gilt. Ressourcen eignen sich für relativ stabile Beschreibungen; aktuelle Verfügbarkeit gehört in einen qualifizierten Tool-Aufruf.

Der Server sollte Produktattribute mit Quelle und Version liefern. Freitext des Modells darf strukturierte Merkmale ergänzen, aber nicht ersetzen. Besonders bei Barrierefreiheit, Verpflegung, Gepäck oder Transferleistungen müssen kontrollierte Felder von generierter Erläuterung unterscheidbar bleiben.

Offer als zeitgebundene Zusage

Ein Offer verbindet konkrete Leistungen, Reisende, Zeitraum, Währung, Preisbestandteile, Bedingungen und Gültigkeit. IATA beschreibt NDC als Offer- und Order-orientierten Datenaustausch für Airline-Retailing. Dieses Denkmodell ist auch außerhalb des Flugs hilfreich, darf aber nicht ungeprüft auf alle Leistungsträger übertragen werden.

Ein MCP-Tool zur Angebotserzeugung sollte eine Offer-ID, Ablaufzeit, Preisquelle, enthaltene Leistungen, Ausschlüsse und Änderungsbedingungen zurückgeben. Ein Sprachmodell darf aus einer Suchantwort keine verbindliche Zusage konstruieren.

Order als autoritativer Geschäftszustand

Eine Order repräsentiert den angenommenen und im Fachsystem geführten Auftrag. Sie besitzt Status, Parteien, Leistungen, Zahlungen, Dokumente und Historie. Der Order-Server muss nach einem Schreibaufruf den tatsächlich gespeicherten Zustand zurücklesen, statt nur den erfolgreichen API-Transport zu melden.

Order-Änderungen sind neue fachliche Vorgänge. Umbuchung und Storno dürfen nicht als generisches Update modelliert werden, weil Bedingungen, Preisfolgen und Lieferantenbestätigungen zu prüfen sind.

IDs, Versionen und Provenienz

Interne, Lieferanten- und Vertriebskanal-IDs sind nicht austauschbar. Ein kanonisches Modell benötigt eine Zuordnung mit Herkunft und Gültigkeitsbereich. Bei jeder Revalidierung muss erkennbar sein, auf welches Offer und welche Version sich die Entscheidung bezieht.

Provenienz ist für KI-Ausgaben besonders wichtig: Quelle, Zeitpunkt und Transformation erlauben dem Client, verbindliche Daten von Zusammenfassungen zu unterscheiden. Ohne diese Metadaten kann eine flüssige Antwort fachlich nicht belastbar bewertet werden.

Capability-Beispiele

Gute Tools bilden Nutzerabsichten ab: `search_travel_products`, `price_itinerary`, `create_offer`, `revalidate_offer`, `create_order` und `get_order`. Ihre Schemas machen Reisende, Zeitraum, Markt, Währung und gewünschte Leistungen explizit.

Ein einziges `book_trip`-Tool ist für komplexe Reisen häufig zu grob. Es verbirgt Zwischenzustände und erschwert Zustimmung. Zu viele technische Tools zwingen dagegen das Modell, eine verteilte Transaktion selbst zu orchestrieren. Die richtige Aufteilung hält fachliche Invarianten auf dem Server.

• Produktbeschreibung lesen
• Verfügbarkeit suchen
• Offer erzeugen und revalidieren
• Order nach expliziter Zustimmung anlegen
• Autoritativen Status zurücklesen

Zustände und Verbindlichkeit im Vergleich

Jede Architektur muss benennen, welches System einen Zustand verantwortet und welche Aussage der Client treffen darf.

Durchgängiges Beispiel: Boutiquehotels in Japan

Eine Nutzerin sucht für zwei Personen zehn Tage in Japan, Gesamtbudget 4.000 Euro und bevorzugt kleine Hotels. Der Host trennt harte Kriterien – Zeitraum, Reisende, Budget und Währung – von weichen Präferenzen. Der Server fragt ausgewählte Hotelquellen unter einer Deadline ab und liefert je Ergebnis Quellsystem, Abrufzeit, Belegung, Steuern, lokale Gebühren, Rate Plan, Stornoregel und Gültigkeitsgrenze. Ein ausgefallener Anbieter erscheint als fehlende Quelle; sein Ausfall wird nicht als „kein Angebot“ interpretiert.

Nach der Auswahl erzeugt das Pricing-System ein konkretes Offer. Vor einer verbindlichen Aktion ruft der Server `revalidate_offer` auf. Ändern sich Preis oder Bedingungen, verfällt die frühere Zustimmung. Erst die Zustimmung zu genau diesem Offer erlaubt `create_order`. Der Aufruf trägt eine Idempotency-ID; nach einem Timeout liest der Server zuerst den Orderzustand. Das Ergebnis enthält Order-ID, Hotelbestätigung, Zahlungsstatus und offene Komponenten.

• Keine Buchung aus einem gecachten Suchtreffer
• Keine Preisgarantie ohne Gültigkeitsgrenze
• Keine Zustimmung nach Repricing wiederverwenden
• Keine blinde Wiederholung eines Schreibaufrufs
• Keine Teilbestätigung als vollständige Reise darstellen

Vollständiger MCP-Aufruf: Offer vor Order revalidieren

[
  {
    "jsonrpc": "2.0",
    "id": 42,
    "method": "tools/call",
    "params": {
      "name": "revalidate_offer",
      "arguments": {
        "offer_id": "off_7f31",
        "expected_version": 7,
        "traveller_market": "DE"
      }
    }
  },
  {
    "jsonrpc": "2.0",
    "id": 42,
    "result": {
      "structuredContent": {
        "offer_id": "off_7f31",
        "version": 8,
        "status": "revalidated",
        "total": { "amount": 1848.00, "currency": "EUR" },
        "valid_until": "2026-07-23T10:25:00Z",
        "material_change": {
          "price_delta": { "amount": 8.00, "currency": "EUR" },
          "requires_new_approval": true
        },
        "order_created": false
      }
    }
  }
]

Das Beispiel zeigt zwei getrennte JSON-RPC-Nachrichten: den Tool-Aufruf und die zugehörige Antwort. Die Zustimmung ist an Offer-Version, Preis, Währung und Bedingungen gebunden; der Server erzeugt noch keine Order. Erst ein nachgelagerter, erneut autorisierter Schreibvorgang darf den bestätigten Zustand referenzieren.

Mapping auf NDC, GDS, CRS und PMS

Im Airline-Retailing liefern NDC-basierte Prozesse Offer- und Order-orientierte Nachrichten, während klassische GDS-Umgebungen zusätzlich PNR-, Ticket- und EMD-Zustände führen können. Ein MCP-Server darf diese Begriffe nicht in ein generisches `booking`-Objekt glätten. Er bewahrt Quellsystem, Namespace, Identifier und Status und übersetzt nur dort in ein kanonisches Modell, wo die Semantik nachweislich gleich ist.

Bei Hotels verteilen sich Wahrheit und Zuständigkeit häufig auf CRS, Channel Manager und PMS. Ein CRS kann Preise und zentralen Bestand liefern, der Channel Manager Kanalverteilung steuern und das PMS den operativen Aufenthalt führen. Eine Order oder Reservierung im Vertrieb ist deshalb nicht automatisch identisch mit dem aktuellen Stay- oder Zahlungszustand. Der Capability-Vertrag nennt für jedes Feld System of Record und Zeitpunkt.

Änderung, Storno und Erstattung sind neue Vorgänge

Eine Order-Änderung ist kein technisches Patch. Zuerst wird der autoritative Zustand gelesen, dann ein Änderungsangebot mit Kosten- und Bedingungsdifferenz erzeugt. Nach Zustimmung erfolgt eine idempotente Ausführung und anschließend der erneute Abgleich von Order, Lieferantenbestätigung, Dokumenten und Zahlung.

Storno und Erstattung können auseinanderfallen. Eine Leistung kann storniert sein, während die Erstattung geprüft oder über einen anderen Zahlungsweg verarbeitet wird. Teilstorno, Non-Refundable-Anteile und Lieferantenablehnung sind explizite Zustände. Der Agent darf einen beantragten Refund nicht als ausgezahlt darstellen.

FAQ

Primärquellen und Spezifikationen

• MCP-Spezifikation 2025-11-25
• MCP-Architektur
• IATA – Distribution with Offers & Orders (NDC)
• EU-Datenschutz-Grundverordnung
• PCI Security Standards Council – PCI DSS