Connection check
verified live · 20h ago
jinko
Turn your ChatGPT to a super travel agent
Tools
7
GitHub stars
—
Installs / wk
—
Licence
—
Transport
streamable-http, sse
Last checked
20h ago
Tools & capabilities
7 toolsRead from the running server on 20h ago.
book
can modify data
createstatususer_intentidempotency_key
Unified tool for booking a trip. Actions are determined by which object you provide. SCHEMA: { create?: { // Initiate booking trip_id: string,… 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" }, "pending_booking": { "id": "bkg_xxx", "status": "awaiting_payment", "trip_id": "trip_xxx" } } 2. CHECK STATUS (status object): Retrieves booking status. If payment is authorized but fulfillment hasn't started, automatically triggers fulfillment. { "status": { "booking_id": "bkg_xxx" } } Returns: Full booking object with status, items, passengers, totals, payment info. 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": "+1-555-123-4567" } } } 3. Check booking status: { "status": { "booking_id": "bkg_xxx" } } **Cost: 1 credit per call.**
find_destination
read-only
localeorigins*sort_bycurrencymax_pricestay_days
+10
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 desti… 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", "LAX", "LHR"] - searches specific airports - City codes: ["NYC", "LON", "PAR"] - searches all airports in those cities 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. **Cost: 1 credit per call.**
flight_calendar
read-only
localeorigin*sort_bycurrencymax_pricestay_days
+14
Search flights between a known origin and destination using cached pricing. Use this tool whenever the user specifies BOTH where they are flying FROM and where they are flying TO.… Search flights between a known origin and destination using cached pricing. Use this tool whenever the user specifies BOTH where they are flying FROM and where they are flying TO. 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 has committed to EXACT dates — both a single departure date AND a single return date for one specific route. - Example: "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 only once route + both dates are locked in. - **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. Please fill as much as possible search parameters based on user intent to get best results. Origin and destination must be IATA city code by default except if the user specifies IATA Airport code in the search. 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 + 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. **Cost: 1 credit per call.**
flight_search
read-only
localesearchtrip_idcurrencyprice_checkuser_intent
+1
Live flight tool with two modes. 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… Live flight tool with two modes. 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). - Supports the full shop filter set on the same call: trip_type, max_stops, cabin_class, max_price, 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" } } ✓ "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 only some of them. 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. 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 THE PROVIDER COULD NOT APPLY: - The result carries applied_filters and unapplied_filters. Anything listed in unapplied_filters was NOT enforced — the flights shown are not narrowed by it, so tell the user rather than implying the constraint held. - Both lists name a leg SIDE in the report, not the field you sent: an origin_alternate_airports / destination_alternate_airports list that was (or was not) honoured is reported as "origin" / "destination". - origin_alternate_airports / destination_alternate_airports take effect only against an AIRPORT anchor. Sent with a city anchor (origin_type / destination_type "city", or a code that resolves to a city) the search still runs and returns flights, the list is ignored, and the side comes back in unapplied_filters with the reason — that is a warning to relay, not an error. - 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 FILTER PASS-THROUGH (CRITICAL): - When the user picks a flight from a previous flight_calendar or find_destination result, you call price_check with that offer_token. - ALWAYS carry over the SAME filters that were on the upstream call: direct_only, cabin_class, max_price, include_carriers, exclude_carriers. - The BFF performs a "closest-match" reshop using offer_token. Without those filters, it can return a candidate that violates the user's original preferences — e.g. stopover when they asked for direct, or wrong cabin. - Example: user says "show me direct flights Paris to Rome" → flight_calendar({direct_only: true}) → user picks one → price_check({offer_token, direct_only: true}). Forgetting direct_only here is a bug; do not skip it. 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. 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 as
hotel_details
read-only
checkincheckouthotel_id*user_intent
Rich metadata (gallery, facilities, policies, per-room details) for a single hotel — called by the hotel widget on fullscreen open. **Cost: 1 credit per call.** Rich metadata (gallery, facilities, policies, per-room details) for a single hotel — called by the hotel widget on fullscreen open. **Cost: 1 credit per call.**
hotel_search
read-only
roomsadultscheckin*filterstrip_idcheckout*
+6
Search live hotel inventory and rates worldwide. REQUIRED: - destination: object — two distinct modes. Mode A (rate lookup): { hotel_name (+ optional country_code, city_name) } or… Search live hotel inventory and rates worldwide. 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 }, { latitude + longitude (+ radius_km) }, or { place_id }. - checkin, checkout: YYYY-MM-DD - 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: filters are ignored (user named the property), and 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 }: unambiguous cities or well-known POIs only ("Paris", "Times Square"). Provider AI search returns 0 for islands ("Menorca", "Santorini", "Mykonos"), regions ("Tuscany", "Provence", "Bavaria"), countries, archipelagos. Do NOT use { query } for those. - { 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). - { latitude + longitude + radius_km }: when the destination is an area, island, or region with no obvious primary city. radius_km up to 50. - { place_id }: when you already have an upstream Place ID. If the user names something non-city (an island, region, archipelago, neighborhood), DO NOT pass it as { query } — pick { city_name+country_code } or { latitude+longitude+radius_km }. 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.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; the search scans deeper automatically when few fit. Prefer it over post-filtering results yourself. 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). 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. EXAMPLES: - { "destination": { "query": "Paris" }, "checkin": "2026-07-15", "checkout": "2026-07-18", "adults": 2 } - { "destination": { "city_name": "Barcelona", "country_code": "es" }, "checkin": "2026-08-01", "checkout": "2026-08-05", "occupancies": [{ "adults": 2 }, { "adults": 1, "children_ages": [5] }] } - Mode A: { "destination": { "hotel_name": "Hotel Calimala", "country_code": "it", "city_name": "Florence" }, "checkin": "2026-07-15", "checkout": "2026-07-18", "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" }. - 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. **Cost: 10 credits per call.**
trip
can modify data
trip_idadd_itemoffer_idremove_itemuser_intentpayment_type
+4