MCP-FAQ für Travel: Protokoll, Architektur, Sicherheit und Reise-IT

Ein offener Standard, über den KI-Anwendungen externe Fähigkeiten und Kontextquellen einheitlich entdecken und verwenden.

Nein. MCP-Server kapseln häufig bestehende APIs und ergänzen eine KI-orientierte Capability-Schicht.

Nein. Ein Server stellt Fähigkeiten bereit; Planung und Zielverfolgung liegen normalerweise im Host oder Agentenframework.

Server bieten vor allem Tools, Ressourcen und Prompts; weitere Capabilities umfassen Logging, Completions und Tasks.

stdio und Streamable HTTP. Der frühere HTTP-plus-SSE-Transport ist ein Bestandsmodell.

Client und Server erklären während der Initialisierung, welche optionalen Protokollfunktionen sie unterstützen.

Nein. Konkrete Hosts und Modelle unterscheiden sich jedoch in ihrer Produktunterstützung.

Entfernte HTTP-Server nutzen das OAuth-basierte MCP-Modell; der Server validiert Tokens und erzwingt zusätzlich Fachrechte.

Nein. Scopes sind grob; konkrete Kunden, Buchungen oder Dokumente benötigen Objektberechtigungen.

Das ungeprüfte Akzeptieren oder Weiterreichen eines Tokens, das nicht korrekt für den MCP-Server ausgestellt wurde. Dieses Muster ist verboten.

Durch technische Trennung von Daten und Instruktionen, minimale Tools, Freigaben und serverseitige Policies – nicht allein durch Prompts.

Für lokale Einzelbenutzer-Integrationen, bei denen der Host einen Serverprozess startet.

Für entfernte, gemeinsam genutzte und zentral betriebene Server mit TLS und Autorisierung.

Eine Serveranfrage an den Client, eine Modellgenerierung unter Kontrolle des Hosts auszuführen.

Ein standardisierter Weg, mit dem ein Server zusätzliche Nutzerinteraktion über den Client anfordert.

Vom Client bereitgestellte Hinweise auf relevante Dateisystemgrenzen; sie ersetzen keine Sandbox.

Ein experimenteller Mechanismus für langlaufende Operationen mit Status und späterem Ergebnisabruf.

Mit einem häufigen, lesenden Use Case, stabiler Quelle, echten Nutzern und messbarer Baseline.

Grundsätzlich APIs, CRM, ERP, DMS, Datenbanken, Buchungs- und Reisesysteme – jeweils nur über begrenzte Fähigkeiten.

Mit SLOs, Logs, Metriken, Tracing, Versionsregeln, Incident Response und benannten Capability-Ownern.

Der Host ist die übergeordnete KI-Anwendung mit Benutzeroberfläche, Modellzugang und Kontrolllogik. Er erzeugt gewöhnlich für jede Serververbindung eine eigene MCP-Clientinstanz. Der Client spricht das Protokoll; der Host entscheidet, wie Fähigkeiten dem Modell und dem Menschen zugänglich werden.

Ja. Das ist ein reguläres Architekturmuster. Jeder Client hält dabei seine eigene Serverbeziehung. Der Host muss Namenskonflikte, Berechtigungen, Ergebnisprovenienz und die Auswahl zwischen ähnlichen Tools kontrollieren.

Nicht zwingend. Der Protokolllifecycle schafft eine logische Verbindung; Streamable HTTP kann zusätzlich eine MCP-Session-ID verwenden. Fachlicher Zustand wie ein Warenkorb oder eine Buchung gehört dennoch in ein ausdrücklich verantwortetes System und nicht unbemerkt in die Transportsitzung.

Client und Server handeln während initialize eine unterstützte Version aus. Neue Implementierungen sollten eine veröffentlichte, versionierte Spezifikation gezielt unterstützen und Kompatibilität testen, statt auf undokumentiertes Latest-Verhalten zu vertrauen.

Kommt keine gemeinsam unterstützte Version zustande, darf die Initialisierung nicht als erfolgreiche Sitzung fortgeführt werden. Betreiber benötigen eine dokumentierte Kompatibilitätsmatrix und kontrollierte Upgrade- beziehungsweise Rollbackpfade.

Ja. MCP-Nachrichten beruhen auf JSON-RPC 2.0 und ergänzen darauf eigene Methoden, Datenstrukturen, Lifecycle-Regeln und Capabilities. JSON-RPC allein ist daher noch keine MCP-Implementierung.

