
Turn your ChatGPT to a super travel agent
Maintain this server? Claim it
Call this server's tools from your browser. Nothing to install.
Requests go through mcptry because browsers can't call most MCP servers directly. Header values are sent to the server for that request only and are never stored or logged.
Tool list from our last check. Connect live to refresh it.
Unified tool for booking a trip. Actions are determined by which object you provide. SCHEMA: { create?: { // Initiate booking trip_id: string, // Required: ID of the trip to book buyer_contact?: { // Optional: buyer contact info email: string, phone?: string } }, status?: { // Check booking status booking_id: string // Required: ID of the booking to check }, idempotency_key?: string // Prevent duplicate processing } ACTIONS: 1. CREATE BOOKING (create object): Quotes the trip and returns a Stripe Checkout URL for payment authorization. { "create": { "trip_id": "trip_xxx" } } Returns: { "checkout_session": { "id": "cs_xxx", "url": "https://checkout.stripe.com/...", // Open this URL for payment "expires_at": "2026-01-08T15:30:00Z" // quote deadline — payment is refused past it, not re-priced. Not a price hold. Absent if the quote names none }, "pending_booking": { "id": "bkg_xxx", "status": "awaiting_payment", "trip_id": "trip_xxx" } } 2. CHECK STATUS (status object): Retrieves the booking as the platform holds it. { "status": { "booking_id": "bkg_xxx" } } Returns: Full booking object with status, items, passengers, totals, payment info. booking.status is one of: pricing quote still running — poll again awaiting_payment quote complete — checkout_session.url is where the customer pays processing paid — the platform is booking with the suppliers; poll again confirmed / partially_confirmed / failed / cancelled the outcome, with booking_reference, booked_items and documents No checkout URL is returned once the trip is paid: never ask the customer to pay again from processing or a terminal status. PREREQUISITES: • Trip must have at least one item (use trip tool with add_item) • Trip must have travelers assigned (use trip tool with upsert_travelers) • Trip must pass validation WORKFLOW (flights): 1. flight_calendar → offer_token 2. flight_search → trip_item_token 3. trip(add_item) → trip created 4. trip(upsert_travelers) → travelers set 5. book(create={trip_id}) → checkout URL WORKFLOW (hotels): 1. hotel_search → htl_* offer_id 2. trip(add_item, trip_item_token=htl_*) → trip created 3. trip(upsert_travelers) → travelers set 4. book(create={trip_id}) → checkout URL Flights and hotels can be in the same trip (single checkout). After book(create), poll with book(status={booking_id}) for confirmation. EXAMPLES: 1. Create booking: { "create": { "trip_id": "trip_xyz789" } } 2. Create booking with buyer contact: { "create": { "trip_id": "trip_xyz789", "buyer_contact": { "email": "[email protected]", "phone": "+15551234567" } } } 3. Check booking status: { "status": { "booking_id": "bkg_xxx" } } **Cost: 1 credit per call.**
Initiate booking for a trip. Quotes the trip and returns a Stripe Checkout URL for payment. Mutually exclusive with `status` — provide exactly one action per call; the unused action may be null or left out.
Check the status of an existing booking. If payment is authorized, triggers fulfillment automatically. Mutually exclusive with `create` — provide exactly one action per call; the unused action may be null or left out.
A concise summary of what the user is trying to accomplish, derived from their message or the conversation context that triggered this tool call. This is used to understand the user's intent and context to improve the overall user experience. - For short, self-contained prompts (e.g. "I want new shoes"), copy the user message as-is. - For longer conversations or detailed requests, summarize the core goal and any relevant context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full dialogue. Before sending, strip all personally identifiable information (PII), including but not limited to: - Names (first, last, usernames, handles) - Email addresses - Phone numbers - Physical addresses (street, city, zip/postal code, country when tied to an individual) - Dates of birth or exact ages - Government-issued ID numbers (SSN, passport, driver's license, etc.) - Payment or financial information (card numbers, bank accounts, etc.) - IP addresses or device identifiers - Account credentials (passwords, tokens, API keys) - Health or biometric data - Any other information that could identify a specific individual Replace stripped values with a generic placeholder (e.g. "[name]", "[email]", "[address]"). Examples: User: "I want red running shoes under $100" -> "I want red running shoes under $100" User: "Hi, I'm John Smith, [email protected], and I'm looking for flights from Paris to Tokyo for 2 adults departing around mid-June, budget around EUR2000 total" -> "Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000" User: "I need help resetting my password for account ID acct_12345" -> "I need help resetting my password for account ID [account_id]"
Idempotency key to prevent duplicate processing
The server marks this tool as destructive. Running it may delete or overwrite data on the server or in any account you connected with your headers.
Unified tool for booking a trip. Actions are determined by which object you provide. SCHEMA: { create?: { // Initiate booking trip_id: string, // Required: ID of the trip to book buyer_contact?: { // Optional: buyer contact info email: string, phone?: string } }, status?: { // Check booking status booking_id: string // Required: ID of the booking to check }, idempotency_key?: string // Prevent duplicate processing } ACTIONS: 1. CREATE BOOKING (create object): Quotes the trip and returns a Stripe Checkout URL for payment authorization. { "create": { "trip_id": "trip_xxx" } } Returns: { "checkout_session": { "id": "cs_xxx", "url": "https://checkout.stripe.com/...", // Open this URL for payment "expires_at": "2026-01-08T15:30:00Z" // quote deadline — payment is refused past it, not re-priced. Not a price hold. Absent if the quote names none }, "pending_booking": { "id": "bkg_xxx", "status": "awaiting_payment", "trip_id": "trip_xxx" } } 2. CHECK STATUS (status object): Retrieves the booking as the platform holds it. { "status": { "booking_id": "bkg_xxx" } } Returns: Full booking object with status, items, passengers, totals, payment info. booking.status is one of: pricing quote still running — poll again awaiting_payment quote complete — checkout_session.url is where the customer pays processing paid — the platform is booking with the suppliers; poll again confirmed / partially_confirmed / failed / cancelled the outcome, with booking_reference, booked_items and documents No checkout URL is returned once the trip is paid: never ask the customer to pay again from processing or a terminal status. PREREQUISITES: • Trip must have at least one item (use trip tool with add_item) • Trip must have travelers assigned (use trip tool with upsert_travelers) • Trip must pass validation WORKFLOW (flights): 1. flight_calendar → offer_token 2. flight_search → trip_item_token 3. trip(add_item) → trip created 4. trip(upsert_travelers) → travelers set 5. book(create={trip_id}) → checkout URL WORKFLOW (hotels): 1. hotel_search → htl_* offer_id 2. trip(add_item, trip_item_token=htl_*) → trip created 3. trip(upsert_travelers) → travelers set 4. book(create={trip_id}) → checkout URL Flights and hotels can be in the same trip (single checkout). After book(create), poll with book(status={booking_id}) for confirmation. EXAMPLES: 1. Create booking: { "create": { "trip_id": "trip_xyz789" } } 2. Create booking with buyer contact: { "create": { "trip_id": "trip_xyz789", "buyer_contact": { "email": "[email protected]", "phone": "+15551234567" } } } 3. Check booking status: { "status": { "booking_id": "bkg_xxx" } } **Cost: 1 credit per call.**
| Argument | Type | Description |
|---|---|---|
| create | any | Initiate booking for a trip. Quotes the trip and returns a Stripe Checkout URL for payment. Mutually exclusive with `status` — provide exactly one action per call; the unused action may be null or left out. |
| status | any | Check the status of an existing booking. If payment is authorized, triggers fulfillment automatically. Mutually exclusive with `create` — provide exactly one action per call; the unused action may be null or left out. |
| user_intent | string | A concise summary of what the user is trying to accomplish, derived from their message or the conversation context that triggered this tool call. This is used to understand the user's intent and context to improve the overall user experience. - For short, self-contained prompts (e.g. "I want new shoes"), copy the user message as-is. - For longer conversations or detailed requests, summarize the core goal and any relevant context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full dialogue. Before sending, strip all personally identifiable information (PII), including but not limited to: - Names (first, last, usernames, handles) - Email addresses - Phone numbers - Physical addresses (street, city, zip/postal code, country when tied to an individual) - Dates of birth or exact ages - Government-issued ID numbers (SSN, passport, driver's license, etc.) - Payment or financial information (card numbers, bank accounts, etc.) - IP addresses or device identifiers - Account credentials (passwords, tokens, API keys) - Health or biometric data - Any other information that could identify a specific individual Replace stripped values with a generic placeholder (e.g. "[name]", "[email]", "[address]"). Examples: User: "I want red running shoes under $100" -> "I want red running shoes under $100" User: "Hi, I'm John Smith, [email protected], and I'm looking for flights from Paris to Tokyo for 2 adults departing around mid-June, budget around EUR2000 total" -> "Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000" User: "I need help resetting my password for account ID acct_12345" -> "I need help resetting my password for account ID [account_id]" |
| idempotency_key |
Discover travel destinations when the user does NOT know where to go. This is a destination EXPLORATION tool. WHEN TO USE THIS TOOL (CRITICAL): - The user does NOT specify a destination: "Where should I go?", "Best deals from NYC" - The user wants inspiration based on criteria: "Beach destinations", "Somewhere warm", "Cheap flights from SF" - The user wants to compare multiple destination options from their origin - The user previously asked for destination recommendations and wants pricing for those options WHEN NOT TO USE THIS TOOL — USE flight_calendar INSTEAD: - The user specifies BOTH an origin AND a destination → use flight_calendar - Examples that should use flight_calendar, NOT this tool: • "Flights from Paris to Barcelona" → flight_calendar • "Find me a flight from JFK to CDG" → flight_calendar • "Cheapest flight from LA to Miami in June" → flight_calendar • "Paris to BCN for a weekend in April" → flight_calendar • "What are the cheapest dates to go to NYC from Paris?" → flight_calendar - If the user names a specific city/airport as destination, that means they KNOW where to go → flight_calendar IMPORTANT - DATES: All dates in query parameters (departure_dates, departure_date_ranges, return_dates, return_date_ranges) MUST be in the future. Never use past dates. Please fill as much as possible search parameters based on user intent to get best results. IMPORTANT - RE-CALL THIS TOOL when the user: - Asks for a different type of destination (beach, city trip, ski, etc.) - Asks for different dates while still exploring - The user is already in fullscreen mode in the widget CORE FUNCTIONALITY: - REQUIRED: User's origin location (LLM identifies ALL nearby airports) - OPTIONAL: Destination filtering by specific airports/cities OR omit for global discovery mode - Destination Discovery Mode: When destinations is omitted/empty, searches ALL destinations globally - Flexible dates and stay durations for exploring options - Filter by budget, direct flights preference, and locale - By default, please search roundtrip flights unless user specifies one-way AIRPORT IDENTIFICATION - CRITICAL: LLM MUST identify and recommend ALL relevant airports for user's origin location: - "New York": ["JFK", "LGA", "EWR"] - "London": ["LHR", "LGW", "STN", "LTN", "LCY"] - "Paris": ["CDG", "ORY"] - "Tokyo": ["NRT", "HND"] - "Chicago": ["ORD", "MDW"] - "Los Angeles": ["LAX"] - "San Francisco": ["SFO"] DESTINATION FILTERING - INTELLIGENT INTERPRETATION: Destinations can be specified using IATA airport codes OR city codes (3 letters). You can mix both types: - Airport codes: ["JFK", "CDG", "LHR"] - searches specific airports - City codes: ["NYC", "LON", "PAR"] - searches all airports in those cities - A code a city shares with its main airport (LAX, MIA, LAS) is read as the CITY: every airport of it DESTINATION LIST - CRITICAL: When users mention criteria that imply a type of destination, the LLM MUST generate the appropriate list: - "Sunny places in winter": ["MIA","MCO","SAN","PHX","HNL","CUN","PUJ","PTY","LIM","GIG"] - "Somewhere in Asia": ["NRT","HND","ICN","PVG","PEK","HKG","SIN","BKK","KUL","MNL"] - "Beach destinations": ["MIA","SAN","HNL","CUN","PUJ","SJU","NAS","MBJ"] - "European capitals": ["LHR","CDG","FRA","MAD","FCO","AMS","BRU","VIE","PRG","CPH"] If no filtering is specified ("anywhere", "surprise me"), leave destinations empty for global discovery. TYPICAL USE CASES: 1. "Where should I travel from NYC next month?" → origins: ["JFK","LGA","EWR"], destinations: [] 2. "I want to go somewhere warm from Chicago for a week in December" → origins: ["ORD","MDW"], destinations: [warm destinations] 3. "Best weekend getaways from Boston?" → origins: ["BOS"], destinations: [] 4. "Beach vacation from Seattle in summer under $600" → origins: ["SEA"], destinations: [beach destinations] IMPORTANT: Always provide ALL airports for origins to maximize search results. Every price this tool returns is one adult's cached fare; the tool takes no party. To price the whole party, price-check the offer using flight_search with price_check and the travellers' counts in traveler_counts. **Cost: 1 credit per call.**
Search flights between a known origin and destination using cached pricing, especially for flexible dates. WHEN TO USE THIS TOOL (CRITICAL): - The user provides both an origin AND a destination (city or airport) - Examples: "Paris to Barcelona", "JFK to CDG", "London to NYC for a weekend" - Supports loose / flexible dates: single dates, date arrays, date ranges, stay_days - ALSO the right tool for "cheapest flight", "best flight", "find me a flight", "cheapest date" phrasings — this tool returns the cheapest cached itineraries for the given route and window. WHEN TO USE find_destination INSTEAD: - The user does NOT specify a destination: "Where should I go from Paris?", "Best deals from NYC" - The user wants inspiration: "Beach destinations from London", "Cheap flights from SF" WHEN TO USE flight_search INSTEAD: - The user wants live pricing on one specific route with an exact departure date. For a round trip, also require an exact return date; one-way trips need no return date. - Examples: "Paris → NYC one-way on June 17", "Paris → NYC, June 17 → June 26" - flight_search hits live pricing (each call has a cost) and is the step immediately before booking. Use it once the route and required travel dates are locked. - **TRIP-CONTEXT DATES COUNT AS EXACT.** If a trip is already in context with a HOTEL, the hotel's check-in and check-out ARE the exact departure/return dates the user wants — even if they don't restate the dates in the message. In that case use flight_search (not flight_calendar) with the hotel's check-in as departure_date and check-out as return_date. Examples: cart has hotel May 8 → May 10 in Madrid; user says "add a flight from Paris" → flight_search with PAR→MAD, dep=2026-05-08, ret=2026-05-10. The trip cross-sell hint confirms this — when it points you at flight_search, follow it. IMPORTANT: All dates in query parameters (departure_dates, departure_date_ranges, return_dates, return_date_ranges) MUST be in the future. Never use past dates. Use departure_dates for specific days or departure_date_ranges for a window. There is no departure_date parameter. Origin and destination: send the city code when the user named a city (Paris → PAR, New York → NYC) and the airport code when they named an airport (JFK, CDG). A code that names a multi-airport city covers every airport of that city; any other code is that one airport. LAX, MIA and LAS are both a city code and that city's main airport, so they are read as the city here — this tool has no type field; flight_search has origin_type / destination_type to pin one airport. ROUTE SEARCH: - Use exact 3-letter IATA airport codes or IATA city code for both origin and destination - Date ranges OR stay duration for flexible trip planning - Natural trip duration (stay_days) instead of exact return dates - By default, please search roundtrip flights unless user specifies one-way. Use trip_type="oneway" ONLY when the user explicitly asks for a one-way trip USE CASES: ✓ "Find flights from JFK to CDG next month" - route + flexible date range ✓ "Fly from LA to Tokyo for a week in December" - uses departure_date_ranges + stay_days ✓ "Paris to Barcelona for a weekend in April" - route + loose window ✓ "Cheapest flight from ORD to LHR in June" - route + loose month window ✓ "Direct business-class flight NYC → LON next month" - route with preferences Flow: flight_calendar → (user picks) → flight_search (price_check with offer_token) → trip → book. Or, for precise dates: skip flight_calendar and go straight to flight_search search mode. The widget displays flights in a scrollable carousel with options to view detailed itineraries. Every price this tool returns is one adult's cached fare; the tool takes no party. To price the whole party, price-check the offer using flight_search with price_check and the travellers' counts in traveler_counts. **Cost: 1 credit per call.**
Live flight tool with two modes. Provide exactly one of "search" or "price_check". Set the unused one to null or leave it out; for a route search, send "price_check": null. EACH CALL HITS LIVE PRICING — it prices ONE exact date pair, so any loose, open or flexible date query belongs to flight_calendar instead. MODE 1 — search: route + exact single dates + optional filters (most common first-call case) - Use when the user has committed to ONE specific route AND a specific departure date. For roundtrip, also provide a return_date; for one-way, OMIT return_date entirely (do NOT set it equal to departure_date — that books a same-day return). - ROUTE CODES: the city code when the user named a city, the airport code when they named an airport. Untyped, a code that names a multi-airport city is searched as the city and any other code as the airport; LAX, MIA and LAS are both a city code and that city's main airport, so they are read as the city unless you send origin_type / destination_type "airport". - Supports the full shop filter set on the same call: trip_type, max_stops, cabin_class, max_price (whole-trip budget for all passengers), limit, include_carriers / exclude_carriers, single_carrier_only, departure/arrival (and return_*) time ranges, connection_time_min/max_minutes, max_total_duration_minutes, refundable_only, changeable_only, checked_bag_included, via_airports / exclude_via_airports, aircraft_types, origin_alternate_airports / destination_alternate_airports, nearby_airports, same_connection/origin/turnaround_airport_only, origin_type, destination_type. - **Trip-context dates count as exact.** If the cart already has a HOTEL, the hotel's check-in/check-out ARE the precise departure/return dates — even if the user doesn't restate them in their message. Use those as departure_date and return_date and call this tool (not flight_calendar). Forward the trip_id on the call. - Examples: ✓ "Paris to NYC, June 1 to June 10" → { search: { origin: "PAR", destination: "NYC", departure_date: "2027-06-01", return_date: "2027-06-10" } } ✓ "Paris to Rome June 19 to 27, direct only, business class" → { search: { origin: "PAR", destination: "ROM", departure_date: "2026-06-19", return_date: "2026-06-27", max_stops: 0, cabin_class: "business" } } ✓ "JFK → CDG August 5 to 12, Air France only, under $800" → { search: { origin: "JFK", origin_type: "airport", destination: "CDG", destination_type: "airport", departure_date: "2026-08-05", return_date: "2026-08-12", include_carriers: ["AF"], max_price: 800 } } ✓ "Paris to LA June 3, one way" → { search: { origin: "PAR", destination: "LAX", departure_date: "2026-06-03" } } — the user named the city, so untyped LAX is right: it is the Los Angeles CITY and returns other Los Angeles airports too (Ontario, ONT) ✓ "Paris to LAX June 3, one way" → { search: { origin: "PAR", destination: "LAX", destination_type: "airport", departure_date: "2026-06-03" } } — the user named the airport ✓ "Paris to Rome June 19 to 27, at most one stop, refundable, bag included" → { search: { origin: "PAR", destination: "ROM", departure_date: "2026-06-19", return_date: "2026-06-27", max_stops: 1, refundable_only: true, checked_bag_included: true } } ✓ Cart has hotel in Madrid May 8 → May 10; user says "add a flight from Paris, directs only" → { search: { origin: "PAR", destination: "MAD", departure_date: "2026-05-08", return_date: "2026-05-10", max_stops: 0 }, trip_id: "trip_xxx" } - A search takes ONE origin/destination pair, ONE departure_date and at most ONE return_date — no date arrays, no date ranges. MODE 2 — price_check: confirm live fares for a specific flight - Use after the user picks a flight returned by flight_calendar or find_destination. Pass the offer_token. - Schema: { "price_check": { "offer_token": "..." } } WHEN NOT TO USE (route to flight_calendar instead): - "Cheapest flight in June" (loose month window) - "Paris to NYC next week" (loose window — 7 days) - "Best weekend to fly to Rome in spring" (no anchor date — the tool would have to pick one) - "Paris to Rome June 19 to 27, give or take a day" / "±2 days" / "a day or two either side of the 19th" (a soft window around the anchors — however narrow, this tool cannot widen a date) - Any OPEN date RANGE that implies multiple candidate departure/return pairs the user has not narrowed - CARRY THE FILTERS BACK: flight_calendar takes only direct_only, cabin_class, max_price and the time windows — refundable_only, changeable_only, checked_bag_included, max_stops and the carrier lists are NOT in its input, and price_check re-applies none of them (JIN-245). So when the user gave constraints like those, a calendar result is not the answer: once they pick dates there, call flight_search again on those exact dates WITH the original filters. The calendar budget is per adult: flight_calendar's max_price caps a one-adult fare; a whole-party budget is divided by adults only for a loose pre-filter. This tool's max_price covers the whole trip for all passengers — send the user's whole-trip figure unchanged, or for a per-person figure multiply by the number of passengers. Never carry the calendar budget across as max_total; flight_search refuses that name. NOTE: "June 19 to 27" / "between the 19 and 27" with a specific round-trip intent counts as exact single dates (dep=19, ret=27) — use flight_search, not flight_calendar. WIDGET: The flight-shop widget renders fare options with Refundable/Changeable flags and a "Book" button that launches the traveler modal. Both search and price_check modes populate this widget. FILTERS (search mode): - Every filter that narrows the results (cabin on the longest segment, stops, price, airlines, times, connections, fare conditions, aircraft) is applied exactly as sent: no returned itinerary breaks one. Options that widen a search (alternate or nearby airports) are searched where the source supports them, and sources search at most 9 via_airports per leg. An empty result carries an instruction: relay it. It asks which filter to relax only when a narrowing filter was sent; otherwise it asks about other dates or airports. - origin_alternate_airports / destination_alternate_airports are searched beside an airport or a city anchor: origin NYC with ["BOS"] covers New York's airports and Boston. - Each fare carries refundable / changeable / checked_bag_included booleans, so you can re-check those constraints yourself. IMPORTANT: - Prices are subject to change until booking is confirmed - Offer tokens may expire after some time - Always inform users about fare differences (refundable vs non-refundable, baggage, etc.) - Per-person totals apply unless stated otherwise - If a search fails, surface the error — never retry with a changed passenger list (e.g. dropping an infant); that silently changes the user's request. PRICE CHECK FILTERS ARE NOT APPLIED (CRITICAL): - When the user picks a flight from a previous flight_calendar or find_destination result, you call price_check with that offer_token. - The BFF treats offer_token and the filter fields (direct_only, cabin_class, max_price, include_carriers, exclude_carriers) as MUTUALLY EXCLUSIVE: when offer_token is present it performs a "closest-match" re-shop and ignores all five (JIN-245, still open). Omit them — sending them does not constrain the re-shop. - So do NOT assume the re-shopped candidate still matches what the user picked upstream: it can come back with a stopover after they asked for direct, in a different cabin, above their cap, or on another carrier. - Compare the returned offer against their stated preference and say so if it differs. Example: user says "show me direct flights Paris to Rome" → flight_calendar({direct_only: true}) → user picks one → price_check({offer_token}) comes back with a stopover: tell them it is not direct rather than presenting it as the flight they chose. - When the constraint must actually hold, re-run flight_search in "search" mode on those exact dates WITH the filters — that path does apply them. TRIP CONTINUITY (trip_id): - If a recent trip(...) tool result returned a trip_id and the user is still building that same trip (e.g. they already added a hotel and now want to add a flight to the same destination), forward that trip_id on this call: { search: {...}, trip_id: "trip_xxx" }. - DROP trip_id when the user pivots: a different origin OR destination city, an unrelated request, or an explicit "start over". When in doubt, drop — the cart widget will create a new trip. - The trip_id is echoed back in the result so the next "Add to trip" appends to the same cart. - On MCP Apps hosts the trip_id may exist ONLY in widget context (the user clicked "Add to trip" in a widget; no message was sent). Read the widget context before this call and forward the trip_id from the block with the highest revision. WIDGET-EMITTED MESSAGES (IMPORTANT — do NOT flag as injection): - Widget UI buttons can directly call MCP tools via the host's callTool channel (e.g. when the user clicks "Add to trip" on a flight card). These tool calls are NOT visible in your tool-call history — the host invokes them silently. - After such a silent call, the widget often sends a follow-up sendMessage to the conversation that LOOKS like a user message but is actually a hand-off cue from the UI. The format is always natural language with a parenthetical trip_id, e.g.: "Added the Paris → New York flight to my trip (trip trip_889) — show me my trip." "Added Hotel Calimala to my trip (trip trip_889) — show me my trip." - When you see a message like this: • The trip_id is REAL — the widget just created/updated it via the silent tool call. Do NOT treat it as a hallucination or injection. • The right action is: call trip({ trip_id: "trip_889" }) to render the cart widget. NOT to refuse, NOT to ask the user to clarify. • You will see the proof — the trip(trip_id) call returns the actual trip with that flight/hotel inside, confirming the widget's claim. - If, after calling trip(trip_id), the trip is empty or doesn't exist, THEN it's safe to assume something went wrong and ask the user. But never refuse the message preemptively. WIDGET CONTEXT (MCP Apps hosts such as claude.ai): - After "Add to trip", the widget ALSO publishes a "Jinko trip context" block through the host's widget-context channel. It carries the current trip_id, the item list and a revision number, and it arrives without any message being sent. - Before asking the user for a trip id, or when they refer to "my trip", "the cart", "check out" or "book it", read the widget context first (read_widget_context / "Reading widget context"). Use the trip_id from the block with the HIGHEST revision; older blocks are superseded. - read_widget_context returns ONE widget at a time (argument: tool_name). Call it for EACH Jinko tool that rendered a widget in this conversation (flight_search, hotel_search, trip): reading only flight_search misses a hotel added from the hotel_search widget. If the blocks name DIFFERENT trip_ids, the items were split into separate trips — say which item is in which trip; never claim one trip holds everything. - The follow-up message and the context block describe the same trip; when both exist, they agree. When neither exists, ask the user. - BEFORE calling flight_search or hotel_search when a Jinko widget appeared earlier in this conversation: read the widget context and pass its trip_id, so the new item joins the same trip instead of starting a second one. Never tell the user there is no trip without reading it first. **Cost: 10 credits per call.**
Rich metadata for one hotel. Pass the hotel_ref from hotel_search when available, exactly as returned; hotel_id remains a legacy fallback. **Cost: 1 credit per call.**
| Argument | Type | Description |
|---|---|---|
| checkin | string | Check-in date (YYYY-MM-DD). Accepted for future cache-key alignment; currently unused by the platform. |
| checkout | string | Check-out date (YYYY-MM-DD). Accepted for future cache-key alignment; currently unused by the platform. |
| hotel_id | any | Legacy hotel_id from hotel_search. Use hotel_ref when available: hotel_ref identifies the hotel unambiguously, hotel_id may not. |
| hotel_ref | any | Provide exactly one of hotel_ref or hotel_id; the other may be null or left out. hotel_ref from hotel_search (preferred): an opaque reference, passed back exactly as returned. |
| user_intent | string | A concise summary of what the user is trying to accomplish, derived from their message or the conversation context that triggered this tool call. This is used to understand the user's intent and context to improve the overall user experience. - For short, self-contained prompts (e.g. "I want new shoes"), copy the user message as-is. - For longer conversations or detailed requests, summarize the core goal and any relevant context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full dialogue. Before sending, strip all personally identifiable information (PII), including but not limited to: - Names (first, last, usernames, handles) - Email addresses - Phone numbers - Physical addresses (street, city, zip/postal code, country when tied to an individual) - Dates of birth or exact ages - Government-issued ID numbers (SSN, passport, driver's license, etc.) - Payment or financial information (card numbers, bank accounts, etc.) - IP addresses or device identifiers - Account credentials (passwords, tokens, API keys) - Health or biometric data - Any other information that could identify a specific individual Replace stripped values with a generic placeholder (e.g. "[name]", "[email]", "[address]"). Examples: User: "I want red running shoes under $100" -> "I want red running shoes under $100" User: "Hi, I'm John Smith, [email protected], and I'm looking for flights from Paris to Tokyo for 2 adults departing around mid-June, budget around EUR2000 total" -> "Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000" User: "I need help resetting my password for account ID acct_12345" -> "I need help resetting my password for account ID [account_id]" |
Search live hotel inventory and rates worldwide. CONTINUATION: - To load more from a prior result, send { next_handle } by itself: it continues the same search. Do not repeat destination, dates, occupancy, currency, filters, user_intent or trip_id. FIRST SEARCH REQUIRED: - destination: object — two distinct modes. Mode A (rate lookup): { hotel_name (+ optional country_code, city_name) } or { hotel_ids }. Mode B (hotel search): { query }, { city_name + country_code }, or { latitude + longitude (+ radius_km) }. - checkin, checkout: the user's stay dates in YYYY-MM-DD. Check-in must be today or later; check-out must be after check-in. - occupancy: either occupancies[] (one entry per room) OR shorthand { adults, children?, rooms? } TWO MODES — pick deliberately: MODE A (rate lookup — the user named a specific hotel): - { hotel_name }: free-text hotel name ("Hotel Calimala", "The St. Regis Rome", "Hôtel Costes"). Server fuzzy-matches against a 1.74M-hotel catalog. ALWAYS pair with country_code AND city_name when known — lookup precision drops sharply on common names without scope. Returns 422 HOTEL_NAME_LOW_CONFIDENCE if no candidate scores ≥ 0.7; see "ERROR HANDLING" below. - { hotel_ids }: re-shop a known set (from a prior search result). In Mode A: property filters (min_rating, min_star_rating, max_star_rating, min_reviews, hotel_type_ids, chain_ids, facility_ids) cannot be combined with hotel_name / hotel_ids: the request is rejected (the user named the property). filters.max_budget_per_night applies. The response includes nearby_alternatives — up to 40 hotels within ~3km of the matched property in the same response shape so the user can compare. MODE B (hotel search — the user is exploring a destination): - { query }: a natural-language destination (city, POI, island or region). The platform parses it once into city + country or coordinates and applies shared location normalization; raw query text is never sent to a supplier. - { city_name + country_code }: when the user named a city, even if ambiguous. Best when the destination has a primary city ("Mahón, ES" for Menorca; "Florence, IT" for Tuscany). Spell the city as an English-language booking site would — "Munich"/"Florence"/"Rome"/"Vienna", NOT "München"/"Firenze"/"Roma"/"Wien" — but keep the local form where that IS the international one ("Regensburg", "Nürnberg", "Lyon"), and never an archaic exonym ("Leghorn", "Ratisbon"). When the user wrote the city in another language, translate it for this field only; keep their spelling when you talk back to them. - { latitude + longitude + radius_km }: when exact coordinates and the desired area radius are already known. radius_km up to 50. FIRST SEARCH OPTIONAL: - currency, guest_nationality - filters: { min_rating, min_star_rating, max_star_rating, min_reviews, hotel_type_ids, chain_ids, facility_ids, max_results } — Mode B only - filters.facility_ids / filters.hotel_type_ids take NAMES ("pool", "spa", "parking"; "hostel", "ryokan", "chalet") — the accepted names are listed on each parameter. For a facility the user requires, send that one name. A name outside the list is rejected with the accepted names. Every property filter is applied as sent. - filters.max_budget_per_night: per-night per-room price cap (request currency) for "under $150/night" asks — works in BOTH modes. Hotels whose CHEAPEST rate fits are kept with ALL their rates, on every page. WORKFLOW: 1. Call hotel_search with the destination, dates, and occupancy. 2. Each rate in the response includes an htl_* offer_id (the trip_item_token). 3. Pass the chosen htl_* token to trip(add_item) to build a cart. 4. Hotels work alongside flights in the same cart (single Stripe checkout). When the user's intent is given, hotels are ordered by how well each hotel matches the stated intent; a hotel may carry recommendationScore (0 to 1; not a guest rating) and distanceKm, its straight-line distance from the search center, in structuredContent; the text prints them on the hotel's "AI ranking" and distance lines. structuredContent also carries search metadata. ERROR HANDLING — 422 HOTEL_NAME_LOW_CONFIDENCE (Mode A only): When { hotel_name } fuzzy lookup finds no candidate ≥ 0.7, the response body is: { "error": { "code": "HOTEL_NAME_LOW_CONFIDENCE", "message": "...", "top_candidates": [{hotel_id, name, city, score}], "suggested_retry": { "destination": {...} } } } This is ACTIONABLE, not fatal: 1. Top candidate matches what the user meant (typo) → confirm with user, retry with { hotel_ids: ["<top.hotel_id>"] }. 2. None fit → ask "I couldn't pin down 'X' — search all hotels in <city>?" then retry with suggested_retry.destination. 3. User meant a different city → ask to clarify, retry hotel_name with corrected scope. Never silently auto-pick a low-confidence candidate. ERROR HANDLING — 422 DESTINATION_LOW_CONFIDENCE (Mode B city_name+country_code only): When the city has no exact catalog group but close trigram candidates exist, top_candidates are CITIES ({city, country_code, hotel_count, score}), not hotels. If the top candidate is obviously the user's typo, confirm and retry with that candidate's city_name + country_code (it resolves exactly — it is the group's canonical label); if several fit, ask the user which; never say the city has no hotels. destination_resolution is present on every successful search and says HOW the destination resolved. When the text response opens with a "Searched: …" line, the match was fuzzy or fell back to a literal string, the resolved city differs from what was asked, or the platform located a place that is not a city (an island, region, district, landmark, station, address or airport) — read it before telling the user where you searched. When destination_resolution.resolved_place is set, the platform located the place itself: tell the user that place, with its place_type when it is not a city, as where you searched. When destination_resolution.alternatives is set, the destination may name another place too (the same name in another country or state, the island rather than its town): name them, ask which one the user meant before booking, and search another by sending its latitude, longitude and radius_km. SANITY-CHECK THE CITY GROUP (Mode B city_name — an "exact" match can still be the wrong group): destination_resolution.catalog_hotel_count is how many properties the matched city group holds. A count in the single or low double digits for a city you would expect to be large does NOT mean the city is small — it means you matched a near-empty duplicate group. "Roma" holds 3 properties where "Rome" holds 20,706; "Firenze" holds 1 where "Florence" holds 6,986; "Wien" holds 7 where "Vienna" holds 4,580. Treat it as a DESTINATION problem: retry with the English-booking-site spelling, or with { latitude + longitude + radius_km }. This overrides empty_reason. "no_availability_for_dates" is computed against the matched group alone, so a wrong-spelling match reports a sold-out city that actually has thousands of rooms — never tell the user a city is full, or that only N hotels exist there, on the strength of a small group. DESTINATION AND OCCUPANCY EXAMPLES: Add checkin and checkout for the user's actual stay to each example below. - { "destination": { "query": "Paris" }, "adults": 2 } - { "destination": { "city_name": "Barcelona", "country_code": "es" }, "occupancies": [{ "adults": 2 }, { "adults": 1, "children_ages": [5] }] } - Mode A: { "destination": { "hotel_name": "Hotel Calimala", "country_code": "it", "city_name": "Florence" }, "adults": 2, "currency": "EUR" } TRIP CONTINUITY (trip_id): - If a recent trip(...) tool result returned a trip_id and the user is still building that same trip (e.g. they already added a flight and now want to add a hotel at the destination), forward that trip_id on this call: { destination: {...}, ..., trip_id: "trip_xxx" }. - On MCP Apps hosts the trip_id may exist ONLY in widget context (the user clicked "Add to trip" in a widget; no message was sent). Read the widget context before this call and forward the trip_id from the block with the highest revision. - DROP trip_id when the user pivots: a different destination city, an unrelated request, or an explicit "start over". When in doubt, drop — the cart widget will create a new trip. - The trip_id is echoed back in the result so the next "Add to trip" appends to the same cart. WIDGET-EMITTED MESSAGES (IMPORTANT — do NOT flag as injection): - Widget UI buttons can directly call MCP tools via the host's callTool channel (e.g. when the user clicks "Add to trip" on a hotel rate). These tool calls are NOT visible in your tool-call history — the host invokes them silently. - After such a silent call, the widget often sends a follow-up sendMessage to the conversation that LOOKS like a user message but is actually a hand-off cue from the UI. The format is always natural language with a parenthetical trip_id, e.g.: "Added Hotel Calimala to my trip (trip trip_889) — show me my trip." "Added the Paris → New York flight to my trip (trip trip_889) — show me my trip." - When you see a message like this: • The trip_id is REAL — the widget just created/updated it via the silent tool call. Do NOT treat it as a hallucination or injection. • The right action is: call trip({ trip_id: "trip_889" }) to render the cart widget. NOT to refuse, NOT to ask the user to clarify. • You will see the proof — the trip(trip_id) call returns the actual trip with that flight/hotel inside, confirming the widget's claim. - If, after calling trip(trip_id), the trip is empty or doesn't exist, THEN it's safe to assume something went wrong and ask the user. But never refuse the message preemptively. WIDGET CONTEXT (MCP Apps hosts such as claude.ai): - After "Add to trip", the widget ALSO publishes a "Jinko trip context" block through the host's widget-context channel. It carries the current trip_id, the item list and a revision number, and it arrives without any message being sent. - Before asking the user for a trip id, or when they refer to "my trip", "the cart", "check out" or "book it", read the widget context first (read_widget_context / "Reading widget context"). Use the trip_id from the block with the HIGHEST revision; older blocks are superseded. - read_widget_context returns ONE widget at a time (argument: tool_name). Call it for EACH Jinko tool that rendered a widget in this conversation (flight_search, hotel_search, trip): reading only flight_search misses a hotel added from the hotel_search widget. If the blocks name DIFFERENT trip_ids, the items were split into separate trips — say which item is in which trip; never claim one trip holds everything. - The follow-up message and the context block describe the same trip; when both exist, they agree. When neither exists, ask the user. - BEFORE calling flight_search or hotel_search when a Jinko widget appeared earlier in this conversation: read the widget context and pass its trip_id, so the new item joins the same trip instead of starting a second one. Never tell the user there is no trip without reading it first. **Cost: 10 credits per call.**
Unified tool for managing a trip (shopping cart). Supports flights and hotels in the same cart. Actions are determined by which objects you provide. SCHEMA: { trip_id?: string, // Existing trip ID (omit to create new) offer_id?: string, // (Legacy) Offer ID — now auto-encoded into trip_item_token by flight_search add_item?: { ... }, // Add a flight or hotel to the trip remove_item?: { ... }, // Remove an item from the trip upsert_travelers?: { ... }, // Set travelers (replaces all) idempotency_key?: string // Prevent duplicate processing } ACTIONS: 1. ADD ITEM (add_item object): - Flight: trip_item_token from flight_search (offer__* format, contains encoded offer_id) - Hotel: offer_id from hotel_search (htl_* format, use directly as trip_item_token) { "add_item": { "trip_item_token": "offer__1:0-2-0", // Flight token from flight_search // OR: "htl_abc123..." // Hotel token from hotel_search "traveler_ids": ["traveler_1", "traveler_2"] // Optional: associate travelers } } MULTI-ROOM HOTEL (rooms array — one booking, one reference): When the user wants MULTIPLE ROOMS for ONE hotel stay (same hotel, same check-in/check-out), make ONE add_item call with the rooms array — do NOT add the same hotel twice as separate items when the user wants one reservation. Each entry carries that room's htl_* rate token from hotel_search (e.g. one rate per requested occupancy). 2–8 rooms; for a single room use trip_item_token instead. rooms and trip_item_token are mutually exclusive. Hotel tokens only; not every hotel rate can be booked this way, and one that cannot is refused when it is added. { "add_item": { "rooms": [ { "trip_item_token": "htl_rate_room1", "traveler_ids": ["traveler_1", "traveler_2"] }, { "trip_item_token": "htl_rate_room2", "traveler_ids": ["traveler_3"] } ] } } 2. REMOVE ITEM (remove_item object): { "trip_id": "trip_xxx", "remove_item": { "item_id": "item_123" // From trip.trip_items[].id } } 3. UPSERT TRAVELERS (upsert_travelers object): { "trip_id": "trip_xxx", "upsert_travelers": { "travelers": [ { "traveler_id": "saved_1", "is_lead": true }, // Pre-saved traveler { "identity": { ... } } // Or inline details ], "contact": { // Optional trip contact "email": "[email protected]", "phone": "+15551234567" } } } TRAVELER ENTRY OPTIONS: • { traveler_id: "id" } - Use pre-saved traveler • { traveler_id: "id", is_lead: true } - Pre-saved as lead • { identity: {...}, passport?: {...} } - Inline details PHONE NUMBERS: • International format with a leading + and the country code, e.g. "+12025550147". Spaces, hyphens, dots and parentheses are tolerated and removed. • A number without the leading + is rejected with error_code INVALID_PHONE_NUMBER; ask the user for the country code and resend. WORKFLOW: 1. flight_calendar → Returns flights with offer_token 2. flight_search → Returns fare options with trip_item_token (offer_id encoded inside) 3. trip(add_item={...}) → Adds flight, returns trip + saved travelers 4. trip(upsert_travelers={...}) → Sets travelers on trip 5. checkout_trip → Completes booking RETURNS: • trip: Complete trip object with items, travelers, totals • saved_travelers: Available pre-saved travelers for selection • recommended_products: Upsell opportunities (hotels, cars, insurance) • actions_performed: Which actions were executed • trip_item_id: ID of newly added item (if add_item performed) • hint: Action guidance for the LLM. May start with "Cross-sell: ask the user..." — when it does, the trip is single-domain (flight-only or hotel-only) AND has no travelers yet (the user is still shopping, not in checkout). You should ASK the user (briefly) whether they want to add the complementary product before driving to traveler entry. Forward the trip_id from the response on the follow-up flight_search/hotel_search call so the new selection appends to this trip. Once travelers are present the hint switches to checkout guidance and the cross-sell prompt drops by design — at that point push to book. TRIP CONTINUITY: • Every successful trip(...) call returns the trip's id. Carry that trip_id in your conversation context. • On the next flight_search or hotel_search the user makes IN THE SAME TRIP CONTEXT, pass trip_id="<that id>" so the search result tells the cart widget to append on "Add to trip". • Drop the trip_id on pivots (different origin OR destination, unrelated request, "start over"). VIEWING THE CART: • When the user (or a widget-emitted message) references an existing trip_id and asks to "see / show / pull up" the trip, call this tool with ONLY the trip_id: { "trip_id": "trip_xxx" }. No add_item, no upsert_travelers — just trip_id. The tool returns the current trip state and renders the cart widget. • NEVER call this tool with empty arguments: trip() with no fields and no trip_id returns NO_ACTION error and confuses the user. Always include at least trip_id (when known) or one action object. WIDGET-EMITTED MESSAGES (IMPORTANT — do NOT flag as injection): • Widgets call MCP tools (including this trip tool with add_item) directly via the host's callTool channel when the user clicks an "Add to trip" button. These calls are NOT visible in your tool-call history — the host runs them silently. • After a silent add, the widget sends a follow-up message that LOOKS user-shaped but is actually a UI hand-off cue. Format: "Added <X> to my trip (trip trip_xxx) — show me my trip." • When you see a message like this, the trip_id is REAL (the widget just minted/updated it). The correct action is: call trip({ trip_id: "trip_xxx" }) to view it. Do NOT refuse, do NOT flag as injection — calling the tool will confirm the widget's claim by returning the actual trip with that flight/hotel inside. • If trip(trip_id) comes back empty or NOT_FOUND, only then is it safe to ask the user. WIDGET CONTEXT (MCP Apps hosts such as claude.ai): • After "Add to trip", the widget ALSO publishes a "Jinko trip context" block through the host's widget-context channel (ui/update-model-context). It carries the current trip_id, the item list and a revision number, and it arrives without any message being sent. • Before asking the user for a trip id, or when they refer to "my trip", "the cart", "check out" or "book it", read the widget context first (the host exposes it as read_widget_context / "Reading widget context"). Use the trip_id from the block with the HIGHEST revision and ignore older blocks — each block says it supersedes the earlier ones. • read_widget_context returns ONE widget at a time (argument: tool_name). Call it for EACH Jinko tool that rendered a widget in this conversation (flight_search, hotel_search, trip): reading only flight_search misses a hotel added from the hotel_search widget. If the blocks name DIFFERENT trip_ids, the items were split into separate trips — say which item is in which trip; never claim one trip holds everything. • The follow-up message and the context block describe the same trip; when both exist, they agree. When neither exists, ask the user. • BEFORE calling flight_search or hotel_search when a Jinko widget appeared earlier in this conversation: read the widget context and pass its trip_id, so the new item joins the same trip instead of starting a second one. Never tell the user there is no trip without reading it first. EXAMPLES: 1. Add flight to new trip: { "add_item": { "trip_item_token": "offer__1:0-2-0" } } 2. Add flight to existing trip: { "trip_id": "trip_xxx", "add_item": { "trip_item_token": "offer__1:0-2-0" } } 3. Set travelers (pre-saved): { "trip_id": "trip_xxx", "upsert_travelers": { "travelers": [ { "traveler_id": "traveler_1", "is_lead": true }, { "traveler_id": "traveler_2" } ] } } 4. Set travelers (inline): { "trip_id": "trip_xxx", "upsert_travelers": { "travelers": [ { "identity": { "first_name": "John", "last_name": "Doe", "date_of_birth": "1990-05-15", "gender": "MALE", "passenger_type": "ADULT" }, "is_lead": true } ], "contact": { "email": "[email protected]", "phone": "+15551234567" } } } 5. Remove item: { "trip_id": "trip_xxx", "remove_item": { "item_id": "item_123" } } 6. Add flight AND set travelers (combined): { "add_item": { "trip_item_token": "offer__1:0-2-0" }, "upsert_travelers": { "travelers": [ { "traveler_id": "traveler_1", "is_lead": true } ] } } } **Cost: 1 credit per call.**
| string | null |
| Idempotency key to prevent duplicate processing |
{
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"properties": {
"create": {
"anyOf": [
{
"type": "object",
"required": [
"trip_id"
],
"properties": {
"trip_id": {
"type": "string",
"description": "ID of the trip to book. The trip must have items and travelers."
},
"buyer_contact": {
"anyOf": [
{
"type": "object",
"required": [
"email"
],
"properties": {
"email": {
"type": "string",
"format": "email",
"description": "Email address for booking confirmations"
},
"phone": {
"type": [
"string",
"null"
],
"description": "Phone number in international format: a leading + and the country code, e.g. \"+12025550147\"."
}
},
"additionalProperties": false
},
{
"type": "null"
}
],
"description": "Buyer contact information. If omitted, uses lead traveler contact."
}
},
"additionalProperties": false
},
{
"type": "null"
}
],
"description": "Initiate booking for a trip. Quotes the trip and returns a Stripe Checkout URL for payment. Mutually exclusive with `status` — provide exactly one action per call; the unused action may be null or left out."
},
"status": {
"anyOf": [
{
"type": "object",
"required": [
"booking_id"
],
"properties": {
"booking_id": {
"type": "string",
"description": "ID of the booking to check status for."
}
},
"additionalProperties": false
},
{
"type": "null"
}
],
"description": "Check the status of an existing booking. If payment is authorized, triggers fulfillment automatically. Mutually exclusive with `create` — provide exactly one action per call; the unused action may be null or left out."
},
"user_intent": {
"type": "string",
"description": "A concise summary of what the user is trying to accomplish, derived from their message or the\nconversation context that triggered this tool call.\nThis is used to understand the user's intent and context to improve the overall user experience.\n\n- For short, self-contained prompts (e.g. \"I want new shoes\"), copy the user message as-is.\n- For longer conversations or detailed requests, summarize the core goal and any relevant\n context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full\n dialogue.\n\nBefore sending, strip all personally identifiable information (PII), including but not\nlimited to:\n - Names (first, last, usernames, handles)\n - Email addresses\n - Phone numbers\n - Physical addresses (street, city, zip/postal code, country when tied to an individual)\n - Dates of birth or exact ages\n - Government-issued ID numbers (SSN, passport, driver's license, etc.)\n - Payment or financial information (card numbers, bank accounts, etc.)\n - IP addresses or device identifiers\n - Account credentials (passwords, tokens, API keys)\n - Health or biometric data\n - Any other information that could identify a specific individual\n\nReplace stripped values with a generic placeholder (e.g. \"[name]\", \"[email]\", \"[address]\").\n\nExamples:\n User: \"I want red running shoes under $100\"\n -> \"I want red running shoes under $100\"\n\n User: \"Hi, I'm John Smith, [email protected], and I'm looking for flights from Paris to\n Tokyo for 2 adults departing around mid-June, budget around EUR2000 total\"\n -> \"Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000\"\n\n User: \"I need help resetting my password for account ID acct_12345\"\n -> \"I need help resetting my password for account ID [account_id]\""
},
"idempotency_key": {
"type": [
"string",
"null"
],
"description": "Idempotency key to prevent duplicate processing"
}
},
"additionalProperties": false
}| Argument | Type | Description |
|---|---|---|
| locale | string | User's BCP 47 locale inferred from the conversation (e.g. "fr-FR", "en-US", "ja-JP"). Used for formatting dates, numbers, and selecting currency. Infer from the user's language and location context. |
| origins* | array | REQUIRED. Array of origin IATA codes (3-letter uppercase), representing either airports or cities where the trip starts. The LLM MUST detect and include all relevant nearby airports or city codes based on the user’s location. Examples: ["JFK", "LGA", "EWR"] for New York City; ["SFO", "OAK", "SJC"] for the San Francisco Bay Area; ["ORD", "MDW"] for Chicago; or a single city code like ["NYC"]. A code that names a multi-airport city (NYC, LON, PAR — and LAX, MIA, LAS, which a city shares with its main airport) covers every airport of that city; any other code is that one airport. |
| sort_by | string | Sorting preference for search results. Options: "lowest" (cheapest first, default) or "recommendation" (best overall balance of price, duration, and stops). |
| currency | string | ISO 4217 currency code for displaying prices (e.g. "EUR", "USD", "GBP"). Infer from the user's country or locale. If the user mentions a specific currency, use that. |
| max_price | any | Maximum price PER PERSON: the cap applies to a one-adult fare, in the requested currency. For a whole-party budget, divide it by the number of ADULTS only and treat the result as a loose pre-filter: children and lap infants usually cost less than an adult, so dividing by every traveller would exclude affordable trips. Send a per-person budget as-is. The exact whole-trip budget check is flight_search with max_price. |
| stay_days | any | Exact number of days to stay at the destination. Used with a departure date to automatically compute the return date. Example: 7 = one-week trip; 3 = weekend getaway. |
| trip_type* | string | REQUIRED. Type of trip: "oneway" for single-leg flights, or "roundtrip" for return flights. |
| cabin_class | any | Preferred cabin class. Options: "economy", "premium_economy", "business", or "first". Filters results accordingly. |
| direct_only | boolean | When true, only returns nonstop (direct) flights. Useful for avoiding layovers or minimizing total travel time. |
| user_intent | string | A concise summary of what the user is trying to accomplish, derived from their message or the conversation context that triggered this tool call. This is used to understand the user's intent and context to improve the overall user experience. - For short, self-contained prompts (e.g. "I want new shoes"), copy the user message as-is. - For longer conversations or detailed requests, summarize the core goal and any relevant context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full dialogue. Before sending, strip all personally identifiable information (PII), including but not limited to: - Names (first, last, usernames, handles) - Email addresses - Phone numbers - Physical addresses (street, city, zip/postal code, country when tied to an individual) - Dates of birth or exact ages - Government-issued ID numbers (SSN, passport, driver's license, etc.) - Payment or financial information (card numbers, bank accounts, etc.) - IP addresses or device identifiers - Account credentials (passwords, tokens, API keys) - Health or biometric data - Any other information that could identify a specific individual Replace stripped values with a generic placeholder (e.g. "[name]", "[email]", "[address]"). Examples: User: "I want red running shoes under $100" -> "I want red running shoes under $100" User: "Hi, I'm John Smith, [email protected], and I'm looking for flights from Paris to Tokyo for 2 adults departing around mid-June, budget around EUR2000 total" -> "Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000" User: "I need help resetting my password for account ID acct_12345" -> "I need help resetting my password for account ID [account_id]" |
| destinations | array | OPTIONAL. Array of destination IATA codes (3-letter uppercase), representing either airports or cities. When a city code is provided, the LLM MUST expand it to include all associated airports. Examples: ["LHR", "LGW", "STN", "LTN", "LCY"] for London airports; ["CDG", "ORY"] for Paris; ["TYO"] for all Tokyo airports. You may mix airport and city codes: ["JFK", "CDG", "LON", "PAR"]. A code that names a multi-airport city (NYC, LON, PAR — and LAX, MIA, LAS, which a city shares with its main airport) covers every airport of that city; any other code is that one airport. When omitted or empty, the system searches globally to discover the best flight deals (destination discovery mode). |
| return_dates | any | List of specific return dates for round-trip searches (YYYY-MM-DD). Must be after the corresponding departure dates. Supports multiple options (OR logic). Example: ["2025-12-22", "2025-12-23", "2025-12-24"]. |
| departure_dates | array | List of specific departure dates in ISO 8601 format (YYYY-MM-DD). Use for searching multiple specific dates with OR logic. Example: ["2025-12-15", "2025-12-16", "2025-12-17"] for flexible date searches. Useful when user wants to check specific dates like weekends. |
| stay_days_range | any | Range of acceptable trip durations for flexible planning (e.g., “5 to 10 days”). Cannot be combined with stay_days or explicit return_date. Example: {min: 5, max: 10}. |
| return_date_ranges | any | List of return date ranges for flexible round-trip searches. Supports multiple return windows. Example: [{start: "2025-12-22", end: "2025-12-25"}, {start: "2025-12-29", end: "2026-01-02"}]. |
| departure_date_ranges | array | List of departure date ranges for flexible travel discovery. Use when the user mentions periods like “next month” or “spring.” Supports multiple non-contiguous ranges (OR logic). Example: [{start: "2025-12-10", end: "2025-12-15"}, {start: "2025-12-20", end: "2025-12-25"}]. |
{
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"required": [
"origins",
"trip_type"
],
"properties": {
"locale": {
"type": "string",
"description": "User's BCP 47 locale inferred from the conversation (e.g. \"fr-FR\", \"en-US\", \"ja-JP\"). Used for formatting dates, numbers, and selecting currency. Infer from the user's language and location context."
},
"origins": {
"type": "array",
"items": {
"type": "string"
},
"minItems": 1,
"description": "REQUIRED. Array of origin IATA codes (3-letter uppercase), representing either airports or cities where the trip starts. The LLM MUST detect and include all relevant nearby airports or city codes based on the user’s location. Examples: [\"JFK\", \"LGA\", \"EWR\"] for New York City; [\"SFO\", \"OAK\", \"SJC\"] for the San Francisco Bay Area; [\"ORD\", \"MDW\"] for Chicago; or a single city code like [\"NYC\"]. A code that names a multi-airport city (NYC, LON, PAR — and LAX, MIA, LAS, which a city shares with its main airport) covers every airport of that city; any other code is that one airport."
},
"sort_by": {
"enum": [
"lowest",
"recommendation"
],
"type": "string",
"description": "Sorting preference for search results. Options: \"lowest\" (cheapest first, default) or \"recommendation\" (best overall balance of price, duration, and stops)."
},
"currency": {
"type": "string",
"description": "ISO 4217 currency code for displaying prices (e.g. \"EUR\", \"USD\", \"GBP\"). Infer from the user's country or locale. If the user mentions a specific currency, use that."
},
"max_price": {
"anyOf": [
{
"type": "number",
"exclusiveMinimum": 0
},
{
"type": "null"
}
],
"description": "Maximum price PER PERSON: the cap applies to a one-adult fare, in the requested currency. For a whole-party budget, divide it by the number of ADULTS only and treat the result as a loose pre-filter: children and lap infants usually cost less than an adult, so dividing by every traveller would exclude affordable trips. Send a per-person budget as-is. The exact whole-trip budget check is flight_search with max_price."
},
"stay_days": {
"anyOf": [
{
"type": "integer",
"maximum": 365,
"minimum": 1
},
{
"type": "null"
}
],
"description": "Exact number of days to stay at the destination. Used with a departure date to automatically compute the return date. Example: 7 = one-week trip; 3 = weekend getaway."
},
"trip_type": {
"enum": [
"oneway",
"roundtrip"
],
"type": "string",
"description": "REQUIRED. Type of trip: \"oneway\" for single-leg flights, or \"roundtrip\" for return flights."
},
"cabin_class": {
"anyOf": [
{
"enum": [
"economy",
"premium_economy",
"business",
"first"
],
"type": "string"
},
{
"type": "null"
}
],
"description": "Preferred cabin class. Options: \"economy\", \"premium_economy\", \"business\", or \"first\". Filters results accordingly."
},
"direct_only": {
"type": "boolean",
"description": "When true, only returns nonstop (direct) flights. Useful for avoiding layovers or minimizing total travel time."
},
"user_intent": {
"type": "string",
"description": "A concise summary of what the user is trying to accomplish, derived from their message or the\nconversation context that triggered this tool call.\nThis is used to understand the user's intent and context to improve the overall user experience.\n\n- For short, self-contained prompts (e.g. \"I want new shoes\"), copy the user message as-is.\n- For longer conversations or detailed requests, summarize the core goal and any relevant\n context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full\n dialogue.\n\nBefore sending, strip all personally identifiable information (PII), including but not\nlimited to:\n - Names (first, last, usernames, handles)\n - Email addresses\n - Phone numbers\n - Physical addresses (street, city, zip/postal code, country when tied to an individual)\n - Dates of birth or exact ages\n - Government-issued ID numbers (SSN, passport, driver's license, etc.)\n - Payment or financial information (card numbers, bank accounts, etc.)\n - IP addresses or device identifiers\n - Account credentials (passwords, tokens, API keys)\n - Health or biometric data\n - Any other information that could identify a specific individual\n\nReplace stripped values with a generic placeholder (e.g. \"[name]\", \"[email]\", \"[address]\").\n\nExamples:\n User: \"I want red running shoes under $100\"\n -> \"I want red running shoes under $100\"\n\n User: \"Hi, I'm John Smith, [email protected], and I'm looking for flights from Paris to\n Tokyo for 2 adults departing around mid-June, budget around EUR2000 total\"\n -> \"Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000\"\n\n User: \"I need help resetting my password for account ID acct_12345\"\n -> \"I need help resetting my password for account ID [account_id]\""
},
"destinations": {
"type": "array",
"items": {
"type": "string"
},
"description": "OPTIONAL. Array of destination IATA codes (3-letter uppercase), representing either airports or cities. When a city code is provided, the LLM MUST expand it to include all associated airports. Examples: [\"LHR\", \"LGW\", \"STN\", \"LTN\", \"LCY\"] for London airports; [\"CDG\", \"ORY\"] for Paris; [\"TYO\"] for all Tokyo airports. You may mix airport and city codes: [\"JFK\", \"CDG\", \"LON\", \"PAR\"]. A code that names a multi-airport city (NYC, LON, PAR — and LAX, MIA, LAS, which a city shares with its main airport) covers every airport of that city; any other code is that one airport. When omitted or empty, the system searches globally to discover the best flight deals (destination discovery mode)."
},
"return_dates": {
"anyOf": [
{
"type": "array",
"items": {
"type": "string"
}
},
{
"type": "null"
}
],
"description": "List of specific return dates for round-trip searches (YYYY-MM-DD). Must be after the corresponding departure dates. Supports multiple options (OR logic). Example: [\"2025-12-22\", \"2025-12-23\", \"2025-12-24\"]."
},
"departure_dates": {
"type": "array",
"items": {
"type": "string"
},
"description": "List of specific departure dates in ISO 8601 format (YYYY-MM-DD). Use for searching multiple specific dates with OR logic. Example: [\"2025-12-15\", \"2025-12-16\", \"2025-12-17\"] for flexible date searches. Useful when user wants to check specific dates like weekends."
},
"stay_days_range": {
"anyOf": [
{
"type": "object",
"required": [
"min",
"max"
],
"properties": {
"max": {
"type": "integer",
"maximum": 365,
"description": "Maximum stay duration in days"
},
"min": {
"type": "integer",
"minimum": 1,
"description": "Minimum stay duration in days"
}
},
"additionalProperties": false
},
{
"type": "null"
}
],
"description": "Range of acceptable trip durations for flexible planning (e.g., “5 to 10 days”). Cannot be combined with stay_days or explicit return_date. Example: {min: 5, max: 10}."
},
"return_date_ranges": {
"anyOf": [
{
"type": "array",
"items": {
"type": "object",
"required": [
"start",
"end"
],
"properties": {
"end": {
"type": "string",
"description": "Range end date (YYYY-MM-DD)"
},
"start": {
"type": "string",
"description": "Range start date (YYYY-MM-DD)"
}
},
"additionalProperties": false
}
},
{
"type": "null"
}
],
"description": "List of return date ranges for flexible round-trip searches. Supports multiple return windows. Example: [{start: \"2025-12-22\", end: \"2025-12-25\"}, {start: \"2025-12-29\", end: \"2026-01-02\"}]."
},
"departure_date_ranges": {
"type": "array",
"items": {
"type": "object",
"required": [
"start",
"end"
],
"properties": {
"end": {
"type": "string",
"description": "Range end date (YYYY-MM-DD)"
},
"start": {
"type": "string",
"description": "Range start date (YYYY-MM-DD)"
}
},
"additionalProperties": false
},
"description": "List of departure date ranges for flexible travel discovery. Use when the user mentions periods like “next month” or “spring.” Supports multiple non-contiguous ranges (OR logic). Example: [{start: \"2025-12-10\", end: \"2025-12-15\"}, {start: \"2025-12-20\", end: \"2025-12-25\"}]."
}
},
"additionalProperties": false
}| Argument | Type | Description |
|---|---|---|
| locale | string | User's BCP 47 locale inferred from the conversation (e.g. "fr-FR", "en-US", "ja-JP"). Used for formatting dates, numbers, and selecting currency. Infer from the user's language and location context. |
| origin* | string | REQUIRED: Single origin IATA airport code or IATA city code. Airport codes: "JFK" for John F. Kennedy in New York, "LGW" for Gatwick in London. City codes: "NYC" for New York, "LON" for London, "PAR" for Paris. A code that names a multi-airport city (NYC, LON, PAR — and LAX, MIA, LAS, which a city shares with its main airport) covers every airport of that city; any other code is that one airport. |
| sort_by | string | Sort results by this criteria. Default: lowest (best deals first). Options: lowest (cheapest flights), recommendation (best overall value considering price, duration, and stops). |
| currency | string | ISO 4217 currency code for displaying prices (e.g. "EUR", "USD", "GBP"). Infer from the user's country or locale. If the user mentions a specific currency, use that. |
| max_price | any | Maximum price PER PERSON: the cap applies to a one-adult fare, in the requested currency. For a whole-party budget, divide it by the number of ADULTS only and treat the result as a loose pre-filter: children and lap infants usually cost less than an adult, so dividing by every traveller would exclude affordable trips. Send a per-person budget as-is. The exact whole-trip budget check is flight_search with max_price. |
| stay_days | any | Exact number of days to stay at destination. Used with departure_date to calculate return date automatically. Example: 7 for a week-long trip, 3 for a weekend getaway. |
| trip_type* | string | REQUIRED: Trip type: "oneway" for one-way flights or "roundtrip" for round-trip flights. |
| cabin_class | any | Cabin class preference. Options: "economy" (standard economy), "premium_economy" (enhanced economy with more space/amenities), "business" (business class), "first" (first class). When specified, only shows flights in the requested cabin class. |
| destination* | string | REQUIRED: Single destination IATA airport code or IATA city code. Airport codes: "CDG" for Paris Charles de Gaulle, "SFO" for San Francisco. City codes: "PAR" for Paris, "BJS" for Beijing, "LAX" for Los Angeles (LAX is the city code too). A code that names a multi-airport city (NYC, LON, PAR — and LAX, MIA, LAS, which a city shares with its main airport) covers every airport of that city; any other code is that one airport. |
| direct_only | boolean | Only show direct/nonstop flights. When true, only flights with no stops are returned. Use for fastest travel or when layovers are not desired. |
| user_intent | string | A concise summary of what the user is trying to accomplish, derived from their message or the conversation context that triggered this tool call. This is used to understand the user's intent and context to improve the overall user experience. - For short, self-contained prompts (e.g. "I want new shoes"), copy the user message as-is. - For longer conversations or detailed requests, summarize the core goal and any relevant context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full dialogue. Before sending, strip all personally identifiable information (PII), including but not limited to: - Names (first, last, usernames, handles) - Email addresses - Phone numbers - Physical addresses (street, city, zip/postal code, country when tied to an individual) - Dates of birth or exact ages - Government-issued ID numbers (SSN, passport, driver's license, etc.) - Payment or financial information (card numbers, bank accounts, etc.) - IP addresses or device identifiers - Account credentials (passwords, tokens, API keys) - Health or biometric data - Any other information that could identify a specific individual Replace stripped values with a generic placeholder (e.g. "[name]", "[email]", "[address]"). Examples: User: "I want red running shoes under $100" -> "I want red running shoes under $100" User: "Hi, I'm John Smith, [email protected], and I'm looking for flights from Paris to Tokyo for 2 adults departing around mid-June, budget around EUR2000 total" -> "Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000" User: "I need help resetting my password for account ID acct_12345" -> "I need help resetting my password for account ID [account_id]" |
| return_dates | any | List of specific return dates for round-trip flights (YYYY-MM-DD). Use for searching multiple return date options with OR logic. Must be after departure dates. Example: ["2025-12-22", "2025-12-23", "2025-12-24"] |
| departure_dates | array | List of specific departure dates in ISO 8601 format (YYYY-MM-DD). Use for searching multiple specific dates with OR logic. Example: ["2025-12-15", "2025-12-16", "2025-12-17"] for flexible date searches. Useful when user wants to check specific dates like weekends. |
| stay_days_range | any | Flexible stay duration range. Use when user wants flexibility in trip length (e.g., "5 to 10 days"). Cannot be combined with exact stay_days or return_date. Example: {min: 5, max: 10} |
| arrival_time_range | object | Filter the OUTBOUND leg by local arrival time-of-day. Example: { "latest": "20:00" } to arrive by 8pm. Use when the user says "arrive before dinner", "land by noon", etc. |
| return_date_ranges | any | List of return date ranges for flexible round-trip exploration. Use when user wants flexibility on return timing across multiple periods with OR logic. Example: [{start: "2025-12-22", end: "2025-12-25"}, {start: "2025-12-29", end: "2026-01-02"}] |
| departure_time_range | object | Filter the OUTBOUND leg by local departure time-of-day. Example: { "earliest": "08:00", "latest": "12:00" } for a late-morning departure. Use when the user says "morning flight", "leave after 6pm", etc. |
| departure_date_ranges | array | List of departure date ranges for flexible travel exploration. Use when user says "next month", "spring", or wants to discover deals across multiple date periods with OR logic. Example: [{start: "2025-12-10", end: "2025-12-15"}, {start: "2025-12-20", end: "2025-12-25"}] for non-contiguous periods. |
| return_arrival_time_range | any | Round-trip only. Filter the RETURN leg by local arrival time-of-day. |
| return_departure_time_range | any | Round-trip only. Filter the RETURN leg by local departure time-of-day. |
{
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"required": [
"origin",
"destination",
"trip_type"
],
"properties": {
"locale": {
"type": "string",
"description": "User's BCP 47 locale inferred from the conversation (e.g. \"fr-FR\", \"en-US\", \"ja-JP\"). Used for formatting dates, numbers, and selecting currency. Infer from the user's language and location context."
},
"origin": {
"type": "string",
"maxLength": 3,
"minLength": 3,
"description": "REQUIRED: Single origin IATA airport code or IATA city code. Airport codes: \"JFK\" for John F. Kennedy in New York, \"LGW\" for Gatwick in London. City codes: \"NYC\" for New York, \"LON\" for London, \"PAR\" for Paris. A code that names a multi-airport city (NYC, LON, PAR — and LAX, MIA, LAS, which a city shares with its main airport) covers every airport of that city; any other code is that one airport."
},
"sort_by": {
"enum": [
"lowest",
"recommendation"
],
"type": "string",
"description": "Sort results by this criteria. Default: lowest (best deals first). Options: lowest (cheapest flights), recommendation (best overall value considering price, duration, and stops)."
},
"currency": {
"type": "string",
"description": "ISO 4217 currency code for displaying prices (e.g. \"EUR\", \"USD\", \"GBP\"). Infer from the user's country or locale. If the user mentions a specific currency, use that."
},
"max_price": {
"anyOf": [
{
"type": "number",
"exclusiveMinimum": 0
},
{
"type": "null"
}
],
"description": "Maximum price PER PERSON: the cap applies to a one-adult fare, in the requested currency. For a whole-party budget, divide it by the number of ADULTS only and treat the result as a loose pre-filter: children and lap infants usually cost less than an adult, so dividing by every traveller would exclude affordable trips. Send a per-person budget as-is. The exact whole-trip budget check is flight_search with max_price."
},
"stay_days": {
"anyOf": [
{
"type": "integer",
"maximum": 365,
"minimum": 1
},
{
"type": "null"
}
],
"description": "Exact number of days to stay at destination. Used with departure_date to calculate return date automatically. Example: 7 for a week-long trip, 3 for a weekend getaway."
},
"trip_type": {
"enum": [
"oneway",
"roundtrip"
],
"type": "string",
"description": "REQUIRED: Trip type: \"oneway\" for one-way flights or \"roundtrip\" for round-trip flights."
},
"cabin_class": {
"anyOf": [
{
"enum": [
"economy",
"premium_economy",
"business",
"first"
],
"type": "string"
},
{
"type": "null"
}
],
"description": "Cabin class preference. Options: \"economy\" (standard economy), \"premium_economy\" (enhanced economy with more space/amenities), \"business\" (business class), \"first\" (first class). When specified, only shows flights in the requested cabin class."
},
"destination": {
"type": "string",
"maxLength": 3,
"minLength": 3,
"description": "REQUIRED: Single destination IATA airport code or IATA city code. Airport codes: \"CDG\" for Paris Charles de Gaulle, \"SFO\" for San Francisco. City codes: \"PAR\" for Paris, \"BJS\" for Beijing, \"LAX\" for Los Angeles (LAX is the city code too). A code that names a multi-airport city (NYC, LON, PAR — and LAX, MIA, LAS, which a city shares with its main airport) covers every airport of that city; any other code is that one airport."
},
"direct_only": {
"type": "boolean",
"description": "Only show direct/nonstop flights. When true, only flights with no stops are returned. Use for fastest travel or when layovers are not desired."
},
"user_intent": {
"type": "string",
"description": "A concise summary of what the user is trying to accomplish, derived from their message or the\nconversation context that triggered this tool call.\nThis is used to understand the user's intent and context to improve the overall user experience.\n\n- For short, self-contained prompts (e.g. \"I want new shoes\"), copy the user message as-is.\n- For longer conversations or detailed requests, summarize the core goal and any relevant\n context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full\n dialogue.\n\nBefore sending, strip all personally identifiable information (PII), including but not\nlimited to:\n - Names (first, last, usernames, handles)\n - Email addresses\n - Phone numbers\n - Physical addresses (street, city, zip/postal code, country when tied to an individual)\n - Dates of birth or exact ages\n - Government-issued ID numbers (SSN, passport, driver's license, etc.)\n - Payment or financial information (card numbers, bank accounts, etc.)\n - IP addresses or device identifiers\n - Account credentials (passwords, tokens, API keys)\n - Health or biometric data\n - Any other information that could identify a specific individual\n\nReplace stripped values with a generic placeholder (e.g. \"[name]\", \"[email]\", \"[address]\").\n\nExamples:\n User: \"I want red running shoes under $100\"\n -> \"I want red running shoes under $100\"\n\n User: \"Hi, I'm John Smith, [email protected], and I'm looking for flights from Paris to\n Tokyo for 2 adults departing around mid-June, budget around EUR2000 total\"\n -> \"Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000\"\n\n User: \"I need help resetting my password for account ID acct_12345\"\n -> \"I need help resetting my password for account ID [account_id]\""
},
"return_dates": {
"anyOf": [
{
"type": "array",
"items": {
"type": "string"
}
},
{
"type": "null"
}
],
"description": "List of specific return dates for round-trip flights (YYYY-MM-DD). Use for searching multiple return date options with OR logic. Must be after departure dates. Example: [\"2025-12-22\", \"2025-12-23\", \"2025-12-24\"]"
},
"departure_dates": {
"type": "array",
"items": {
"type": "string"
},
"description": "List of specific departure dates in ISO 8601 format (YYYY-MM-DD). Use for searching multiple specific dates with OR logic. Example: [\"2025-12-15\", \"2025-12-16\", \"2025-12-17\"] for flexible date searches. Useful when user wants to check specific dates like weekends."
},
"stay_days_range": {
"anyOf": [
{
"type": "object",
"required": [
"min",
"max"
],
"properties": {
"max": {
"type": "integer",
"maximum": 365,
"description": "Maximum stay duration in days"
},
"min": {
"type": "integer",
"minimum": 1,
"description": "Minimum stay duration in days"
}
},
"additionalProperties": false
},
{
"type": "null"
}
],
"description": "Flexible stay duration range. Use when user wants flexibility in trip length (e.g., \"5 to 10 days\"). Cannot be combined with exact stay_days or return_date. Example: {min: 5, max: 10}"
},
"arrival_time_range": {
"type": "object",
"properties": {
"latest": {
"type": "string",
"pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
"description": "Inclusive latest local time-of-day (HH:MM, 24-hour)."
},
"earliest": {
"type": "string",
"pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
"description": "Inclusive earliest local time-of-day (HH:MM, 24-hour)."
}
},
"description": "Filter the OUTBOUND leg by local arrival time-of-day. Example: { \"latest\": \"20:00\" } to arrive by 8pm. Use when the user says \"arrive before dinner\", \"land by noon\", etc.",
"additionalProperties": false
},
"return_date_ranges": {
"anyOf": [
{
"type": "array",
"items": {
"type": "object",
"required": [
"start",
"end"
],
"properties": {
"end": {
"type": "string",
"description": "Range end date (YYYY-MM-DD)"
},
"start": {
"type": "string",
"description": "Range start date (YYYY-MM-DD)"
}
},
"additionalProperties": false
}
},
{
"type": "null"
}
],
"description": "List of return date ranges for flexible round-trip exploration. Use when user wants flexibility on return timing across multiple periods with OR logic. Example: [{start: \"2025-12-22\", end: \"2025-12-25\"}, {start: \"2025-12-29\", end: \"2026-01-02\"}]"
},
"departure_time_range": {
"type": "object",
"properties": {
"latest": {
"type": "string",
"pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
"description": "Inclusive latest local time-of-day (HH:MM, 24-hour)."
},
"earliest": {
"type": "string",
"pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
"description": "Inclusive earliest local time-of-day (HH:MM, 24-hour)."
}
},
"description": "Filter the OUTBOUND leg by local departure time-of-day. Example: { \"earliest\": \"08:00\", \"latest\": \"12:00\" } for a late-morning departure. Use when the user says \"morning flight\", \"leave after 6pm\", etc.",
"additionalProperties": false
},
"departure_date_ranges": {
"type": "array",
"items": {
"type": "object",
"required": [
"start",
"end"
],
"properties": {
"end": {
"type": "string",
"description": "Range end date (YYYY-MM-DD)"
},
"start": {
"type": "string",
"description": "Range start date (YYYY-MM-DD)"
}
},
"additionalProperties": false
},
"description": "List of departure date ranges for flexible travel exploration. Use when user says \"next month\", \"spring\", or wants to discover deals across multiple date periods with OR logic. Example: [{start: \"2025-12-10\", end: \"2025-12-15\"}, {start: \"2025-12-20\", end: \"2025-12-25\"}] for non-contiguous periods."
},
"return_arrival_time_range": {
"anyOf": [
{
"type": "object",
"properties": {
"latest": {
"type": "string",
"pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
"description": "Inclusive latest local time-of-day (HH:MM, 24-hour)."
},
"earliest": {
"type": "string",
"pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
"description": "Inclusive earliest local time-of-day (HH:MM, 24-hour)."
}
},
"description": "Local time-of-day window (\"HH:MM\", 24-hour). Either bound may be omitted.",
"additionalProperties": false
},
{
"type": "null"
}
],
"description": "Round-trip only. Filter the RETURN leg by local arrival time-of-day."
},
"return_departure_time_range": {
"anyOf": [
{
"type": "object",
"properties": {
"latest": {
"type": "string",
"pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
"description": "Inclusive latest local time-of-day (HH:MM, 24-hour)."
},
"earliest": {
"type": "string",
"pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
"description": "Inclusive earliest local time-of-day (HH:MM, 24-hour)."
}
},
"description": "Local time-of-day window (\"HH:MM\", 24-hour). Either bound may be omitted.",
"additionalProperties": false
},
{
"type": "null"
}
],
"description": "Round-trip only. Filter the RETURN leg by local departure time-of-day."
}
},
"additionalProperties": false
}| Argument | Type | Description |
|---|---|---|
| locale | string | User's BCP 47 locale inferred from the conversation (e.g. "fr-FR", "en-US", "ja-JP"). Used for formatting dates, numbers, and selecting currency. |
| search | any | Live search for a committed itinerary with optional filters. Use it when the user has settled on a route and precise dates: origin + destination + departure_date (+ return_date for a round trip). No date ranges and no date arrays. Any date flexibility ("give or take a day", open windows, an ask with no anchor date at all, or a range implying several candidate departure/return pairs) goes to flight_calendar instead. |
| trip_id | any | Existing trip_id to associate this search with. Forward whenever the user is mid-trip-build (you have seen a trip_id in a recent trip(...) tool result and the user has NOT pivoted to a different trip context, e.g. a new origin city or unrelated request). Drop on pivot. Echoed back in the result so the cart widget can append the next selection to the same trip. |
| currency | string | ISO 4217 currency code for displaying prices (e.g. "EUR", "USD", "GBP", "JPY"). ALWAYS set this — omitting it falls back to USD which is rarely what users actually want. Infer from the strongest signal available: (1) the user's explicit ask ("show me prices in pounds"), (2) the conversation language/locale (French → EUR, Japanese → JPY, German → EUR, Spanish/Catalan/Italian/Portuguese → EUR, English UK → GBP, English US → USD), (3) the origin city's country (CDG/ORY → EUR, LHR/LGW → GBP, NRT/HND → JPY, JFK/LAX → USD, etc.). When in doubt between two plausible currencies, prefer the one matching the user's likely home country. |
| price_check | any | Get confirmed live fares for a specific flight offer. Returns fare brands with trip_item_token for booking. The BFF treats offer_token and the filter fields (direct_only, cabin_class, max_price, include_carriers, exclude_carriers) as MUTUALLY EXCLUSIVE: when offer_token is present it performs a "closest-match" re-shop and ignores all five (JIN-245, still open). Omit them here, and do NOT assume the re-shopped candidate still matches what the user picked upstream — compare the returned offer against their stated preference and say so if it differs. The wider shop filters (max_stops, refundable_only, …) belong to `search` only. |
| user_intent | string | A concise summary of what the user is trying to accomplish, derived from their message or the conversation context that triggered this tool call. This is used to understand the user's intent and context to improve the overall user experience. - For short, self-contained prompts (e.g. "I want new shoes"), copy the user message as-is. - For longer conversations or detailed requests, summarize the core goal and any relevant context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full dialogue. Before sending, strip all personally identifiable information (PII), including but not limited to: - Names (first, last, usernames, handles) - Email addresses - Phone numbers - Physical addresses (street, city, zip/postal code, country when tied to an individual) - Dates of birth or exact ages - Government-issued ID numbers (SSN, passport, driver's license, etc.) - Payment or financial information (card numbers, bank accounts, etc.) - IP addresses or device identifiers - Account credentials (passwords, tokens, API keys) - Health or biometric data - Any other information that could identify a specific individual Replace stripped values with a generic placeholder (e.g. "[name]", "[email]", "[address]"). Examples: User: "I want red running shoes under $100" -> "I want red running shoes under $100" User: "Hi, I'm John Smith, [email protected], and I'm looking for flights from Paris to Tokyo for 2 adults departing around mid-June, budget around EUR2000 total" -> "Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000" User: "I need help resetting my password for account ID acct_12345" -> "I need help resetting my password for account ID [account_id]" |
| traveler_counts | object | Traveler counts. Defaults to 1 adult. |
{
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"properties": {
"locale": {
"type": "string",
"description": "User's BCP 47 locale inferred from the conversation (e.g. \"fr-FR\", \"en-US\", \"ja-JP\"). Used for formatting dates, numbers, and selecting currency."
},
"search": {
"anyOf": [
{
"type": "object",
"properties": {
"limit": {
"type": "integer",
"maximum": 300,
"minimum": 1,
"description": "TOTAL number of flights returned (1–300). Caps the whole result set, not a per-page size; it only trims what comes back, since the providers still bound the real count."
},
"origin": {
"type": "string",
"pattern": "^[A-Z]{3}$",
"description": "Origin IATA city code (e.g. PAR, NYC, LON) or airport code (e.g. CDG, JFK, LHR). A city code searches every airport of the city, which is what a user naming a city wants. ALWAYS convert place names to codes yourself before calling (Paris → PAR, Mexico City → MEX, Miami → MIA); a name like \"Paris\" fails validation. See origin_type for how an untyped code is read. Required."
},
"max_price": {
"type": "number",
"description": "Maximum total price for the whole trip and ALL passengers together, in the requested currency. Send the user's whole-trip budget unchanged, or multiply a per-person budget by the number of passengers.",
"exclusiveMinimum": 0
},
"max_stops": {
"type": "integer",
"maximum": 2,
"minimum": 0,
"description": "Maximum stops per leg (0-2). 0 = nonstop — send `max_stops: 0` when the user says \"direct only\" / \"non-stop\" / \"no layovers\"; 1 when the user says \"at most one stop\"."
},
"trip_type": {
"enum": [
"oneway",
"roundtrip"
],
"type": "string",
"description": "Optional. Derived from return_date when omitted."
},
"multi_fare": {
"type": "boolean",
"description": "Defaults to TRUE: several branded fares per itinerary (the upsell ladder). Set false for a single fare per itinerary and much smaller responses."
},
"cabin_class": {
"anyOf": [
{
"enum": [
"economy",
"premium_economy",
"business",
"first"
],
"type": "string"
},
{
"type": "null"
}
],
"description": "Cabin class filter. Use null when the user did not explicitly request a cabin; null or omission lets the provider use economy as its search default without filtering returned fares by cabin. When the user explicitly requests economy, premium economy, business, or first, send that value; results must match it on the longest segment, while shorter segments may use another cabin."
},
"destination": {
"type": "string",
"pattern": "^[A-Z]{3}$",
"description": "Destination IATA city code (e.g. MIL, BCN, TYO) or airport code (e.g. MXP, BCN, NRT). A city code searches every airport of the city, which is what a user naming a city wants. ALWAYS convert place names to codes yourself before calling (Tokyo → TYO, São Paulo → SAO); a name like \"Tokyo\" fails validation. See destination_type for how an untyped code is read — LAX alone is the Los Angeles CITY. Required."
},
"direct_only": {
"type": "boolean",
"description": "DEPRECATED — send `max_stops: 0` instead. Still accepted: `direct_only: true` is folded into `max_stops: 0` before the search runs and only `max_stops` reaches the platform. Setting it beside a non-zero `max_stops` is an error."
},
"origin_type": {
"enum": [
"city",
"airport"
],
"type": "string",
"description": "How to read origin: \"city\" searches every airport of the city; \"airport\" only that one airport. With no type sent, the platform applies one rule: a code that names a multi-airport city is searched as the city; every other code is searched as the airport. NYC, LON, PAR → the city. JFK, LHR, CDG → the airport. LAX, MIA, LAS — codes a city shares with its main airport — → the CITY, every airport of it. If the user named the airport (\"LAX\", \"JFK\", \"Heathrow\"), send \"airport\"; if they named the city (\"Los Angeles\", \"New York\"), send the city code and omit the type. On a live search the provider decides which airports a city holds, so untyped LAX returns flights into other Los Angeles airports — Ontario (ONT) among them, often as the cheapest offers. Each offer reports the airports flown on its legs; the offer-level city code does not change."
},
"return_date": {
"type": "string",
"pattern": "^\\d{4}-\\d{2}-\\d{2}$",
"description": "Single return date (YYYY-MM-DD) for a round trip. Omit for one-way."
},
"via_airports": {
"type": "array",
"items": {
"type": "string",
"pattern": "^[A-Z]{3}$"
},
"description": "Restrict connections to these IATA airport codes. Nonstop itineraries still pass. Example: [\"CDG\",\"AMS\"]. Every connection in a returned itinerary is at a listed airport; sources search at most 9 per leg. Must not overlap exclude_via_airports."
},
"aircraft_types": {
"type": "array",
"items": {
"type": "string",
"pattern": "^[A-Z0-9]{3}$"
},
"description": "Restrict every segment to these IATA aircraft equipment codes. Example: [\"320\",\"321\"]. Use only when the user names equipment; most users do not."
},
"departure_date": {
"type": "string",
"pattern": "^\\d{4}-\\d{2}-\\d{2}$",
"description": "Single departure date (YYYY-MM-DD) — no arrays or ranges. Required."
},
"changeable_only": {
"type": "boolean",
"description": "Keep only fares that allow a voluntary change (with or without a fee). Same conservative behavior as refundable_only. Each returned fare echoes the resolved `changeable` flag."
},
"nearby_airports": {
"type": "boolean",
"description": "Ask the providers to also search alternate airports around each leg's origin and destination. WIDENS the search. Use when the user says \"or any nearby airport\"."
},
"refundable_only": {
"type": "boolean",
"description": "Keep only fares that can be cancelled before departure (with or without a fee). Narrowing and conservative: fares whose rules cannot be verified are dropped, so some carriers disappear entirely. Each returned fare echoes the resolved `refundable` flag."
},
"destination_type": {
"enum": [
"city",
"airport"
],
"type": "string",
"description": "How to read destination: \"city\" searches every airport of the city; \"airport\" only that one airport. With no type sent, the platform applies one rule: a code that names a multi-airport city is searched as the city; every other code is searched as the airport. NYC, LON, PAR → the city. JFK, LHR, CDG → the airport. LAX, MIA, LAS — codes a city shares with its main airport — → the CITY, every airport of it. If the user named the airport (\"LAX\", \"JFK\", \"Heathrow\"), send \"airport\"; if they named the city (\"Los Angeles\", \"New York\"), send the city code and omit the type. On a live search the provider decides which airports a city holds, so untyped LAX returns flights into other Los Angeles airports — Ontario (ONT) among them, often as the cheapest offers. Each offer reports the airports flown on its legs; the offer-level city code does not change."
},
"exclude_carriers": {
"type": "array",
"items": {
"type": "string",
"pattern": "^[A-Z0-9]{2}$"
},
"description": "IATA 2-letter marketing carrier codes to exclude (blacklist). Example: [\"FR\",\"U2\"]. ALWAYS convert airline names to codes yourself (Ryanair → FR, Frontier → F9); a name like \"Ryanair\" fails validation. A brand that operates several marketing carriers needs every code listed (\"no Wizz Air\" → W6, W9). Use when the user says \"no Ryanair\", \"avoid budget airlines\", etc. Must not overlap include_carriers."
},
"include_carriers": {
"type": "array",
"items": {
"type": "string",
"pattern": "^[A-Z0-9]{2}$"
},
"description": "IATA 2-letter marketing carrier codes to include (whitelist). Example: [\"AF\",\"KL\"]. ALWAYS convert airline names to codes yourself (Air France → AF, Delta → DL); a name like \"Delta\" fails validation. A brand that operates several marketing carriers needs every code listed (easyJet → U2, EC, DS). Use when the user says \"Air France only\", \"fly Delta\", etc. Must not overlap exclude_carriers. Matching means EVERY segment is marketed by a listed carrier (codeshares count by marketing carrier). When nothing matches, the search returns no offers with reason no_matches; the platform never widens to other carriers. Tell the user no itinerary satisfied the airline filter and ask which filter to relax."
},
"arrival_time_range": {
"type": "object",
"properties": {
"latest": {
"type": "string",
"pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
"description": "Inclusive latest local time-of-day (HH:MM, 24-hour)."
},
"earliest": {
"type": "string",
"pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
"description": "Inclusive earliest local time-of-day (HH:MM, 24-hour)."
}
},
"description": "Filter the OUTBOUND leg by local arrival time-of-day. Example: { \"latest\": \"20:00\" }. Use when the user says \"arrive before dinner\", \"land by noon\".",
"additionalProperties": false
},
"single_carrier_only": {
"type": "boolean",
"description": "Keep only itineraries marketed by ONE carrier end to end. Use when the user says \"same airline the whole way\" or wants to avoid split-carrier connections."
},
"checked_bag_included": {
"type": "boolean",
"description": "Keep only fares whose price already includes a checked bag. Use when the user says \"with a bag included\", \"I need to check luggage\"."
},
"departure_time_range": {
"type": "object",
"properties": {
"latest": {
"type": "string",
"pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
"description": "Inclusive latest local time-of-day (HH:MM, 24-hour)."
},
"earliest": {
"type": "string",
"pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
"description": "Inclusive earliest local time-of-day (HH:MM, 24-hour)."
}
},
"description": "Filter the OUTBOUND leg by local departure time-of-day. Example: { \"earliest\": \"08:00\", \"latest\": \"12:00\" }. Use when the user says \"morning flight\", \"leave after 6pm\".",
"additionalProperties": false
},
"exclude_via_airports": {
"type": "array",
"items": {
"type": "string",
"pattern": "^[A-Z]{3}$"
},
"description": "Ban connections at these IATA airport codes. Example: [\"LHR\"] when the user says \"anything but Heathrow\". Lists longer than 9 are still fully enforced. Must not overlap via_airports."
},
"same_origin_airport_only": {
"type": "boolean",
"description": "Round trips only: keep itineraries that return to the departure airport."
},
"origin_alternate_airports": {
"type": "array",
"items": {
"type": "string",
"pattern": "^[A-Z]{3}$"
},
"description": "ADDITIONAL departure airports searched ALONGSIDE `origin`, e.g. [\"EWR\",\"LGA\"] with `origin: \"JFK\"`. WIDENING ONLY — the anchor in `origin` is always searched. THE ANCHOR RANKS AND TRUNCATES the result set, so put the airport that matters most to the user in `origin`, not in this list: on one measured route, anchor JFK + alternate EWR came back 15 JFK / 35 EWR, while anchor EWR + alternate JFK came back 2 JFK / 48 EWR. Works with an airport or a city anchor: `origin: \"NYC\"` with [\"BOS\"] searches New York's airports and Boston. On a round trip the whole side is mirrored, so these airports also apply to where the RETURN lands. Some sources search only the anchor."
},
"return_arrival_time_range": {
"type": "object",
"properties": {
"latest": {
"type": "string",
"pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
"description": "Inclusive latest local time-of-day (HH:MM, 24-hour)."
},
"earliest": {
"type": "string",
"pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
"description": "Inclusive earliest local time-of-day (HH:MM, 24-hour)."
}
},
"description": "Round-trip only. Filter the RETURN leg by local arrival time-of-day.",
"additionalProperties": false
},
"max_total_duration_minutes": {
"type": "integer",
"description": "Cap on EACH leg's total elapsed travel time, in minutes (gate to gate, layovers included). Use when the user says \"nothing longer than 12 hours\" → 720.",
"exclusiveMinimum": 0
},
"connection_time_max_minutes": {
"type": "integer",
"minimum": 0,
"description": "Maximum layover length, in minutes, for EVERY connection of EVERY leg. Use when the user says \"no long layovers\" (\"under 3 hours\" → 180)."
},
"connection_time_min_minutes": {
"type": "integer",
"minimum": 0,
"description": "Minimum layover length, in minutes, for EVERY connection of EVERY leg. Use when the user wants a comfortable connection (\"at least 90 minutes to change planes\"). Must not exceed connection_time_max_minutes."
},
"return_departure_time_range": {
"type": "object",
"properties": {
"latest": {
"type": "string",
"pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
"description": "Inclusive latest local time-of-day (HH:MM, 24-hour)."
},
"earliest": {
"type": "string",
"pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
"description": "Inclusive earliest local time-of-day (HH:MM, 24-hour)."
}
},
"description": "Round-trip only. Filter the RETURN leg by local departure time-of-day.",
"additionalProperties": false
},
"same_connection_airport_only": {
"type": "boolean",
"description": "Keep only itineraries whose connections arrive at and depart from the SAME airport (no cross-town airport change)."
},
"same_turnaround_airport_only": {
"type": "boolean",
"description": "Round trips only: keep itineraries whose return departs from the airport the outbound arrived at."
},
"destination_alternate_airports": {
"type": "array",
"items": {
"type": "string",
"pattern": "^[A-Z]{3}$"
},
"description": "ADDITIONAL arrival airports searched ALONGSIDE `destination`, e.g. [\"EWR\",\"LGA\"] with `destination: \"JFK\"`. WIDENING ONLY — the anchor in `destination` is always searched. THE ANCHOR RANKS AND TRUNCATES the result set, so put the airport that matters most to the user in `destination`, not in this list: on one measured route, anchor JFK + alternate EWR came back 15 JFK / 35 EWR, while anchor EWR + alternate JFK came back 2 JFK / 48 EWR. Works with an airport or a city anchor: `destination: \"NYC\"` with [\"BOS\"] searches New York's airports and Boston. On a round trip the whole side is mirrored, so these airports also apply to where the RETURN departs from. Some sources search only the anchor."
}
},
"additionalProperties": false
},
{
"type": "null"
}
],
"description": "Live search for a committed itinerary with optional filters. Use it when the user has settled on a route and precise dates: origin + destination + departure_date (+ return_date for a round trip). No date ranges and no date arrays. Any date flexibility (\"give or take a day\", open windows, an ask with no anchor date at all, or a range implying several candidate departure/return pairs) goes to flight_calendar instead."
},
"trip_id": {
"anyOf": [
{
"type": "string",
"minLength": 1
},
{
"type": "null"
}
],
"description": "Existing trip_id to associate this search with. Forward whenever the user is mid-trip-build (you have seen a trip_id in a recent trip(...) tool result and the user has NOT pivoted to a different trip context, e.g. a new origin city or unrelated request). Drop on pivot. Echoed back in the result so the cart widget can append the next selection to the same trip."
},
"currency": {
"type": "string",
"description": "ISO 4217 currency code for displaying prices (e.g. \"EUR\", \"USD\", \"GBP\", \"JPY\"). ALWAYS set this — omitting it falls back to USD which is rarely what users actually want. Infer from the strongest signal available: (1) the user's explicit ask (\"show me prices in pounds\"), (2) the conversation language/locale (French → EUR, Japanese → JPY, German → EUR, Spanish/Catalan/Italian/Portuguese → EUR, English UK → GBP, English US → USD), (3) the origin city's country (CDG/ORY → EUR, LHR/LGW → GBP, NRT/HND → JPY, JFK/LAX → USD, etc.). When in doubt between two plausible currencies, prefer the one matching the user's likely home country."
},
"price_check": {
"anyOf": [
{
"type": "object",
"required": [
"offer_token"
],
"properties": {
"max_price": {
"type": "number",
"description": "Not applied in price_check (JIN-245); omit even if the upstream call had this filter set. With offer_token present the BFF re-shops closest-match and ignores it, so the candidate can come back above the cap.",
"exclusiveMinimum": 0
},
"cabin_class": {
"enum": [
"economy",
"premium_economy",
"business",
"first"
],
"type": "string",
"description": "Not applied in price_check (JIN-245); omit even if the upstream call had this filter set. With offer_token present the BFF re-shops closest-match and ignores it, so the candidate can come back in a different cabin."
},
"direct_only": {
"type": "boolean",
"description": "Not applied in price_check (JIN-245); omit even if the upstream call had this filter set. With offer_token present the BFF re-shops closest-match and ignores it, so the candidate can come back with a stopover."
},
"offer_token": {
"type": "string",
"minLength": 1,
"description": "offer_token from flight_calendar or find_destination results. Uniquely identifies a specific flight offer for live pricing."
},
"exclude_carriers": {
"type": "array",
"items": {
"type": "string",
"maxLength": 2,
"minLength": 2
},
"description": "IATA 2-letter marketing carrier codes (blacklist). Not applied in price_check (JIN-245); omit even if the upstream call had this filter set."
},
"include_carriers": {
"type": "array",
"items": {
"type": "string",
"maxLength": 2,
"minLength": 2
},
"description": "IATA 2-letter marketing carrier codes (whitelist). Not applied in price_check (JIN-245); omit even if the upstream call had this filter set."
}
},
"additionalProperties": false
},
{
"type": "null"
}
],
"description": "Get confirmed live fares for a specific flight offer. Returns fare brands with trip_item_token for booking. The BFF treats offer_token and the filter fields (direct_only, cabin_class, max_price, include_carriers, exclude_carriers) as MUTUALLY EXCLUSIVE: when offer_token is present it performs a \"closest-match\" re-shop and ignores all five (JIN-245, still open). Omit them here, and do NOT assume the re-shopped candidate still matches what the user picked upstream — compare the returned offer against their stated preference and say so if it differs. The wider shop filters (max_stops, refundable_only, …) belong to `search` only."
},
"user_intent": {
"type": "string",
"description": "A concise summary of what the user is trying to accomplish, derived from their message or the\nconversation context that triggered this tool call.\nThis is used to understand the user's intent and context to improve the overall user experience.\n\n- For short, self-contained prompts (e.g. \"I want new shoes\"), copy the user message as-is.\n- For longer conversations or detailed requests, summarize the core goal and any relevant\n context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full\n dialogue.\n\nBefore sending, strip all personally identifiable information (PII), including but not\nlimited to:\n - Names (first, last, usernames, handles)\n - Email addresses\n - Phone numbers\n - Physical addresses (street, city, zip/postal code, country when tied to an individual)\n - Dates of birth or exact ages\n - Government-issued ID numbers (SSN, passport, driver's license, etc.)\n - Payment or financial information (card numbers, bank accounts, etc.)\n - IP addresses or device identifiers\n - Account credentials (passwords, tokens, API keys)\n - Health or biometric data\n - Any other information that could identify a specific individual\n\nReplace stripped values with a generic placeholder (e.g. \"[name]\", \"[email]\", \"[address]\").\n\nExamples:\n User: \"I want red running shoes under $100\"\n -> \"I want red running shoes under $100\"\n\n User: \"Hi, I'm John Smith, [email protected], and I'm looking for flights from Paris to\n Tokyo for 2 adults departing around mid-June, budget around EUR2000 total\"\n -> \"Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000\"\n\n User: \"I need help resetting my password for account ID acct_12345\"\n -> \"I need help resetting my password for account ID [account_id]\""
},
"traveler_counts": {
"type": "object",
"properties": {
"adults": {
"type": "integer",
"default": 1,
"maximum": 9,
"minimum": 1,
"description": "Number of adult travelers (12+ years)"
},
"infants": {
"type": "integer",
"default": 0,
"maximum": 4,
"minimum": 0,
"description": "Infant travelers (under 2), traveling on an adult's lap. Seated infants (own seat) are not supported."
},
"children": {
"type": "integer",
"default": 0,
"maximum": 8,
"minimum": 0,
"description": "Number of child travelers (2-11 years)"
}
},
"description": "Traveler counts. Defaults to 1 adult.",
"additionalProperties": false
}
},
"additionalProperties": false
}{
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"properties": {
"checkin": {
"type": "string",
"pattern": "^\\d{4}-\\d{2}-\\d{2}$",
"description": "Check-in date (YYYY-MM-DD). Accepted for future cache-key alignment; currently unused by the platform."
},
"checkout": {
"type": "string",
"pattern": "^\\d{4}-\\d{2}-\\d{2}$",
"description": "Check-out date (YYYY-MM-DD). Accepted for future cache-key alignment; currently unused by the platform."
},
"hotel_id": {
"anyOf": [
{
"type": "string",
"minLength": 1
},
{
"type": "null"
}
],
"description": "Legacy hotel_id from hotel_search. Use hotel_ref when available: hotel_ref identifies the hotel unambiguously, hotel_id may not."
},
"hotel_ref": {
"anyOf": [
{
"type": "string",
"minLength": 1
},
{
"type": "null"
}
],
"description": "Provide exactly one of hotel_ref or hotel_id; the other may be null or left out. hotel_ref from hotel_search (preferred): an opaque reference, passed back exactly as returned."
},
"user_intent": {
"type": "string",
"description": "A concise summary of what the user is trying to accomplish, derived from their message or the\nconversation context that triggered this tool call.\nThis is used to understand the user's intent and context to improve the overall user experience.\n\n- For short, self-contained prompts (e.g. \"I want new shoes\"), copy the user message as-is.\n- For longer conversations or detailed requests, summarize the core goal and any relevant\n context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full\n dialogue.\n\nBefore sending, strip all personally identifiable information (PII), including but not\nlimited to:\n - Names (first, last, usernames, handles)\n - Email addresses\n - Phone numbers\n - Physical addresses (street, city, zip/postal code, country when tied to an individual)\n - Dates of birth or exact ages\n - Government-issued ID numbers (SSN, passport, driver's license, etc.)\n - Payment or financial information (card numbers, bank accounts, etc.)\n - IP addresses or device identifiers\n - Account credentials (passwords, tokens, API keys)\n - Health or biometric data\n - Any other information that could identify a specific individual\n\nReplace stripped values with a generic placeholder (e.g. \"[name]\", \"[email]\", \"[address]\").\n\nExamples:\n User: \"I want red running shoes under $100\"\n -> \"I want red running shoes under $100\"\n\n User: \"Hi, I'm John Smith, [email protected], and I'm looking for flights from Paris to\n Tokyo for 2 adults departing around mid-June, budget around EUR2000 total\"\n -> \"Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000\"\n\n User: \"I need help resetting my password for account ID acct_12345\"\n -> \"I need help resetting my password for account ID [account_id]\""
}
},
"additionalProperties": false
}| Argument | Type | Description |
|---|---|---|
| rooms | any | Shorthand: number of rooms (the platform auto-distributes adults + children). Use when the user named a room count but not the per-room split. |
| adults | any | Shorthand: total adults across all rooms. Use ONLY when there is no ambiguity (1 or 2 adults = single room). For 3+ adults, or odd splits, ask the user how they want to split rooms and pass occupancies[] instead — e.g. 4 adults → [{adults:2},{adults:2}] (double + double) vs a single 4-sleeper is a meaningfully different search. If the user does not clarify, the server defaults to 2-adults-per-room (remainder in the last room), so every 4-adult request becomes two double rooms. Do NOT combine with occupancies[] — use one or the other. |
| checkin | any | Check-in date (YYYY-MM-DD). |
| filters | any | Optional filter overrides applied on top of the tenant default filter set. Every property filter is applied as sent. |
| trip_id | any | Existing trip_id to associate this search with. Used only by the Jinko cart widget. The platform accepts the field on every surface for schema consistency; a surface without the widget does not use it. Forward whenever the user is mid-trip-build (you have seen a trip_id in a recent trip(...) tool result and the user has NOT pivoted to a different trip context, e.g. a new origin OR destination city or unrelated request). Drop on pivot. Echoed back in the result so the cart widget can append the next selection to the same trip. |
| checkout | any | Check-out date (YYYY-MM-DD). |
| children | any | Shorthand: ages of all children across all rooms. If children are present, prefer occupancies[] so the caller controls which room each child goes in (ages affect pricing and some providers reject invalid age/room combinations). |
| currency | any | ISO 4217 currency code (e.g. "EUR", "USD", "GBP", "JPY"). ALWAYS set this — omitting it falls back to USD which is rarely what users actually want. Infer from the strongest signal available: (1) the user's explicit ask ("show me prices in pounds"), (2) the conversation language/locale (French → EUR, Japanese → JPY, German → EUR, Spanish/Catalan/Italian/Portuguese → EUR, English UK → GBP, English US → USD), (3) the destination country (Italy/France/Germany → EUR, UK → GBP, Japan → JPY, US → USD). When in doubt between two plausible currencies, prefer the one matching the user's likely home country. |
| destination | any | Destination — provide exactly one shape; unused fields may be null or left out. Two distinct modes: MODE A (rate lookup — you know which hotel): • { hotel_ids } to re-shop a known set. • { hotel_name, country_code?, city_name? } when the user named a specific property. Server resolves via fuzzy lookup; returns 422 HOTEL_NAME_LOW_CONFIDENCE if no candidate scores ≥ 0.7. MODE B (hotel search — you're exploring): • { query } for a natural-language destination. The platform parses it once into city + country or coordinates and never forwards the raw query to a supplier. • { city_name + country_code } for ambiguous city names or when the user named a primary city ("Mahón, ES" for Menorca). • { latitude + longitude + radius_km } when exact coordinates and an area radius are already known. In Mode A, property filters (min_rating / star / min_reviews / facility / chain / hotel_type) cannot be combined with hotel_name / hotel_ids: the request is rejected — the user already named the property. filters.max_budget_per_night applies with hotel_ids or hotel_name. |
| next_handle | any | Opaque continuation handle returned by a prior hotel_search. Send this field by itself, or with every other field null. A first request needs destination, checkin and checkout. |
| occupancies | any | One entry per room (structured). PREFERRED whenever the party is larger than 2 adults or has children — it removes ambiguity about how guests are split across rooms. Example: [{ "adults": 2 }, { "adults": 1, "children_ages": [5] }]. Do NOT combine with the shorthand fields (adults/children/rooms) — use one or the other. |
| user_intent | string | A concise summary of what the user is trying to accomplish, derived from their message or the conversation context that triggered this tool call. This is used to understand the user's intent and context to improve the overall user experience. - For short, self-contained prompts (e.g. "I want new shoes"), copy the user message as-is. - For longer conversations or detailed requests, summarize the core goal and any relevant context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full dialogue. Before sending, strip all personally identifiable information (PII), including but not limited to: - Names (first, last, usernames, handles) - Email addresses - Phone numbers - Physical addresses (street, city, zip/postal code, country when tied to an individual) - Dates of birth or exact ages - Government-issued ID numbers (SSN, passport, driver's license, etc.) - Payment or financial information (card numbers, bank accounts, etc.) - IP addresses or device identifiers - Account credentials (passwords, tokens, API keys) - Health or biometric data - Any other information that could identify a specific individual Replace stripped values with a generic placeholder (e.g. "[name]", "[email]", "[address]"). Examples: User: "I want red running shoes under $100" -> "I want red running shoes under $100" User: "Hi, I'm John Smith, [email protected], and I'm looking for flights from Paris to Tokyo for 2 adults departing around mid-June, budget around EUR2000 total" -> "Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000" User: "I need help resetting my password for account ID acct_12345" -> "I need help resetting my password for account ID [account_id]" |
| guest_nationality | any | Guest nationality (ISO 3166-1 alpha-2, uppercase, e.g. "FR"). Affects rate availability + tax handling at search time. Separate from traveler nationality used for booking documents. |
{
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"properties": {
"rooms": {
"anyOf": [
{
"type": "integer",
"maximum": 8,
"minimum": 1
},
{
"type": "null"
}
],
"description": "Shorthand: number of rooms (the platform auto-distributes adults + children). Use when the user named a room count but not the per-room split."
},
"adults": {
"anyOf": [
{
"type": "integer",
"maximum": 16,
"minimum": 1
},
{
"type": "null"
}
],
"description": "Shorthand: total adults across all rooms. Use ONLY when there is no ambiguity (1 or 2 adults = single room). For 3+ adults, or odd splits, ask the user how they want to split rooms and pass occupancies[] instead — e.g. 4 adults → [{adults:2},{adults:2}] (double + double) vs a single 4-sleeper is a meaningfully different search. If the user does not clarify, the server defaults to 2-adults-per-room (remainder in the last room), so every 4-adult request becomes two double rooms. Do NOT combine with occupancies[] — use one or the other."
},
"checkin": {
"anyOf": [
{
"type": "string",
"pattern": "^\\d{4}-\\d{2}-\\d{2}$"
},
{
"type": "null"
}
],
"description": "Check-in date (YYYY-MM-DD)."
},
"filters": {
"anyOf": [
{
"type": "object",
"properties": {
"offset": {
"type": "integer",
"minimum": 0,
"description": "Skip this many hotels (default 0). Rejected once a search returned search_handle / next_handle: page with next_handle instead."
},
"chain_ids": {
"type": "array",
"items": {
"type": "string",
"minLength": 1
},
"description": "Filter by hotel chain. Each entry is a brand slug (e.g. \"accor\", \"hilton\") OR a numeric chain id. Slugs are expanded to all sub-brands (e.g. \"accor\" → Accor, ibis, Novotel, Mercure, Pullman, Sofitel, …). Every entry is applied as sent: one that matches no chain is rejected with a validation error."
},
"min_rating": {
"anyOf": [
{
"type": "number",
"maximum": 10,
"minimum": 0
},
{
"type": "null"
}
],
"description": "Minimum guest review rating (0-10 scale). Omitted or 0: no rating floor, unrated hotels included."
},
"max_results": {
"type": "integer",
"maximum": 200,
"minimum": 1,
"description": "Requested page size (default 50); next_handle returns the next page of the same search. A hotel_name or hotel_ids search returns every named hotel that has rates."
},
"min_reviews": {
"anyOf": [
{
"type": "integer",
"minimum": 0
},
{
"type": "null"
}
],
"description": "Minimum number of guest reviews."
},
"facility_ids": {
"type": "array",
"items": {
"type": "string",
"minLength": 1
},
"description": "Filter by hotel facility, applied at platform search time, not post-filtered. Each entry is one of these names (or a numeric facility id): pool, outdoor_pool, indoor_pool, rooftop_pool, infinity_pool, heated_pool, kids_pool, spa, sauna, hot_tub, hammam, gym, parking, free_parking, valet_parking, ev_charging, wifi, free_wifi, restaurant, bar, room_service, airport_shuttle, pets_allowed, family_rooms, air_conditioning, wheelchair_accessible, elevator, 24h_front_desk, beachfront, private_beach, adults_only, kids_club, water_park, golf_course, tennis_court, casino, terrace, garden, non_smoking_rooms, laundry, concierge, business_center, meeting_rooms, shared_kitchen, luggage_storage. For a facility the user requires, send that ONE name: with several entries the standard search keeps hotels having at least one of them, not all. These are hotel-level facilities — breakfast is a rate board type, and sea view, balcony or a private kitchen are room features, none of which can be filtered here. A name outside the list is rejected with the accepted names."
},
"hotel_type_ids": {
"type": "array",
"items": {
"type": "string",
"minLength": 1
},
"description": "Filter by property type. Each entry is one of these names (or a numeric type id): hotel, apartment, aparthotel, resort, hostel, guesthouse, bed_and_breakfast, inn, ryokan, riad, villa, chalet, cottage, cabin, lodge, holiday_home, country_house, farm_stay, homestay, condo, residence, motel, campsite, luxury_tent, holiday_park, houseboat. Several entries keep properties of ANY of those types. \"boutique\", \"luxury\" or \"romantic\" are styles, not types, and cannot be filtered here. A name outside the list is rejected with the accepted names."
},
"max_star_rating": {
"anyOf": [
{
"type": "integer",
"maximum": 5,
"minimum": 1
},
{
"type": "null"
}
],
"description": "Maximum star rating (1-5). Pair with min_star_rating to bound a range."
},
"min_star_rating": {
"anyOf": [
{
"type": "integer",
"maximum": 5,
"minimum": 1
},
{
"type": "null"
}
],
"description": "Minimum star rating (1-5). Pair with max_star_rating to bound a range."
},
"max_budget_per_night": {
"anyOf": [
{
"type": "number",
"exclusiveMinimum": 0
},
{
"type": "null"
}
],
"description": "Keep only hotels whose CHEAPEST per-night price (per room, in the request currency) fits this budget; qualifying hotels keep all their rates. Also applies in Mode A (rate lookup)."
}
},
"additionalProperties": false
},
{
"type": "null"
}
],
"description": "Optional filter overrides applied on top of the tenant default filter set. Every property filter is applied as sent."
},
"trip_id": {
"anyOf": [
{
"type": "string",
"minLength": 1
},
{
"type": "null"
}
],
"description": "Existing trip_id to associate this search with. Used only by the Jinko cart widget. The platform accepts the field on every surface for schema consistency; a surface without the widget does not use it. Forward whenever the user is mid-trip-build (you have seen a trip_id in a recent trip(...) tool result and the user has NOT pivoted to a different trip context, e.g. a new origin OR destination city or unrelated request). Drop on pivot. Echoed back in the result so the cart widget can append the next selection to the same trip."
},
"checkout": {
"anyOf": [
{
"$ref": "#/properties/checkin/anyOf/0"
},
{
"type": "null"
}
],
"description": "Check-out date (YYYY-MM-DD)."
},
"children": {
"anyOf": [
{
"type": "array",
"items": {
"type": "integer",
"maximum": 17,
"minimum": 0
},
"maxItems": 8
},
{
"type": "null"
}
],
"description": "Shorthand: ages of all children across all rooms. If children are present, prefer occupancies[] so the caller controls which room each child goes in (ages affect pricing and some providers reject invalid age/room combinations)."
},
"currency": {
"anyOf": [
{
"type": "string",
"maxLength": 3,
"minLength": 3
},
{
"type": "null"
}
],
"description": "ISO 4217 currency code (e.g. \"EUR\", \"USD\", \"GBP\", \"JPY\"). ALWAYS set this — omitting it falls back to USD which is rarely what users actually want. Infer from the strongest signal available: (1) the user's explicit ask (\"show me prices in pounds\"), (2) the conversation language/locale (French → EUR, Japanese → JPY, German → EUR, Spanish/Catalan/Italian/Portuguese → EUR, English UK → GBP, English US → USD), (3) the destination country (Italy/France/Germany → EUR, UK → GBP, Japan → JPY, US → USD). When in doubt between two plausible currencies, prefer the one matching the user's likely home country."
},
"destination": {
"anyOf": [
{
"type": "object",
"properties": {
"query": {
"anyOf": [
{
"type": "string",
"maxLength": 200,
"minLength": 1
},
{
"type": "null"
}
],
"description": "Free-text destination (for example \"Paris\", \"Times Square\", \"Menorca\" or \"Tuscany\"). The platform parses it once into a city + country or coordinates, then applies the same shared location normalization as structured inputs; the raw query is not forwarded to a supplier. Max 200 chars."
},
"latitude": {
"anyOf": [
{
"type": "number",
"maximum": 90,
"minimum": -90
},
{
"type": "null"
}
],
"description": "Latitude for geo-radius search. Pair with longitude."
},
"city_name": {
"anyOf": [
{
"type": "string",
"minLength": 1
},
{
"type": "null"
}
],
"description": "City name (e.g. \"Paris\"). Spell it the way an English-language booking site would: \"Munich\" not \"München\", \"Florence\" not \"Firenze\", \"Rome\" not \"Roma\", \"Vienna\" not \"Wien\". Keep the local form where that IS the international one (\"Regensburg\", \"Livorno\", \"Nürnberg\", \"Lyon\"), and never an archaic exonym (\"Leghorn\", \"Ratisbon\"). The catalog stores one group per spelling and does not fold translations, so the wrong form usually resolves to a near-empty group instead of failing — see destination_resolution.catalog_hotel_count. Case, accents and hyphens ARE folded (\"Mahon\" = \"Mahón\", \"Saint Malo\" = \"Saint-Malo\"), so those need no correction. In Mode B: pair with country_code as the destination. In Mode A (with hotel_name): pair with hotel_name to narrow the fuzzy-lookup scope."
},
"hotel_ids": {
"anyOf": [
{
"type": "array",
"items": {
"type": "string",
"minLength": 1
},
"minItems": 1
},
{
"type": "null"
}
],
"description": "Mode A — re-shop a known set of hotel IDs (skips destination resolution)."
},
"longitude": {
"anyOf": [
{
"type": "number",
"maximum": 180,
"minimum": -180
},
{
"type": "null"
}
],
"description": "Longitude for geo-radius search. Pair with latitude."
},
"radius_km": {
"anyOf": [
{
"type": "number",
"maximum": 50,
"exclusiveMinimum": 0
},
{
"type": "null"
}
],
"description": "Geo-radius in km (default 20 for explicit coordinates, max 50). Requires latitude+longitude."
},
"hotel_name": {
"anyOf": [
{
"type": "string",
"maxLength": 120,
"minLength": 2
},
{
"type": "null"
}
],
"description": "Mode A — free-text hotel name when the user named a specific property they want to book (e.g. \"Hotel Calimala\", \"The St. Regis Rome\", \"Hôtel Costes\"). Server runs a fuzzy trigram match over the 1.74M-hotel catalog; uses the top hit when its confidence is ≥ 0.7 (auto-pick safe). If no candidate clears that threshold, returns HTTP 422 with error.code = HOTEL_NAME_LOW_CONFIDENCE + top_candidates + suggested_retry — the agent should confirm a candidate with the user or fall back to the suggested city destination. ALWAYS pair with country_code and city_name when known; lookup precision drops sharply on common names without scope."
},
"country_code": {
"anyOf": [
{
"type": "string",
"maxLength": 2,
"minLength": 2
},
{
"type": "null"
}
],
"description": "ISO 3166-1 alpha-2 country code (lowercase preferred, e.g. \"fr\"). Must be paired with city_name OR hotel_name. In Mode B it disambiguates the city; in Mode A it narrows the fuzzy lookup."
}
},
"description": "Destination — provide exactly one shape; unused fields may be null or left out. Two distinct modes:\n\nMODE A (rate lookup — you know which hotel):\n • { hotel_ids } to re-shop a known set.\n • { hotel_name, country_code?, city_name? } when the user named a specific property. Server resolves via fuzzy lookup; returns 422 HOTEL_NAME_LOW_CONFIDENCE if no candidate scores ≥ 0.7.\n\nMODE B (hotel search — you're exploring):\n • { query } for a natural-language destination. The platform parses it once into city + country or coordinates and never forwards the raw query to a supplier.\n • { city_name + country_code } for ambiguous city names or when the user named a primary city (\"Mahón, ES\" for Menorca).\n • { latitude + longitude + radius_km } when exact coordinates and an area radius are already known.\nIn Mode A, property filters (min_rating / star / min_reviews / facility / chain / hotel_type) cannot be combined with hotel_name / hotel_ids: the request is rejected — the user already named the property. filters.max_budget_per_night applies with hotel_ids or hotel_name.",
"additionalProperties": false
},
{
"type": "null"
}
],
"description": "Destination — provide exactly one shape; unused fields may be null or left out. Two distinct modes:\n\nMODE A (rate lookup — you know which hotel):\n • { hotel_ids } to re-shop a known set.\n • { hotel_name, country_code?, city_name? } when the user named a specific property. Server resolves via fuzzy lookup; returns 422 HOTEL_NAME_LOW_CONFIDENCE if no candidate scores ≥ 0.7.\n\nMODE B (hotel search — you're exploring):\n • { query } for a natural-language destination. The platform parses it once into city + country or coordinates and never forwards the raw query to a supplier.\n • { city_name + country_code } for ambiguous city names or when the user named a primary city (\"Mahón, ES\" for Menorca).\n • { latitude + longitude + radius_km } when exact coordinates and an area radius are already known.\nIn Mode A, property filters (min_rating / star / min_reviews / facility / chain / hotel_type) cannot be combined with hotel_name / hotel_ids: the request is rejected — the user already named the property. filters.max_budget_per_night applies with hotel_ids or hotel_name."
},
"next_handle": {
"anyOf": [
{
"type": "string",
"minLength": 1
},
{
"type": "null"
}
],
"description": "Opaque continuation handle returned by a prior hotel_search. Send this field by itself, or with every other field null. A first request needs destination, checkin and checkout."
},
"occupancies": {
"anyOf": [
{
"type": "array",
"items": {
"type": "object",
"required": [
"adults"
],
"properties": {
"adults": {
"type": "integer",
"maximum": 8,
"minimum": 1,
"description": "Adult travelers in this room (12+)."
},
"children_ages": {
"type": "array",
"items": {
"type": "integer",
"maximum": 17,
"minimum": 0
},
"maxItems": 6,
"description": "Ages of children in this room (0-17). Required for child pricing."
}
},
"additionalProperties": false
},
"maxItems": 8,
"minItems": 1
},
{
"type": "null"
}
],
"description": "One entry per room (structured). PREFERRED whenever the party is larger than 2 adults or has children — it removes ambiguity about how guests are split across rooms. Example: [{ \"adults\": 2 }, { \"adults\": 1, \"children_ages\": [5] }]. Do NOT combine with the shorthand fields (adults/children/rooms) — use one or the other."
},
"user_intent": {
"type": "string",
"description": "A concise summary of what the user is trying to accomplish, derived from their message or the\nconversation context that triggered this tool call.\nThis is used to understand the user's intent and context to improve the overall user experience.\n\n- For short, self-contained prompts (e.g. \"I want new shoes\"), copy the user message as-is.\n- For longer conversations or detailed requests, summarize the core goal and any relevant\n context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full\n dialogue.\n\nBefore sending, strip all personally identifiable information (PII), including but not\nlimited to:\n - Names (first, last, usernames, handles)\n - Email addresses\n - Phone numbers\n - Physical addresses (street, city, zip/postal code, country when tied to an individual)\n - Dates of birth or exact ages\n - Government-issued ID numbers (SSN, passport, driver's license, etc.)\n - Payment or financial information (card numbers, bank accounts, etc.)\n - IP addresses or device identifiers\n - Account credentials (passwords, tokens, API keys)\n - Health or biometric data\n - Any other information that could identify a specific individual\n\nReplace stripped values with a generic placeholder (e.g. \"[name]\", \"[email]\", \"[address]\").\n\nExamples:\n User: \"I want red running shoes under $100\"\n -> \"I want red running shoes under $100\"\n\n User: \"Hi, I'm John Smith, [email protected], and I'm looking for flights from Paris to\n Tokyo for 2 adults departing around mid-June, budget around EUR2000 total\"\n -> \"Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000\"\n\n User: \"I need help resetting my password for account ID acct_12345\"\n -> \"I need help resetting my password for account ID [account_id]\""
},
"guest_nationality": {
"anyOf": [
{
"type": "string",
"maxLength": 2,
"minLength": 2
},
{
"type": "null"
}
],
"description": "Guest nationality (ISO 3166-1 alpha-2, uppercase, e.g. \"FR\"). Affects rate availability + tax handling at search time. Separate from traveler nationality used for booking documents."
}
},
"additionalProperties": false
}| Argument | Type | Description |
|---|---|---|
| trip_id | string | null | ID of an existing trip. If not provided, a new trip will be created. |
| version | any | Deprecated legacy widget field. Accepted and ignored for compatibility; it does not provide optimistic concurrency. |
| add_item | any | Add a flight or hotel to the trip. Use trip_item_token from flight_search (offer__* format) or offer_id from hotel_search (htl_* format). For MULTIPLE ROOMS of the same hotel stay, make ONE add_item call with the rooms array (2–8 htl_* tokens, same hotel + dates) — do NOT add the same hotel as separate items. |
| offer_id | string | null | Deprecated: offer_id is now encoded into trip_item_token by flight_search. Only needed for legacy tokens without encoded offer_id. |
| remove_item | any | Remove an item from the trip by its ID. |
| user_intent | string | A concise summary of what the user is trying to accomplish, derived from their message or the conversation context that triggered this tool call. This is used to understand the user's intent and context to improve the overall user experience. - For short, self-contained prompts (e.g. "I want new shoes"), copy the user message as-is. - For longer conversations or detailed requests, summarize the core goal and any relevant context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full dialogue. Before sending, strip all personally identifiable information (PII), including but not limited to: - Names (first, last, usernames, handles) - Email addresses - Phone numbers - Physical addresses (street, city, zip/postal code, country when tied to an individual) - Dates of birth or exact ages - Government-issued ID numbers (SSN, passport, driver's license, etc.) - Payment or financial information (card numbers, bank accounts, etc.) - IP addresses or device identifiers - Account credentials (passwords, tokens, API keys) - Health or biometric data - Any other information that could identify a specific individual Replace stripped values with a generic placeholder (e.g. "[name]", "[email]", "[address]"). Examples: User: "I want red running shoes under $100" -> "I want red running shoes under $100" User: "Hi, I'm John Smith, [email protected], and I'm looking for flights from Paris to Tokyo for 2 adults departing around mid-June, budget around EUR2000 total" -> "Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000" User: "I need help resetting my password for account ID acct_12345" -> "I need help resetting my password for account ID [account_id]" |
| payment_type | string | Payment flow type: "checkout" for Stripe Checkout (default), "intent" for Payment Intent. |
| schedule_quote | boolean | Schedule a fresh quote on the current cart state. Triggers async re-pricing on the BFF; poll trip(get) until trip.quote_status is "completed", "partial", or "failed". Only "completed" covers the whole cart. trip.quoted_total is the quoted sell total; trip.totals includes unquoted search prices, and trip.status is a legacy lifecycle field. Call this AFTER any traveler or cart-composition change so subsequent steps see fresh prices. book(create) will silently re-quote if the cart drifted from the last quote. |
| idempotency_key | string | null | Idempotency key to prevent duplicate processing |
| upsert_travelers | any | Set travelers on the trip. Replaces all existing travelers (idempotent operation). |
{
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"properties": {
"trip_id": {
"type": [
"string",
"null"
],
"description": "ID of an existing trip. If not provided, a new trip will be created."
},
"version": {
"description": "Deprecated legacy widget field. Accepted and ignored for compatibility; it does not provide optimistic concurrency."
},
"add_item": {
"anyOf": [
{
"type": "object",
"properties": {
"rooms": {
"anyOf": [
{
"type": "array",
"items": {
"type": "object",
"required": [
"trip_item_token"
],
"properties": {
"traveler_ids": {
"type": "array",
"items": {
"type": "string"
},
"description": "Optional traveler IDs occupying this specific room."
},
"trip_item_token": {
"type": "string",
"minLength": 1,
"description": "Hotel rate token (htl_*) from hotel_search for THIS room. All rooms in the array must come from the same hotel and the same stay (same check-in/check-out dates) — typically one rate per requested occupancy from the same hotel_search response."
}
},
"additionalProperties": false
}
},
{
"type": "null"
}
],
"description": "MULTI-ROOM HOTEL ONLY: book 2–8 rooms of the SAME hotel and SAME stay as ONE booking with ONE reference. One entry per room, each with its own htl_* rate token from hotel_search (e.g. one rate per occupancy). All tokens must belong to the same hotel and identical check-in/check-out dates. Mutually exclusive with trip_item_token; for a single room use trip_item_token instead. Not every hotel rate can be booked this way; one that cannot is refused when it is added."
},
"traveler_ids": {
"type": "array",
"items": {
"type": "string"
},
"description": "Traveler IDs to associate with the added item"
},
"trip_item_token": {
"type": [
"string",
"null"
],
"description": "Token from flight_search fare options. Contains encoded flight/fare information. Mutually exclusive with rooms — provide exactly one of the two; the unused one may be null or left out."
},
"special_requests": {
"type": "array",
"items": {
"type": "string",
"maxLength": 500
},
"maxItems": 10,
"description": "HOTEL ONLY. Free-text special requests for the property, one per entry — e.g. \"Expected arrival around 11:30 PM\", \"Quiet room on a high floor, if available\", \"Baby cot requested\", \"Non-smoking room\". Forwarded to the hotel supplier with the booking as REQUESTS ONLY: neither Jinko nor the hotel guarantees them, and a confirmed booking does not mean they will be honoured — tell the user so. Applies to the whole stay (every room). At most 10 entries of 500 characters each and 1500 characters in total; blank entries are dropped. Ignored on any item that is not a hotel."
}
},
"additionalProperties": false
},
{
"type": "null"
}
],
"description": "Add a flight or hotel to the trip. Use trip_item_token from flight_search (offer__* format) or offer_id from hotel_search (htl_* format). For MULTIPLE ROOMS of the same hotel stay, make ONE add_item call with the rooms array (2–8 htl_* tokens, same hotel + dates) — do NOT add the same hotel as separate items."
},
"offer_id": {
"type": [
"string",
"null"
],
"description": "Deprecated: offer_id is now encoded into trip_item_token by flight_search. Only needed for legacy tokens without encoded offer_id."
},
"remove_item": {
"anyOf": [
{
"type": "object",
"required": [
"item_id"
],
"properties": {
"item_id": {
"type": "string",
"description": "ID of the trip item to remove. Get this from trip.trip_items[].id"
}
},
"additionalProperties": false
},
{
"type": "null"
}
],
"description": "Remove an item from the trip by its ID."
},
"user_intent": {
"type": "string",
"description": "A concise summary of what the user is trying to accomplish, derived from their message or the\nconversation context that triggered this tool call.\nThis is used to understand the user's intent and context to improve the overall user experience.\n\n- For short, self-contained prompts (e.g. \"I want new shoes\"), copy the user message as-is.\n- For longer conversations or detailed requests, summarize the core goal and any relevant\n context in 1-2 sentences. Focus on intent, constraints, and preferences - not the full\n dialogue.\n\nBefore sending, strip all personally identifiable information (PII), including but not\nlimited to:\n - Names (first, last, usernames, handles)\n - Email addresses\n - Phone numbers\n - Physical addresses (street, city, zip/postal code, country when tied to an individual)\n - Dates of birth or exact ages\n - Government-issued ID numbers (SSN, passport, driver's license, etc.)\n - Payment or financial information (card numbers, bank accounts, etc.)\n - IP addresses or device identifiers\n - Account credentials (passwords, tokens, API keys)\n - Health or biometric data\n - Any other information that could identify a specific individual\n\nReplace stripped values with a generic placeholder (e.g. \"[name]\", \"[email]\", \"[address]\").\n\nExamples:\n User: \"I want red running shoes under $100\"\n -> \"I want red running shoes under $100\"\n\n User: \"Hi, I'm John Smith, [email protected], and I'm looking for flights from Paris to\n Tokyo for 2 adults departing around mid-June, budget around EUR2000 total\"\n -> \"Looking for flights from Paris to Tokyo for 2 adults, mid-June, budget ~EUR2000\"\n\n User: \"I need help resetting my password for account ID acct_12345\"\n -> \"I need help resetting my password for account ID [account_id]\""
},
"payment_type": {
"enum": [
"checkout",
"intent"
],
"type": "string",
"description": "Payment flow type: \"checkout\" for Stripe Checkout (default), \"intent\" for Payment Intent."
},
"schedule_quote": {
"type": "boolean",
"description": "Schedule a fresh quote on the current cart state. Triggers async re-pricing on the BFF; poll trip(get) until trip.quote_status is \"completed\", \"partial\", or \"failed\". Only \"completed\" covers the whole cart. trip.quoted_total is the quoted sell total; trip.totals includes unquoted search prices, and trip.status is a legacy lifecycle field. Call this AFTER any traveler or cart-composition change so subsequent steps see fresh prices. book(create) will silently re-quote if the cart drifted from the last quote."
},
"idempotency_key": {
"type": [
"string",
"null"
],
"description": "Idempotency key to prevent duplicate processing"
},
"upsert_travelers": {
"anyOf": [
{
"type": "object",
"required": [
"travelers"
],
"properties": {
"contact": {
"anyOf": [
{
"type": "object",
"required": [
"email",
"phone"
],
"properties": {
"city": {
"type": [
"string",
"null"
],
"description": "Billing city. Required by some carriers."
},
"email": {
"type": "string",
"format": "email",
"description": "Email address for booking confirmations"
},
"phone": {
"type": "string",
"description": "Phone number in international format: a leading + and the country code, e.g. \"+12025550147\". Spaces, hyphens, dots and parentheses are tolerated and removed. A number without the leading + is rejected with INVALID_PHONE_NUMBER."
},
"title": {
"type": [
"string",
"null"
],
"description": "Title of the person paying (e.g. \"mr\", \"ms\", \"mx\"). Required by some carriers."
},
"zip_code": {
"type": [
"string",
"null"
],
"description": "Billing postal code. Required by some carriers."
},
"country_code": {
"type": [
"string",
"null"
],
"description": "Billing country as an ISO 3166-1 alpha-2 code (e.g. \"FR\")."
},
"terms_accepted": {
"type": "boolean",
"description": "Whether the traveller accepted the CARRIER's terms and conditions, which are separate from Jinko's. Send true only if they were actually shown and accepted."
},
"street_and_number": {
"type": [
"string",
"null"
],
"description": "Billing street and number. Required by some carriers."
}
},
"additionalProperties": false
},
{
"type": "null"
}
],
"description": "Contact for the trip lead (email + phone). Optional while building the cart, but required before booking — the connectors reject bookings without a contact phone."
},
"travelers": {
"type": "array",
"items": {
"type": "object",
"properties": {
"contact": {
"anyOf": [
{
"type": "object",
"properties": {
"email": {
"anyOf": [
{
"type": "string",
"format": "email"
},
{
"type": "null"
}
],
"description": "Email address"
},
"phone": {
"type": [
"string",
"null"
],
"description": "Phone number in international format: a leading + and the country code, e.g. \"+12025550147\". Spaces, hyphens, dots and parentheses are tolerated and removed. A number without the leading + is rejected with INVALID_PHONE_NUMBER."
}
},
"additionalProperties": false
},
{
"type": "null"
}
],
"description": "Contact information"
},
"is_lead": {
"type": "boolean",
"description": "Whether this traveler is the lead/primary contact"
},
"identity": {
"anyOf": [
{
"type": "object",
"required": [
"first_name",
"last_name",
"passenger_type"
],
"properties": {
"title": {
"type": [
"string",
"null"
],
"description": "Title (Mr, Mrs, Ms, etc.)"
},
"gender": {
"anyOf": [
{
"enum": [
"MALE",
"FEMALE"
],
"type": "string"
},
{
"type": "null"
}
],
"description": "Gender. Required for flights; optional for hotel-only bookings."
},
"last_name": {
"type": "string",
"description": "Last name as on travel documents"
},
"first_name": {
"type": "string",
"description": "First name as on travel documents"
},
"middle_name": {
"type": [
"string",
"null"
],
"description": "Middle name"
},
"nationality": {
"type": [
"string",
"null"
],
"description": "Nationality (ISO 3166-1 alpha-2 country code)"
},
"date_of_birth": {
"type": [
"string",
"null"
],
"description": "Date of birth (YYYY-MM-DD). Required for flights, and for a CHILD or infant (LAP_INFANT, SEATED_INFANT) staying at a hotel; optional for an adult on a hotel-only booking."
},
"frequent_flyer": {
"anyOf": [
{
"type": "object",
"required": [
"airline",
"number"
],
"properties": {
"number": {
"type": "string"
},
"airline": {
"type": "string"
}
},
"additionalProperties": false
},
{
"type": "null"
}
],
"description": "Frequent-flyer / loyalty membership. airline = IATA carrier that issued the membership (e.g. LH); number = membership number."
},
"passenger_type": {
"enum": [
"ADULT",
"CHILD",
"LAP_INFANT",
"SEATED_INFANT"
],
"type": "string",
"description": "Passenger type based on age. SEATED_INFANT is not currently supported for flights — bookings with it are rejected; book infants as LAP_INFANT."
},
"redress_number": {
"type": [
"string",
"null"
],
"description": "DHS redress control number (TRIP program). Flights only."
},
"known_traveler_number": {
"type": [
"string",
"null"
],
"description": "US trusted-traveler Known Traveler Number (TSA PreCheck / Global Entry). Flights only; sent to the airline as Secure Flight data so PreCheck prints on the boarding pass."
},
"redress_issuing_country": {
"type": [
"string",
"null"
],
"description": "ISO 3166-1 alpha-2 country that issued the redress number. Defaults to US downstream; ignored without redress_number."
},
"known_traveler_issuing_country": {
"type": [
"string",
"null"
],
"description": "ISO 3166-1 alpha-2 country that issued the Known Traveler Number. Defaults to US downstream; ignored without known_traveler_number."
}
},
"additionalProperties": false
},
{
"type": "null"
}
],
"description": "Traveler identity information. Required if traveler_id is not provided."
},
"passport": {
"anyOf": [
{
"type": "object",
"required": [
"number",
"expiry_date",
"issuing_country"
],
"properties": {
"type": {
"type": [
"string",
"null"
],
"description": "Document type in the CARRIER's vocabulary, when the booking requires one (carriers list it in required_customer_details as government_id_type; values are carrier-specific, e.g. \"passport_id\", \"international_passport\", \"national_id\"). Omit unless asked."
},
"number": {
"type": "string",
"description": "Passport number"
},
"expiry_date": {
"type": "string",
"description": "Passport expiration date (YYYY-MM-DD)"
},
"issuing_country": {
"type": "string",
"description": "Issuing country (ISO 3166-1 alpha-2 code)"
}
},
"additionalProperties": false
},
{
"type": "null"
}
],
"description": "Passport information for international travel"
},
"traveler_id": {
"type": [
"string",
"null"
],
"description": "ID of a pre-saved traveler. If provided, fetches traveler details from storage."
}
},
"additionalProperties": false
},
"description": "List of travelers for the trip. Replaces all existing travelers (idempotent). Required to complete a booking; the first traveler also supplies the booking contact name."
}
},
"additionalProperties": false
},
{
"type": "null"
}
],
"description": "Set travelers on the trip. Replaces all existing travelers (idempotent operation)."
}
},
"additionalProperties": false
}