Inhalt
Autor: Dominik E.
Stand: 5. August 2026. Das Model Context Protocol (MCP) ist kein KI-Modell, kein Reisevertriebssystem und keine fachliche Datennorm. Es ist ein offenes Protokoll, über das KI-Anwendungen Kontext und klar definierte Funktionen von externen Systemen beziehen können. Für Travel Tech liegt seine strategische Relevanz deshalb weniger im besseren Chat als in einer neuen Integrationsschicht zwischen Sprachmodell, Unternehmenslogik und operativem Systembestand.
Vom KI-Frontend zur kontrollierten Integrationsarchitektur
Dokumentierter Ist-Zustand. MCP folgt einer Client-Server-Architektur: Ein Host – etwa eine KI-Anwendung – verwaltet Verbindungen, während einzelne Clients isolierte Sitzungen zu MCP-Servern aufbauen. Server können Tools für ausführbare Funktionen, Resources für Kontextdaten und Prompts als wiederverwendbare Vorlagen anbieten. Der Datenaustausch basiert auf JSON-RPC; die Spezifikation beschreibt unter anderem Initialisierung, Capability-Negotiation und das Aufrufen von Tools. MCP-Architekturüberblick ([modelcontextprotocol.io](https://modelcontextprotocol.io/docs/learn/architecture?utm_source=openai))
Diese Trennung ist für Reiseunternehmen wesentlich. Ein Sprachmodell kann Angebote erklären, Optionen vergleichen oder einen Servicefall zusammenfassen. Es sollte jedoch weder die alleinige Autorität über Preise und Verfügbarkeiten sein noch direkt in ein Passenger Service System, ein Property-Management-System oder ein Zahlungsmodul schreiben. MCP erlaubt, die Modellschicht von den fachlichen und transaktionalen Quellen zu entkoppeln. Das Protokoll definiert dabei den Zugang; die Reise-API, das Regelwerk und das führende Fachsystem bleiben für die Wahrheit einer Transaktion zuständig.
Analyse. Die tragfähige Travel-Tech-These lautet daher: MCP sollte als kontrollierte Orchestrierungs- und Governance-Schicht über bestehenden Reise-APIs eingesetzt werden, nicht als Ersatz für diese APIs. Die Wettbewerbsfrage lautet dann nicht, welches Modell eine Reise am eloquentesten formuliert, sondern welches Unternehmen Angebot, Bestellung, Service, Einwilligung und Auditierbarkeit zuverlässig über Modellgrenzen hinweg steuern kann.
Revisionsstand, Ankündigung und Herstellerangabe sauber trennen
Dokumentierter Ist-Zustand. Der für diesen Beitrag maßgebliche veröffentlichte MCP-Revisionsstand ist 2025-11-25. Er definiert als Standardtransporte stdio und Streamable HTTP. Bei Streamable HTTP kann ein Server eine Sitzungskennung vergeben; Clients müssen diese anschließend in weiteren Requests mitsenden. Server müssen bei diesem Transport den Origin-Header gegen DNS-Rebinding-Angriffe prüfen; lokal sollen sie nach Möglichkeit nur an localhost gebunden werden. MCP-Transportspezifikation ([modelcontextprotocol.io](https://modelcontextprotocol.io/specification/2025-11-25/basic/transports?utm_source=openai))
Ankündigung. Am 28. Juli 2026 wurde ein Release Candidate für eine MCP-Spezifikation gleichen Datums vorgestellt. Dort wird eine zustandslose Protokollebene als zentrale Änderung beschrieben: Tool-Aufrufe sollen ohne vorherige Sitzung von beliebigen Serverinstanzen verarbeitet werden können. Ein Release Candidate ist jedoch keine finale, produktiv verbindliche Spezifikation. Reiseunternehmen sollten ihn als Architekturindikator und Testgegenstand behandeln, nicht als bereits fixierten Implementierungsvertrag. Ankündigung des Release Candidate vom 28. Juli 2026 ([blog.modelcontextprotocol.io](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/))
Herstellerangabe. OpenAI beschreibt für ChatGPT einen Modus, in dem Anwendungen mit entfernten MCP-Servern verbunden werden können, und weist ausdrücklich auf Risiken durch nicht vertrauenswürdige Server und Prompt Injection hin. Das belegt eine konkrete Produktintegration, nicht jedoch Sicherheit oder Interoperabilität jeder beliebigen MCP-Implementierung. OpenAI-Hinweis zu Developer Mode und MCP-Apps ([help-lb.openai.com](https://help-lb.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt?utm_source=openai))
Die Travel-MCP-Architektur: Systeme bleiben führend
Eine belastbare Architektur beginnt mit einer fachlichen Grenzziehung. Fluggesellschaften arbeiten im Vertrieb zunehmend mit Offer- und Order-Prozessen; IATA beschreibt NDC als Datenaustauschformat für die Erstellung und Verteilung von Angeboten sowie für Order-Management-Prozesse. Parallel bietet OpenTravel mit seinem Objektmodell wiederverwendbare, in JSON oder XML austauschbare Konzepte für Reisebranchen. Beide Ansätze liefern semantische Grundlagen – MCP ersetzt sie nicht. IATA: Distribution with Offers & Orders ([iata.org](https://www.iata.org/en/programs/airline-distribution/retailing/ndc)) OpenTravel 2.0 Object Model ([opentravel.org](https://opentravel.org/about-2-0-object-model/))
Vier Schichten statt eines allmächtigen Reiseassistenten
- Host und Agentenoberfläche: Sie hält Nutzeridentität, Dialog, Einwilligungen, Modellwahl und Freigabedialoge. Der Host entscheidet, ob ein Tool überhaupt aufgerufen werden darf.
- MCP-Client und Policy Gateway: Diese Schicht verbindet den Host mit Servern, erzwingt Mandantentrennung, Berechtigungen, Ratenlimits, Freigaben und Audit-Ereignisse.
- Domänenspezifische MCP-Server: Kleine Adapter kapseln beispielsweise Air Shopping, Hotelverfügbarkeit, Reiseorder, Störungskommunikation oder Wissensdatenbanken. Jeder Server erhält einen klaren Verantwortungsbereich.
- APIs und System of Record: PSS, CRS, PMS, Order-Management, CRM, MDM, Zahlungsdienst und Operations-Plattform bleiben führende Systeme. Nur sie bestätigen Preise, Verfügbarkeiten, Reservierungen, Zahlungen oder Umbuchungen.
Ein MCP-Tool search_air_offers darf strukturierte, zeitlich begrenzte Angebote lesen. price_offer muss eine aktuelle Neubepreisung aus dem führenden System auslösen. create_order darf erst nach expliziter Nutzerfreigabe, Preisbestätigung, erfolgreicher Fachregelprüfung und Übergabe eines Idempotenzschlüssels ausgeführt werden. Ein Tool-Ergebnis braucht deshalb nicht nur Text, sondern maschinenprüfbare Felder wie Angebots-ID, Gültigkeitszeit, Währung, Preisstand, Korrelation-ID und Fehlercode.
Analyse. Das System of Record darf nicht als frei abrufbare „Resource“ missverstanden werden. Resources eignen sich für abgegrenzten Kontext; sie können beispielsweise Zielregeln, interne Serviceleitfäden oder eine pseudonymisierte Reiseübersicht liefern. Die MCP-Spezifikation erlaubt hierzu Metadaten wie Zielgruppe, Priorität und Änderungszeitpunkt, damit Clients Kontext selektiv behandeln können. Für verbindliche Transaktionen sind dagegen API-Aufrufe mit fachlicher Validierung und konsistentem Audit erforderlich. MCP-Resourcespezifikation ([modelcontextprotocol.io](https://modelcontextprotocol.io/specification/2025-11-25/server/resources))
Berechtigungen müssen auf Geschäftsrisiken passen
Dokumentierter Ist-Zustand. Für HTTP-basierte geschützte MCP-Server sieht die Spezifikation OAuth-basierte Autorisierung vor. MCP-Server müssen Protected Resource Metadata nach RFC 9728 bereitstellen; Clients verwenden diese Metadaten, um Autorisierungsserver zu finden. Außerdem muss ein Client den Zielserver als resource-Parameter angeben, und der Server muss prüfen, ob ein Token tatsächlich für ihn ausgestellt wurde. Die Spezifikation verbietet ausdrücklich, eingehende Tokens ungeprüft an nachgelagerte APIs durchzureichen. MCP-Autorisierungsspezifikation ([modelcontextprotocol.io](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization)) RFC 8707: OAuth Resource Indicators ([rfc-editor.org](https://www.rfc-editor.org/rfc/rfc8707.pdf?utm_source=openai))
Für Travel Tech reichen grobe Rollen wie „Agent“ oder „Administrator“ nicht aus. Berechtigungen sollten mindestens fünf Ebenen verbinden:
- Aktion: lesen, halten, bestellen, umbuchen, stornieren oder erstatten;
- Fachobjekt: Angebot, Order, Reisender, Voucher oder Zahlungsstatus;
- Kontext: Mandant, Vertriebskanal, Markt, Reisezeitraum und Servicefall;
- Wirkungsgrenze: Betrag, Anzahl Reisender, betroffene Segmente und Frist;
- Freigabe: automatische Ausführung, Schritt-für-Schritt-Bestätigung oder Vier-Augen-Prinzip.
Eine Umbuchung ist damit kein einzelnes Toolrecht, sondern ein kontrollierter Geschäftsprozess: Berechtigung prüfen, aktuelle Order laden, Alternativen bepreisen, Differenz transparent darstellen, Zustimmung erfassen, Änderung ausführen und Ergebnis gegen das führende System zurücklesen. Lang laufende Vorgänge wie Rückerstattungen oder Störungsbearbeitungen sollten als asynchrone Fachprozesse modelliert werden. MCP kennt hierfür experimentelle Tasks; deren Einsatz entbindet aber nicht von eigener Prozesspersistenz und fachlicher Zustandsführung. Experimentelle MCP-Tasks ([modelcontextprotocol.io](https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/tasks?utm_source=openai))
Prompt Injection ist kein Berechtigungsmodell
Reiseinhalte sind ein besonders plausibler Angriffsvektor: Freitext aus Hotelbeschreibungen, E-Mails, PDFs, Störungsmeldungen oder Partner-APIs kann Anweisungen enthalten, die ein Modell fehlinterpretiert. Deshalb darf weder ein Dokument noch eine Toolbeschreibung selbst Rechte verleihen. Auch MCP-Tool-Annotationen wie „read only“ oder „destructive“ sind lediglich Hinweise; Clients sollen Entscheidungen gegenüber nicht vertrauenswürdigen Servern nicht darauf stützen. MCP-Schema und Tool-Annotationen ([modelcontextprotocol.io](https://modelcontextprotocol.io/specification/2025-11-25/schema?utm_source=openai))
Analyse. Jede schreibende Reiseaktion benötigt daher eine Policy-Entscheidung außerhalb des Modells: validierte Eingabeparameter, serverseitige Geschäftsregeln, aktuelle Datenabfrage, risikogestufte Zustimmung und unveränderbares Audit-Protokoll. Zu speichern sind mindestens Identität, Zweck, Zeitpunkt, Toolversion, Parameter-Hash, Ergebnisreferenz und Freigabeentscheidung – nicht zwingend der vollständige sensible Dialog. Das folgt auch dem Prinzip der Datenminimierung und dem Datenschutz durch Technikgestaltung nach DSGVO. DSGVO, insbesondere Artikel 5 und 25 ([eur-lex.europa.eu](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32016R0679&utm_source=openai))
Zusätzlich sind kurzlebige Tokens, eng abgegrenzte Scopes, getrennte Tokens je Zielressource, Secret-Scanning, Ausgabefilter für personenbezogene Daten sowie Testumgebungen mit synthetischen Reisedaten erforderlich. Die MCP-Sicherheitshinweise nennen neben Token-Passthrough insbesondere SSRF, Session Hijacking und überbreite Berechtigungen als relevante Risiken. MCP Security Best Practices ([modelcontextprotocol.io](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices?utm_source=openai))
Ein belastbarer Einführungsplan
- Domänen inventarisieren: Systeme of Record, Datenklassen, APIs, Eigentümer und zulässige Aktionen dokumentieren.
- Mit lesenden Fällen beginnen: Reiseauskunft, Statusabfrage, Richtlinienerklärung und interne Wissenssuche sind geeigneter als Buchung oder Erstattung.
- Tool-Verträge härten: JSON-Schemas, strukturierte Ausgaben, Versionsregeln, Idempotenz und Contract Tests verbindlich machen.
- Transaktionen kapseln: Für jede schreibende Aktion Freigabestufe, Limits, Rückabwicklung, Monitoring und fachliches Audit definieren.
- Erst dann skalieren: Messgrößen sind nicht nur Antwortqualität, sondern Fehlbuchungen, Abbruchquote, Freigabequote, Policy-Verstöße, Bearbeitungszeit und Revisionsfähigkeit.
Der wirtschaftliche Nutzen entsteht, wenn ein Assistent Informationen kanalübergreifend erklären und Prozesse vorbereiten kann, ohne die Kontrolle über kommerzielle und regulatorisch sensible Entscheidungen zu übernehmen. MCP ist dafür ein brauchbarer technischer Baustein. Die strategische Differenzierung entsteht aber durch die Qualität der Domänen-APIs, der Berechtigungsarchitektur und der Prozessführung.
FAQ
Ersetzt MCP NDC, OpenTravel oder bestehende Reise-APIs?
Nein. NDC, OpenTravel und proprietäre APIs beschreiben fachliche Objekte und Transaktionen. MCP standardisiert den Kontext- und Toolzugang einer KI-Anwendung. Eine sinnvolle Architektur kombiniert beide Ebenen, statt sie gegeneinander auszuspielen.
Wer entscheidet bei MCP, welches KI-Modell verwendet wird?
Der Server kann bei Sampling-Funktionen Präferenzen zu Kosten, Geschwindigkeit oder Leistungsfähigkeit angeben. Die endgültige Auswahl kontrolliert jedoch der Client; Modellhinweise sind nicht verbindlich. Das unterstützt eine Multi-Model-Strategie, verlangt aber reproduzierbare Tests je freigegebenem Modell. MCP-Sampling und Modellpräferenzen ([modelcontextprotocol.io](https://modelcontextprotocol.io/specification/2025-11-25/client/sampling?utm_source=openai))
Darf ein KI-Agent eine Reise autonom buchen oder umbuchen?
Technisch kann ein Tool eine solche Aktion auslösen. Fachlich sollte dies nur in eng definierten, überprüfbaren Fällen geschehen. Für preis- oder leistungswirksame Änderungen sind aktuelle Preisprüfung, explizite Zustimmung, Limits, Idempotenz und ein Audit-Trail die Mindestvoraussetzungen.
Genügen OAuth-Scopes für sichere Reiseprozesse?
Nein. Scopes begrenzen den Zugang zu Ressourcen, ersetzen aber keine fachliche Prüfung. Ein gültiger Scope darf beispielsweise nicht automatisch bedeuten, dass eine Tarifregel erfüllt, eine Erstattung zulässig oder eine Zustimmung nachweisbar ist.
Ist ein zentraler MCP-Server für alle Reisebereiche sinnvoll?
Ein zentrales Gateway für Policy, Audit und Observability ist sinnvoll. Ein einziger monolithischer Server für alle Fachdomänen meist nicht. Kleine, klar verantwortete Domänenserver reduzieren Berechtigungsumfang, vereinfachen Tests und begrenzen Schadenswirkungen.