check_experience_availability
ChatGPTUse this only when the user explicitly wants a live supplier check for one specific Over The Planet activity. For broad destination searches with dates, use get_listed_experience_availability once with all shortlisted IDs instead; never call this tool once per product. If the user names the specific activity without a public ID, search first and use the returned publicId; users do not need to know the ID. Requires the activity publicId, start date, optional end date, and room-style occupancy values such as ["2"]. Returns supplier availability, available dates/times, prices, each option's cancellation policies and date-derived free-cancellation status, without reserving a slot. isRefundable alone does not mean cancellation is free. Never claim that a booking was made.
get_experience_details
ChatGPTUse this after search_experiences returns a publicId or when the user explicitly provides an Over The Planet activity public ID. If the user gives only an activity name, search first instead of asking them to find the ID. Returns catalogue details, images, starting-price information, rating evidence, and a direct detail URL. Do not use for live availability or booking confirmation.
get_experience_options
ChatGPTUse this when the user asks for variants, options, prices, or catalogue sale dates for an Over The Planet activity. If the user gives an activity name without a public ID, search first and use the returned publicId. Returns option names, SKUs, images, starting-price windows, and a direct detail URL. Do not use for live availability, booking, payment, flights, or accommodation.
get_listed_experience_availability
ChatGPTUse this after a broad dated experience search to retrieve availability information previously recorded by Over The Planet for every publicId returned by that search page in one GraphQL request. Pass all result publicIds together (up to 10); do not make one call per product. These details are not checked with providers in real time, so prices and availability may have changed. Returns cancellation policies for each matching option plus whether free cancellation applies before a policy date, based on Over The Planet's cancellation-policy rules; do not infer this from isRefundable. No availability details returned does not mean an experience is sold out. For an explicit live check of one chosen activity, use check_experience_availability instead.
render_travel_cards
ChatGPTThis tool creates the final visual result, so invoke it at most once per answer, sequentially and only after all relevant Over The Planet data and requested availability calls have completed and the shortlist is fixed. Never call it in parallel with data tools, for provisional results, or a second time to update the same answer. For a broad activity or hotel shortlist with two or more usable products, pass 2–8 final selected listings. For one listing, use this only when the user asks for a card or a product-specific detail/availability response benefits from one. Do not call for empty results or unresolved ambiguous name candidates; if the final data is unusable or this call fails, answer in text without retrying the renderer. Copy names, HTTPS product URLs, every available images[].url candidate in original order into imageUrls, duration, language, ratings, review counts, prices, cancellation summaries and other availability facts only from previous tool results; never invent or alter them. Copy freeCancellation only when the prior result has status all_options or some_options; preserve the status and deadline exactly. Never infer free cancellation from isRefundable. When passing linkContext, set productType to activity or hotel and include only a user-provided or resolved arrival/check-in date; never copy implicit occupancy defaults. For activities, set departAt equal to arriveAt. For hotels, use the explicit check-out date or omit it to apply the two-night default. Copy user-specified occupancy exactly. Copy destination.url to destinationUrl when available; never use the homepage as a fallback. Use an empty imageUrls array only when no image URLs were returned. For availability details that weren't confirmed with providers in real time, use plain language: say they may have changed and recommend checking Over The Planet before booking; don't expose implementation or storage terms. Put available rating and duration data in the structured fields, and use metadata only as a concise fallback. Keep badges concise; if more than two are supplied or their text is long, the server shortens them and keeps only the first two. After rendering, keep the conversational response brief and non-redundant.
search_experiences
ChatGPTUse this when the user asks what to do, tours, activities, or experiences in a named destination, or names a specific activity. If no destination is stated or clearly established in context, ask which city or area to search before calling. For 'near me', use a location only when one is explicitly available; otherwise ask. Never infer a destination from locale, currency, or time zone. Always provide destination separately. For broad browsing, omit queryText/activityName; use queryText only when the user names or clearly describes a particular activity, preserving their original wording. The server resolves aliases, partial names, spelling differences, and products without a destination relationship. Do not ask the user for a publicId. Returns active catalogue experiences with images, starting-price windows, ratings, match guidance, and direct detail URLs as data only. For broad searches with dates, follow with one get_listed_experience_availability call for all shortlisted publicIds. Once all data and requested availability calls finish, call render_travel_cards at most once with the final shortlist of two or more usable experiences; never render a provisional shortlist or retry/update it in the same answer. If the match is ambiguous, show candidates and ask the user to choose instead of rendering unresolved candidates. Do not use for flights, visas, general destination facts, live availability, or booking confirmation. Use searchMode category with categories for preference requests such as ski-related, family-friendly, romantic, or food experiences; do not put category words in queryText. Use searchMode specific only when the user names a particular product. Use broad for open-ended destination browsing.
search_hotels
ChatGPTUse this when the user asks to find hotels, accommodation, or places to stay in a named destination and a check-in date is known. Check-out is optional; if omitted, default it to two nights after check-in. Use an explicitly provided occupancy, or the standard two-adult search default. Returns active hotel properties with images, ratings, a point-in-time supplier rate, room name, and direct links as data only. After all data calls finish, call render_travel_cards at most once with the final shortlist of two or more usable hotels; never render provisional results or retry/update the same answer. This is read-only discovery: it does not reserve rooms, book, charge, or guarantee a rate.
