The answer first: three objects, three kinds of truth

A product describes what may be sold: characteristics, service relationships and relatively stable rules. An offer applies market, travellers, dates, availability, price and conditions at a particular point in time. An order is the commercial record accepted and maintained by an authoritative provider. These objects can reference one another, but they are not interchangeable.

MCP standardises how a host discovers and invokes a capability; it does not make an offer current or an order legally effective. The domain server must preserve the source contract behind each field, and the connected airline, GDS, CRS, PMS, tour-operator or order platform remains authoritative for the state it owns.

A product does not prove availability

A product resource may describe a room type, flight service, rail product, package component, baggage option or transfer. It can include controlled attributes, applicability rules, supplier references and a content version. None of those fields proves that the service is available for a particular date, party, point of sale or distribution agreement.

Relatively stable descriptions can be exposed as MCP resources when their URI, access policy and freshness are explicit. Current inventory requires a qualified tool call. Accessibility, meal, baggage and transfer attributes should remain structured and sourced; model-generated prose may explain them but must not replace the controlled facts.

An offer is a time-bound commercial proposition

An offer binds specific services to travellers, dates, market, currency, price components, conditions and a validity boundary. IATA NDC uses offer- and order-oriented messaging for airline retailing, but the same terms must not be projected onto every supplier as if their state models were identical.

A useful offer result carries its source namespace, identifier, version, retrieval time, expiry, total price, taxes and fees, inclusions, exclusions, fulfilment assumptions and material conditions. A conversational summary is presentation only. It cannot turn a shopping result into a supplier commitment or extend an expired offer.

An order is an authoritative business state

An order represents accepted services and the state recorded by the responsible system. It may reference parties, travellers, payments, fulfilment documents and a transition history. A successful HTTP or JSON-RPC response proves message processing, not necessarily that every supplier component was confirmed.

After a write, the server should reconcile the stored order and return authoritative identifiers and per-component status. Modification, exchange, cancellation and refund are new domain processes. They require fresh rules, quotations, approval and execution rather than a generic patch to an earlier object.

Lifecycle and permitted claims

The safe lifecycle is product discovery, qualified shopping, offer creation, offer revalidation, explicit approval, idempotent order creation and authoritative reconciliation. Each step has a different owner and evidence threshold. The client may say that an offer was found only when the source and retrieval state support that claim.

A revalidated offer may still require a new approval if price, currency, traveller, service or material conditions changed. Approval must be tied to the exact version shown to the user. An order may be described as confirmed only when the responsible system returns the corresponding state; a pending supplier response remains pending.

  • Product: descriptive and rule-bearing
  • Offer: priced, scoped and time-bound
  • Approval: bound to exact material terms
  • Order: authoritative commercial record
  • Fulfilment: ticket, voucher, EMD or supplier confirmation

Identifiers, namespaces and provenance

Internal IDs, distributor references, supplier locators, PNRs, order IDs, ticket numbers and hotel reservation codes belong to different namespaces. A canonical travel model must preserve the original identifier, issuer, object type and validity scope rather than placing every value in a field called booking_id.

Provenance records source, retrieval time, transformation and version. This lets the host distinguish authoritative fields from normalized or generated presentation. It also makes incident investigation possible when a user-visible answer differs from the supplier state.

Mapping NDC, GDS, CRS and PMS without flattening

NDC-oriented airline flows can exchange offers and orders, while traditional GDS environments may also maintain PNR, ticket and EMD states. These records overlap but are not synonyms. The MCP server should expose a documented mapping and retain the source representation needed for servicing and audit.

Hotels commonly distribute responsibility across CRS, channel manager and PMS. A CRS may own central rates and inventory, a channel manager may control channel distribution, and the PMS may own the operational stay. A distribution reservation is therefore not automatically identical to the latest stay, payment or housekeeping state.

Capability boundaries for model-controlled interaction

Capabilities should express bounded outcomes such as search_travel_products, price_itinerary, create_offer, revalidate_offer, create_order and get_order. Their contracts state required identity, traveller and market context, output limits, side effects, idempotency, authorization and stable error classes.

One universal book_trip tool hides intermediate states and makes informed approval difficult. At the opposite extreme, exposing every supplier endpoint forces the model to orchestrate a distributed transaction. The server boundary should retain domain invariants and expose only decisions the host can use safely.

Complete MCP example: revalidate before creating an order

[
  {
    "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
      }
    }
  }
]

The example contains two separate JSON-RPC messages: a tool request and its response. The changed price produces a new offer version and explicitly invalidates the earlier approval. No order is created by this read-and-prepare capability.

A subsequent create_order call would require authorization and a new approval tied to version 8, the EUR 1,848 total and the disclosed conditions. Its idempotency key must represent that exact intended transaction, and the server must reconcile the resulting authoritative order.

Errors, expiry and retry semantics

Invalid input, denied access, unknown objects, expired offers, price changes, supplier timeouts and internal faults are distinct error classes. An expired offer is an expected domain conflict that can lead to repricing; it should not be hidden as a generic server error.

Read operations may be retried within rate and freshness limits. Writes require idempotency and reconciliation because a timeout can occur after the backend changed state. Reusing an old approval after repricing is unsafe even when the technical request is otherwise valid.

Partial orders, servicing and refunds

Multi-component trips rarely provide one distributed ACID transaction. One segment can be confirmed while another is rejected, or payment can be authorised before final supplier confirmation. The output must expose every component, its status, financial effect and next safe action instead of presenting the trip as wholly booked.

Cancellation and refund are separate processes. A service can be cancelled while a refund remains requested, approved, declined or paid through another channel. Non-refundable elements, cancellation fees and supplier rejection must remain explicit states. An agent must never describe a requested refund as completed.

Acceptance criteria for production

Tests should cover version negotiation, schema limits, object-level authorization, expired and modified offers, duplicate requests, supplier timeouts, partial confirmation and reconciliation after an ambiguous response. Contract tests must verify both machine-readable structure and the claims a host is permitted to present.

Production operation requires named owners, source-of-truth documentation, service objectives, per-capability telemetry, incident procedures, deprecation and kill switches. Useful measures include stale-offer rejection, inappropriate calls, duplicate prevention, reconciliation success, latency and the rate of manual correction.

FAQ zu Product, offer and order in the Travel MCP model

Why is a search result insufficient for booking?

Price, inventory and conditions are time-dependent. The authoritative provider must revalidate the selected offer before an order is created.

Should a language model calculate a binding travel price?

No. Binding prices must come from an authorised pricing or booking source. The model may explain sourced components but must not invent or recompute the commercial commitment.

Are an order, a PNR and a ticket the same object?

No. They belong to different state models and may be issued by different systems. A correct integration preserves their namespaces, relationships and authoritative status.

Primary sources and academic context

This page follows the versioned MCP specification and separates normative requirements from architectural recommendations.