Faktenfassung: Travel Shopping, Verfügbarkeit und dynamische Preise

Sachliche Zusammenfassung

Travel Shopping ist ein Such- und Entscheidungsproblem unter veränderlichem Bestand. Ein MCP-System muss fachliche Suchparameter, Quellenunterschiede, Limits und Unsicherheit transparent machen, statt lediglich möglichst viele Ergebnisse an ein Modell zu senden.

Suchabsicht in prüfbare Parameter übersetzen

Natürliche Sprache enthält weiche Wünsche und harte Einschränkungen. Reisezeitraum, Abflugregion, Reisende, Budget, Zimmerbelegung und notwendige Leistungen müssen als strukturierte Eingabe bestätigt werden. Wünsche wie ruhig, familienfreundlich oder nachhaltig benötigen definierte Merkmale oder nachvollziehbare Bewertungsquellen.

Der Client kann fehlende Angaben über Elicitation erfragen. Der Server sollte keine geschäftskritischen Standardwerte erraten. Besonders Alter, Nationalität, Markt und Währung können Preis und Buchbarkeit beeinflussen.

Fan-out und Lieferantensteuerung

Eine Metasuche kann zahlreiche Quellen ansprechen. Unbegrenzter Fan-out erhöht Kosten, Latenz und Rate-Limit-Risiken. Der Server benötigt Quellenauswahl, Parallelitätsgrenzen, Deadlines, Cachingregeln und eine klare Kennzeichnung nicht erreichbarer Anbieter.

Teilresultate sind zulässig, wenn sie sichtbar als solche erscheinen. Das Modell darf aus dem Fehlen eines Ergebnisses nicht ableiten, dass kein Angebot existiert. Negative Ergebnisse brauchen denselben Provenienznachweis wie positive.

Normalisierung ohne Informationsverlust

Angebote unterscheiden sich bei Steuern, Gebühren, Gepäck, Storno, Verpflegung, Zimmerart und Zahlungszeitpunkt. Ein kanonisches Schema erleichtert den Vergleich, darf aber anbieterspezifische Bedingungen nicht wegaggregieren. Normalisierte Felder benötigen Links oder Referenzen auf die Originalbedingungen.

Währungskonvertierung, Zeitzonen und lokale Datumsgrenzen sind fachliche Operationen. Der Server muss den verwendeten Kurs und Zeitpunkt nennen und darf umgerechnete Orientierungspreise nicht als belastbaren Zahlbetrag ausgeben.

Ranking und Erklärbarkeit

Ranking sollte harte Filter von Präferenzen trennen. Das Modell kann eine Auswahl erklären, aber die zugrunde liegenden Kriterien müssen prüfbar sein. Provision, Verfügbarkeit, persönliche Präferenz und redaktionelle Bewertung dürfen nicht in einem unbekannten Score verschwinden.

Ein gutes Ergebnis liefert nicht nur Treffer, sondern Ausschlussgründe, Unsicherheit und Alternativen. Damit bleibt die Beratung nachvollziehbar und kann bei veränderten Prioritäten neu berechnet werden.

Preisrevalidierung und Race Conditions

Zwischen Anzeige und Auswahl kann ein Offer ablaufen. Vor Buchung muss der Server Preis, Bestand und Bedingungen erneut prüfen. Ändert sich etwas, endet der Ablauf nicht mit einem generischen Fehler: Der Client muss Differenz, neue Gesamtsumme und geänderte Bedingungen darstellen und erneut bestätigen lassen.

Idempotenz schützt nicht vor Preisänderung; sie verhindert doppelte Ausführung desselben bestätigten Auftrags. Revalidierung und Idempotenz sind deshalb getrennte Kontrollen.

• Zeitpunkt und Gültigkeit jedes Offers
• Gesamtpreis mit Steuern und Gebühren
• Enthaltene und ausgeschlossene Leistungen
• Tarif- und Stornobedingungen
• Vollständigkeit der abgefragten Quellen

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

