Get Booking

Start every servicing workflow here. Retrieve the booking, choose the intended booked_item_id, and inspect that item’s servicing eligibility and refusal reasons.

Tool description (what the LLM sees)

Start here before flight_refund, flight_exchange, hotel_cancel or car_cancel. Retrieve a booking by its Jinko booking_ref, then choose the intended items[] entry.

Each item has a stable booked_item_id (an "itm_…" string), itinerary summary, confirmation, supplier_references (the confirmations the airline, hotel or rental company issued), status and servicing eligibility: can_refund, can_void, can_exchange, refund_support_level, exchange_support_level and refusal reasons/reason_code. Use booking_ref + that booked_item_id on every subsequent servicing action. Keep the same booked_item_id after an exchange. booking_state summarizes the booking's progress after payment.

A flight item's confirmation.details.flight.fare_conditions lists the fare's refund and change rules (rule_type, penalty, penalty_fee). They are an estimate kept with the booking, not a live check: whether a refund or change can be done is confirmed by the refund or exchange tools when it starts.

check_eligibility (default true) checks each item's servicing eligibility live with the airline or supplier, which can add several seconds for a flight. Send check_eligibility: false to list or display a booking; leave it out or send true when the user wants to cancel or change, before the refund or exchange tools.

last_name is required for guests and optional for an authenticated owner. No login is needed for guest lookup.

USAGE: get_booking({ booking_ref: "JNK-A7B3X9", last_name: "Doe" })

booking_ref is the JNK-XXXXXX reference from the confirmation email, get_trip or submit_agent_payment. The airline record locator (pnr) in a flight item's supplier_references is for airline check-in; servicing uses booking_ref + booked_item_id.

Parameters

Name	Type	Required	Description
`booking_ref`	`string`	Yes	Trip-level Jinko booking_ref returned by get_trip or submit_agent_payment. Use it to look up the booking with get_booking.
`last_name`	`string \| null`	No	Primary traveler last name. Required for guests; optional for an authenticated owner of the booking.
`check_eligibility`	`boolean`	No	Check now, with the airline or supplier, whether each item can be voided, refunded or exchanged (items[].servicing). Defaults to true. For flights this can add several seconds; send false to read the booking and its stored fare conditions only.
`user_intent`	`string`	No	The end user’s current request in their own words, e.g. “help me with my travel plans”. Pass it as-is when short; otherwise condense the goal and constraints into 1-2 sentences. Strip personal identifiers (names, emails, phone numbers, addresses, payment details), replace them with placeholders like “[name]”. Optional. Jinko uses it to understand demand, and hotel_search uses it to rank hotel results against what the user asked for (e.g. “quiet, with a gym, near Times Square”), so keep the user’s stated preferences in it.

Examples

Guest lookup by Jinko reference + last name:

{
  "name": "get_booking",
  "arguments": {
    "booking_ref": "JNK-ABC123",
    "last_name": "Doe"
  }
}

Returns the booking envelope (itineraries, travelers, status). The MCP connection still requires authentication. Guest lookup verifies the booking reference and last name, so travelers do not need a personal Jinko login. Read a booking to display it, without the live eligibility check:

{
  "name": "get_booking",
  "arguments": {
    "booking_ref": "JNK-ABC123",
    "last_name": "Doe",
    "check_eligibility": false
  }
}

check_eligibility defaults to true, which checks with the airline or supplier whether each item can be voided, refunded or exchanged, and for a flight can add several seconds. With false the booking is read without that check and items[].servicing keeps the cancellation and exchange progress but leaves out can_refund, can_void, can_exchange and the support levels. Leave it out, or send true, when the traveler wants to cancel or change. Either way, a flight item whose fare rules are known carries them in confirmation.details.flight.fare_conditions, kept with the booking. The field is absent when no rules were recorded for the fare, so read it only when it is there:

{
  "rules": [
    { "rule_type": "CHANGE", "penalty": "ALLOWED_WITH_FEE", "penalty_fee": { "value": 8900, "currency": "EUR", "decimal_places": 2 } },
    { "rule_type": "CANCEL", "penalty": "NOT_ALLOWED" }
  ]
}

A fee is in the currency the airline states it in, which can differ from the fare’s. The conditions are an estimate: the airline can refund or void a ticket they call non-refundable, for example on the day it was issued. Whether a refund or change can be done is confirmed by flight_refund or flight_exchange when it starts. Error handling: MCP returns structuredContent.status: "not_found" for an unknown or inaccessible booking, including a last-name mismatch. It deliberately does not reveal whether the booking exists. Ask the user to check the reference and last name rather than retrying with variations.

Introduction

Flights

Hotels

Cars

Trip & Payment

Marketing claim

Parameters

Examples

​Parameters

​Examples

Parameters

Examples