Nein. Sie sind innerhalb des jeweiligen Servers eindeutig. Ein Host, der mehrere Server kombiniert, muss Herkunft und Namensraum erhalten und darf zwei gleichnamige Tools nicht ohne explizite Konfliktregel vermischen.

Mindestens einen eindeutigen Namen, eine verständliche Beschreibung und ein gültiges inputSchema. Titel, outputSchema, Icons, Annotationen und Ausführungsinformationen können je Spezifikationsversion ergänzend vorhanden sein.

Wenn kein anderes $schema angegeben ist, gilt für Tool-Schemas in der Spezifikation 2025-11-25 JSON Schema 2020-12 als Standardwert. Implementierungen müssen trotzdem prüfen, welchen Umfang ihre Bibliotheken tatsächlich unterstützen.

inputSchema beschreibt die Argumente eines Tools. Das optionale outputSchema beschreibt dessen strukturiertes Ergebnis. Wenn ein Server ein outputSchema veröffentlicht, muss structuredContent diesem Schema entsprechen; der Client sollte dies validieren.

Ein maschinenlesbares JSON-Objekt im Toolergebnis. Es verhindert nicht automatisch Halluzinationen oder falsche Quelldaten, erleichtert aber Typprüfung, Weiterverarbeitung und eine klare Trennung von Darstellungstext und Ergebnisstruktur.

Fehler im Protokoll oder in der Request-Struktur werden als JSON-RPC-Fehler behandelt. Fachliche Ausführungsfehler können als Toolresultat mit isError: true zurückgegeben werden, damit der aufrufende Client sie kontrolliert an das Modell weitergeben kann.

Technisch kann ein Schema dies erlauben. Für sicherheitsrelevante Tools ist additionalProperties: false häufig sinnvoll, weil unerwartete Parameter früh abgewiesen werden. Die Entscheidung muss zur Erweiterungsstrategie des Vertrags passen.

Nicht automatisch. Die Spezifikation verlangt, dass Clients Annotationen eines nicht vertrauenswürdigen Servers nicht als Sicherheitsgarantie behandeln. Aussagen wie readOnlyHint ersetzen weder Codeprüfung noch serverseitige Autorisierung.

Eine Resource stellt adressierbaren Kontext über eine URI bereit. Ein Tool modelliert eine aufrufbare Operation. Eine Resource sollte nicht als versteckter Schreibkanal und ein Tool nicht als beliebige Datenablage missbraucht werden.

Eine parametrisierte URI-Beschreibung für eine Menge ähnlich strukturierter Ressourcen. Der Client setzt definierte Argumente ein; der Server bleibt für Autorisierung, Validierung und die sichere Auflösung der URI verantwortlich.

Ja. Server können List-Changed-Fähigkeiten und Abonnements unterstützen. Ein Client darf daraus nicht schließen, dass alle Änderungen garantiert oder in Echtzeit eintreffen; Cache- und Konsistenzregeln müssen dokumentiert werden.

Eine serverseitig angebotene, vom Nutzer auswählbare Vorlage für Nachrichten und Kontext. Ein Prompt ist keine technische Sicherheitsrichtlinie und darf serverseitige Zugriffsprüfungen niemals ersetzen.

Wenn eine klar definierte, validierbare Operation ausgeführt oder strukturiert abgefragt wird, ist ein Tool passend. Ein Prompt eignet sich für wiederverwendbare Interaktionsvorlagen, deren Auswahl und Ausführung beim Nutzer beziehungsweise Host liegt.

Nur wenn der Client Sampling unterstützt und der Host die Anfrage kontrolliert. Der Server erhält dadurch keinen unbegrenzten Modellzugang; der Client kann Anfragen prüfen, verändern oder ablehnen.

Form Mode ist nicht für sensible Geheimnisse gedacht. Für externe sensible oder personenbezogene Abläufe sieht die neuere Spezifikation URL-basierte Interaktion vor. Unabhängig davon müssen Datensparsamkeit und Zweckbindung gelten.

Die Serveradresse kann konfiguriert oder über vertrauenswürdige Verzeichnisse bereitgestellt werden. Für geschützte HTTP-Ressourcen nutzt die Autorisierung Protected Resource Metadata zur Ermittlung zugehöriger Authorization Server.

Sie stellt standardisierte Metadaten bereit und bindet Publikationen über Namespace-Verifikation an GitHub-Konten oder Domains. Laut eigener Dokumentation ist sie keine Sicherheitsprüfung des Servercodes und keine Garantie für Produktionseignung.

