FACT COPY · EN
Fact copy: Standards map for MCP and travel
Maps MCP, IATA NDC, ONE Order, OpenTravel, GTFS, NeTEx, SIRI, OAuth and JSON Schema to their actual responsibilities.
Canonical source: https://travel-mcp.com/en/research/standards-map/
Factual summary
Standards are not interchangeable. This map shows which one defines interaction, travel semantics, transport data, authorization or validation.
Specifications and core data
- MCP
- KI–Capability-Interaktion
- NDC
- Airline Offers & Orders Messaging
- ONE Order
- Airline Order/Fulfilment Record
- GTFS
- ÖPNV-Fahrplan und Echtzeit
- NeTEx/SIRI
- europäische ÖPNV-Datenmodelle und Austausch
- OpenTravel
- segmentübergreifende Travel-Nachrichten
Responsibility map
MCP does not replace travel domain standards. It can expose bounded operations over systems that implement them.
Selection rule
Select the authoritative domain source and semantic standard first; then evaluate MCP as the controlled discovery and invocation layer.
Research question and boundary
Standards map for MCP and travel examines maps MCP, IATA NDC, ONE Order, OpenTravel, GTFS, NeTEx, SIRI, OAuth and JSON Schema to their actual responsibilities. The module distinguishes normative MCP requirements from editorial travel-architecture patterns. A pattern is not presented as protocol behaviour unless the versioned specification supports that claim.
The analysis also separates interoperability from suitability. A server may exchange valid MCP messages and still be unsafe, semantically ambiguous or unusable for a production travel process.
Travel-domain validity
Travel evidence must preserve the authoritative source, retrieval time, identifier namespace, currency, conditions and validity window. Offer, order, reservation, PNR, ticket, EMD and itinerary describe different states and must not be collapsed into a generic booking object.
For write operations, the test model includes repricing or state revalidation, object-level authorization, approval bound to the exact material terms, idempotency and recovery after a partial downstream failure. MCP supplies none of these domain guarantees automatically.
Method, falsification and evidence
The recorded indicators for this module include MCP: KI–Capability-Interaktion; NDC: Airline Offers & Orders Messaging; ONE Order: Airline Order/Fulfilment Record; GTFS: ÖPNV-Fahrplan und Echtzeit; NeTEx/SIRI: europäische ÖPNV-Datenmodelle und Austausch; OpenTravel: segmentübergreifende Travel-Nachrichten. Each claim should identify its observation date and primary source. Release candidates, experimental capabilities and editorial inferences are labelled separately from the current protocol baseline.
A useful result must survive counterexamples: unsupported client capabilities, malformed or adversarial content, stale supplier state, denied authorization, timeout and duplicate execution. The evidence package combines contract tests, negative tests, trace correlation and a documented owner for corrections.
Interpretation for decision-makers
The module is not a product ranking or an assurance certificate. Registry presence, repository activity or a successful demonstration cannot prove security, legal authority, commercial access or operational maturity.
A decision should state which uncertainty the module reduced, which assumptions remain open and what would falsify the conclusion. This prevents an interactive graphic or catalogue entry from being mistaken for production due diligence.