Randfälle eines produktiven Travel-Shoppings

Caching ist nur zulässig, wenn Ergebnis und Client die Frische eindeutig erkennen. Statische Hotelmerkmale können lange gelten; Bestand und Preis können beim Empfang bereits veraltet sein. Ein Cache-Hit darf nie stillschweigend als Live-Preis bezeichnet werden.

Teilresultate unterscheiden null Treffer, abgelehnten Zugriff, Timeout, Rate Limit und nicht unterstützte Anfrage. Bei Flugangeboten bleiben Tarif- und Gepäckbedingungen erhalten; bei Hotels Belegung, lokale Abgaben und Zahlungszeitpunkt. Normalisierung darf keine kommerziell wesentlichen Unterschiede entfernen.

Race Conditions werden als Zustandsfolge behandelt: auswählen, revalidieren, Abweichung präsentieren, erneut zustimmen, idempotent ausführen und autoritativ abgleichen. Idempotenz verhindert Doppelbuchungen; sie garantiert weder Preis noch Bestand.

Quellenauswahl, Fan-out und belastbare Teilresultate

Ein Shopping-Server fragt nicht unbegrenzt jede erreichbare Quelle ab. Er wählt Anbieter nach Markt, Produkt, Vertrag, Nutzerrechten und erwarteter Relevanz, begrenzt Parallelität und setzt eine gemeinsame Deadline. Die Antwort dokumentiert, welche Quellen vollständig, teilweise, abgelehnt oder nicht erreichbar waren. Nur so kann der Host erklären, ob er einen Marktüberblick oder einen begrenzten Ausschnitt zeigt.

Rate Limits und Kosten sind Teil des Capability-Vertrags. Ein Nutzerwunsch darf nicht zu exponentiellem Fan-out über flexible Daten, Datenbereiche und Anbieter führen. Breite Suchräume werden iterativ eingegrenzt. Caches erhalten produktabhängige Fristen, und negative Cache-Einträge dürfen Lieferantenausfälle nicht in vermeintliche Nichtverfügbarkeit verwandeln.

Ranking ohne verdeckte Geschäftslogik

Harte Filter wie Reisedatum, Belegung oder notwendige Barrierefreiheitsmerkmale werden vor Präferenzranking geprüft. Weiche Kriterien wie Boutique-Charakter oder ruhige Lage benötigen nachvollziehbare Merkmale und Quellen. Provision, Sponsorplatzierung oder eigene Marge dürfen nicht unbemerkt in einen angeblich objektiven Qualitätswert einfließen.

Ein zitierfähiges Ranking nennt Kriterien, Gewichte oder zumindest nachvollziehbare Gründe und zeigt ausgeschlossene Alternativen. Das Modell kann diese strukturierten Gründe sprachlich erklären, darf aber keine fehlenden Fakten ergänzen. Ändert die Nutzerin ihre Prioritäten, wird aus den gespeicherten Kandidaten neu bewertet oder gezielt neu gesucht; der frühere Rang ist keine dauerhafte Produkteigenschaft.

Begrenztes Suchergebnis

{
  "offers": [{
    "offer_id": "htl_jp_7f31",
    "supplier": "hotel-crs-eu",
    "retrieved_at": "2026-07-23T10:15:00Z",
    "valid_until": "2026-07-23T10:25:00Z",
    "total": { "amount": 1840.00, "currency": "EUR" },
    "local_fees_due": { "amount": 42.00, "currency": "EUR" }
  }],
  "source_status": [
    { "source": "hotel-crs-eu", "status": "complete" },
    { "source": "channel-manager-2", "status": "timeout" }
  ],
  "is_complete": false
}

Das Ergebnis trennt Gesamtpreis, Gültigkeit und Quellenstatus und behauptet bei Ausfällen keine Vollständigkeit.

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