Der Eintrag und seine Metadaten sind durch eine offizielle Primärquelle belegt. Installation, Capabilities, Datenqualität, Seiteneffekte und Sicherheit wurden jedoch noch nicht reproduzierbar redaktionell getestet.

Die Registry befindet sich im Preview-Status und umfasst nur öffentlich registrierte Server. Private Unternehmensserver, nicht registrierte Repositories und geschlossene Produkte ohne öffentliche Metadaten fehlen. Eine absolute Marktzahl wäre deshalb methodisch irreführend.

Nein. Offener Quellcode ermöglicht Prüfung, garantiert sie aber nicht. Entscheidend sind konkrete Version, Abhängigkeiten, Berechtigungen, Datenflüsse, Build-Provenienz, Wartung und Betriebsumgebung.

Bei HTTP-basierter Autorisierung agiert er als OAuth Protected Resource beziehungsweise Resource Server. Er akzeptiert nur passend ausgestellte Tokens und muss insbesondere deren Zielressource beziehungsweise Audience validieren.

Sie binden die Tokenanforderung an den konkreten MCP-Server. Dadurch wird erschwert, dass ein für eine andere Ressource ausgestelltes Token an einem MCP-Server missbraucht wird.

Das HTTP-Autorisierungsmodell soll für stdio nicht verwendet werden. Lokale stdio-Server beziehen Zugangsdaten typischerweise aus ihrer kontrollierten Umgebung; der Host muss Prozessstart, Umgebungsvariablen und Dateirechte absichern.

Ein Tool erhält nur die Daten, Operationen und Zeiträume, die sein Zweck verlangt. Eine reine Verfügbarkeitssuche braucht beispielsweise keine Zahlungsdaten und gewöhnlich kein Recht zum Erstellen oder Stornieren einer Buchung.

Insbesondere bei wirtschaftlich oder rechtlich relevanten, schwer reversiblen oder personenbezogenen Aktionen. Die Freigabe muss den konkreten Preis, Umfang, Reisenden, Tarifzustand und Zeitpunkt abdecken; eine pauschale Zustimmung zu einem Agenten reicht nicht.

Als fachliche Zustandsfolge: Suche, konkretes Offer, Revalidierung, informierte Bestätigung und idempotente Order-Erzeugung. Das System of Record bestätigt Preis, Verfügbarkeit und Buchungsstatus; das Sprachmodell ist nicht die Buchungsdatenbank.

Ein Offer beschreibt ein befristetes oder konditioniertes Leistungsangebot. Eine Order dokumentiert den angenommenen, verwalteten Geschäftszustand. Die genaue Semantik hängt vom fachlichen Standard und Anbieter ab und darf nicht aus dem MCP-Protokoll abgeleitet werden.

Nein. NDC und ONE Order beschreiben Airline-Retailing-, Offer-, Order- und Fulfilment-Semantik. MCP kann passende Fähigkeiten zugänglich machen, liefert diese fachlichen Modelle aber nicht selbst.

Nein. OpenTravel definiert segmentübergreifende Travel-Nachrichten und Datenobjekte. Ein MCP-Server kann solche Schnittstellen kapseln, muss Version, Lizenz, Codes und fachliche Regeln jedoch weiterhin respektieren.

Ja. Ein Server kann statische oder dynamische Mobilitätsdaten aus GTFS, NeTEx oder SIRI bereitstellen. Er muss Herkunft, Gültigkeitszeit, Zeitzone, Servicekalender und Aktualität erhalten, damit Ergebnisse fachlich interpretierbar bleiben.

Ein Code benötigt immer seinen Namensraum, etwa IATA, UIC oder einen feed-spezifischen GTFS stop_id. Ein nackter String wie BER ist ohne Semantik und Gültigkeitskontext nicht ausreichend.

Mindestens mit Betrag, ISO-4217-Währung, Preisbestandteilen, Steuer-/Gebührenstatus, Gültigkeit, Quelle und Hinweis auf Revalidierung. Gleitkommazahlen sind für Geldberechnungen häufig ungeeignet; Dezimal- oder Minor-Unit-Modelle sind kontrollierbarer.

Zeitpunkte sollten eine eindeutige Zeitzone oder einen UTC-Bezug besitzen. Lokale Abflugzeit, Betriebsdatum und UTC-Zeit sind verschiedene Informationen; Sommerzeitwechsel und Fahrplanlogik dürfen nicht stillschweigend vom Modell geraten werden.

Nur innerhalb einer ausdrücklich freigegebenen Policy und nach erneuter Prüfung der konkreten Folgen. Gebühren, Erstattungsweg, Teilstorno, verbundene Leistungen und Unumkehrbarkeit müssen vor der Ausführung transparent sein.

Durch fachliche Idempotenzschlüssel, Deduplizierung, eindeutige Request-Korrelation und kontrolliertes Retry-Verhalten. Ein Timeout darf nicht automatisch als nicht ausgeführte Buchung interpretiert werden; zuerst ist der Zustand im System of Record zu klären.

Identität, Tool und Version, Zweck, Autorisierungsentscheidung, freigegebene Parameter, Zeit, Ergebnisstatus und Korrelationskennung. Geheimnisse und unnötige personenbezogene Inhalte gehören nicht in Logs; Integrität, Zugriff und Aufbewahrung müssen geregelt sein.

Durch Zweckbindung, Datenminimierung, getrennte Identitäten, Verschlüsselung, kurze Aufbewahrung, Objektberechtigungen und nachvollziehbare Übermittlung. MCP ändert nicht die datenschutzrechtliche Verantwortung der beteiligten Systeme.

Latenz und Fehler je Tool, Backendabhängigkeit, Autorisierungsfehler, Timeouts, Abbrüche, Schemafehler, Ergebnisgröße und Seiteneffektstatus. Prompt- und Inhaltsdaten sollten nur nach Datenklassifikation protokolliert werden.

Mit Protokoll- und Contract-Tests, Schema- und Autorisierungstests, Negativfällen, Last- und Abbruchtests sowie fachlichen Zustandsprüfungen. Travel-Transaktionen benötigen zusätzlich Sandboxdaten und eine sichere Kontrolle möglicher realer Seiteneffekte.

Additive, kompatible Erweiterungen sind von brechenden Änderungen zu trennen. Benötigt werden Versionierungsregel, Deprecation-Frist, Consumer-Inventar, Contract Tests, schrittweiser Rollout und ein belastbarer Rückweg.

Der Mensch erhält die entscheidungsrelevanten Daten und bestätigt einen bestimmten Zustand. Eine bloße Meldung nach Ausführung oder ein unverständlicher Sammeldialog ist keine wirksame Kontrolle.

Ja, sofern Host, Server, Modelle und abhängige Systeme entsprechend bereitgestellt werden. Ob tatsächlich keine Daten externe Grenzen verlassen, hängt aber von Telemetrie, Modellendpoint, Authentifizierung, Updates und weiteren Diensten ab.

Wenn mehrere Server gemeinsame Discovery-, Routing-, Policy- oder Beobachtungsanforderungen haben. Das Gateway darf Domänenautorisierung nicht unbemerkt zentralisieren, keine Tokens ungeprüft weiterreichen und keinen Single Point of Failure ohne Gegenmaßnahmen erzeugen.

Nicht automatisch. Grenzen sollten Datenverantwortung, Berechtigungsmodell, Releasezyklus, Fehlerdomäne und fachliche Kohärenz widerspiegeln. Sowohl der Universalserver als auch extreme Zersplitterung können problematisch sein.

Er verlangt breite Schreibrechte, hat unklare Verantwortliche, schlechte Datenqualität, seltene Ausnahmefälle oder keinen messbaren Ausgangswert. Ein enger, lesender und häufig genutzter Prozess ist als Einstieg meist besser prüfbar.

Nein. Travel MCP ist ein unabhängiges Wissensportal. Der TRAVEL MCP Scanner dokumentiert öffentlich auffindbare Server, und die technischen Beispiele simulieren Protokollabläufe ohne reale Buchungswirkung.

Nein. Das Portal veröffentlicht Fachwissen, Referenzmuster, Quellen, Testsichten und redaktionelle Einordnungen. Es verkauft keine Beratung und übernimmt keine Produktfreigabe.

Normative MCP-Aussagen werden gegen eine benannte Spezifikationsversion geprüft. Travel-Standards werden auf ihre Primärquellen zurückgeführt. Redaktionelle Architekturfolgerungen werden als Ableitung gekennzeichnet und nicht als Protokollanforderung ausgegeben.

Über die Kontaktseite mit betroffener URL, konkreter Aussage, begründeter Korrektur und möglichst einer Primärquelle. Relevante Änderungen erhalten ein neues redaktionelles Prüfdatum.