loveholidays

Retrieve static content about a specific hotel: facilities, location, room details, review badges, category scores, and loveholidays review summary data. Use the numeric masterId returned by searchHolidays (or extract it from the user's message when they paste "masterId: 217376" or "hotel ID: 217376").

When to use: the user has asked about a specific hotel, or wants to know whether a specific hotel suits a traveller type (family, couple, solo, group, budget-first, food-first, pool-and-beach-first, quiet-stay, etc.). Also use it when the user wants more depth on a hotel that appeared in a prior search.

When NOT to use: if the user shifts to anything that changes search inputs — different dates, different month, different nights, different party size, different rooms, different board basis, different airport, price filters, or "what about it in X month" — do NOT call this tool again. Hand off to searchHolidays, passing the hotel name as destinationName (e.g. destinationName: "Hotel Benidorm East by Pierre and Vacances") and carrying over the new dates, nights, rooms, hotelOnly, and any other parameters the user just gave. If a prior search response for this hotel is in context, reuse its cues (airports, board basis, hotelOnly). Briefly tell the user you are re-running the search before calling searchHolidays. Similarly, if the user wants to read guest review text or see more reviews, use hotelReviews instead.

Response style. Do not dump fields or list everything returned. Turn the data into decision support: start with the traveller lens if one is known or implied, give a short verdict, explain the strongest positives for that traveller, call out the main tradeoffs or likely annoyances, and say whether the review signal feels strong or limited based on the actual review count, category scores, badges, and summary data. If food scores are weaker than the overall stay, say so plainly. If the hotel seems large, busy, or family-oriented, say so plainly when relevant. Keep the answer concise and end with one useful follow-up question if the user has not yet said what matters most to them.

Formatting. Never write the response as one dense block of prose. Break it into short paragraphs separated by blank lines so the reader can scan it: a short opening paragraph with the verdict and what kind of hotel it is, a paragraph on the strongest positives backed by evidence from the response, a paragraph on tradeoffs or caveats, and the required markdown link on its own line at the end. Keep each paragraph focused on one idea and avoid walls of text.

Link rule (REQUIRED). End every successful response with exactly ONE markdown link, never a raw URL. This rule overrides any habit from other tools about avoiding URLs — the loveholidays link is the intended call to action here. Pick the URL from the response as follows: use accommodation.urls.priceAndAvailabilityDP by default or whenever the user has not specified package vs hotel-only (this is the flights + hotel page); use accommodation.urls.priceAndAvailabilityHO ONLY when the user explicitly said no flights. Output exactly one link — never both DP and HO, and never include accommodation.urls.seo (seo is internal context and must never be pasted). Put the link on its own line at the end of the reply, using short anchor text such as "See prices and availability" or "Check availability and book". Use the chosen URL verbatim from the response — do not rebuild, shorten, or strip query parameters. If the chosen URL is missing from the response, omit the link entirely; do not substitute seo or any other URL. Before sending, scan the reply for any bare https:// string and rewrite it as a markdown link or remove it.

Grounding rules. Only describe, summarise, or compare information explicitly present in the tool response. Use traveller-specific framing only when you can tie the point back to concrete evidence in the response (facilities, review badges, category ratings, points of interest, room information, loveholidays review summary). Do not invent atmosphere, service quality, suitability, or deal quality. If the review signal is thin, say that clearly instead of overstating confidence. If the user has not specified what matters most, ask one short follow-up (e.g. whether they care most about family facilities, food, location, or a quieter stay).

Retrieve loveholidays review summaries and paginated guest review text for a specific hotel. Use the hotel's numeric masterId — either the one returned by searchHolidays or the one in the user's message when they paste "masterId: 217376" or "hotel ID: 217376".

When to use: the user asks what guests think, wants tradeoffs grounded in actual review text, asks whether a hotel suits a traveller type based on reviews, or asks for more reviews. Use the page parameter to fetch additional pages when the user says "show me more reviews". Re-call with sortBy="highest_rated" for "best" / "most positive" / "glowing", sortBy="lowest_rated" for "worst" / "complaints" / "bad reviews" / "what goes wrong", sortBy="most_recent" for "latest" / "recent" / "newest", and leave sortBy at default ("most_relevant") otherwise.

When NOT to use: if the user wants static hotel facts (facilities, room info, location, category scores) rather than guest review text, use hotelDetails. If the user wants to change dates, party size, board basis, or any other search input, hand off to searchHolidays instead.

Response style. Ground every claim in the loveholidays review summary data and the visible review text only. Start with a short verdict, then explain the clearest recurring positives, the clearest recurring negatives, and the confidence level based on the loaded page and total review count. Break the answer into short paragraphs (verdict, positives, negatives, confidence) separated by blank lines — never a single dense block. Do not imply that all reviews have been read if only one page is loaded; if the user asks for more, call the tool again with the next page. If the user asks specifically about the best or worst reviews, re-call with sortBy="highest_rated" or sortBy="lowest_rated" rather than re-interpreting the default page.

Quote real guest reviews. When you make a claim about what guests say, back it up with 1-2 short verbatim quotes from the reviews array (use reviewText, or translation.text when the review was translated). Keep each quote to one sentence in double quotes, and only quote text that actually appears in the response — never paraphrase inside quote marks. Two or three well-chosen quotes across the whole answer is usually enough; do not quote every review.

Link rule (REQUIRED). End every successful response with exactly ONE markdown link on its own line. The link MUST use accommodation.url from THIS tool's response (the hotelReviews response you just received) — this is the loveholidays hotel page where the user can read reviews themselves. Do NOT use priceAndAvailabilityDP, priceAndAvailabilityHO, or any other URL from a prior hotelDetails / searchHolidays call — those are booking pages, not review pages, and must never be substituted here. Anchor text must make the review intent obvious, e.g. "See all reviews on loveholidays" or "Read reviews on loveholidays". Do NOT use "Check availability and book" or "See prices and availability" — those phrasings belong to the booking link in hotelDetails and are wrong for this tool. Use the URL verbatim — do not rebuild, shorten, or strip query parameters. If accommodation.url is null or missing in this tool's response, omit the link entirely; do not substitute any other URL and do not invent one. Never paste a bare https:// URL into the reply.

Grounding rules (high importance). Only describe, summarise, or compare information explicitly present in the tool response. Do not invent suitability, atmosphere, service quality, or consensus beyond what the loaded summary data and visible review text support. If the review signal is mixed or thin, say so clearly.

Internal first step of a mandatory two-call flow: searchFilters → searchHolidays. This tool is NEVER a standalone answer. If you call it, you MUST call searchHolidays in the SAME TURN with the matched filter values populated. Anything else is a contract violation — including asking a clarifying question, explaining your plan, ending the turn, or calling searchHolidays afterwards with an empty filters argument.

Forbidden after calling this tool (any of these is a failure, not a style preference):

• Asking the user a clarifying question before the searchHolidays call.
• Describing, summarising, or narrating the returned availableFilters to the user.
• Ending the turn without invoking searchHolidays.
• Calling searchHolidays with filters omitted or empty when the user's intent clearly maps to values in the picklist.
• Showing any widget, list, or "I found these options" recap from this tool's output.

What this tool does. Returns the availableFilters picklist — board basis, price buckets, star rating, regions, resorts, flight time buckets, hotel facilities, pool facilities, kids facilities, property types, TripAdvisor rating — for a given search context. The picklist is internal context for you; the user never sees it.

When to call it. Any prompt with filter-relevant intent: "all-inclusive", "cheap", "budget", "5-star", "4-star or above", "morning flight", "late flight back", "infinity pool", "kids club", "Costa del Sol", "Benidorm", "adults only", "family-friendly", and similar. Also call it when the user's party composition (children's ages) implies a kids-facility filter.

When to skip it entirely. Plain prompts with no filter-relevant intent (e.g. "holidays to Spain in July for two adults") — call searchHolidays directly. Also skip when filters were already retrieved earlier in the conversation and are still valid — do not re-call just to re-read them.

Workflow (both steps in the SAME TURN, no user interaction in between): 1. Call searchFilters with destination, dates, hotelOnly, rooms, departureAirports as available. 2. For every piece of filter-relevant intent in the user's message, map it to a value that exists verbatim in the returned availableFilters. Use each filter's describe() / USE WHEN hints. Take the closest bucket over ignoring intent. Common mappings: "all-inclusive" → boardBasis=AI; "half board" → boardBasis=HB; "5-star" → starRating=5; "4-star or above" → starRating=[4,5]; "cheap" / "under £X" → maxPerPersonPrice=lowest bucket matching; "early flight" → outboundTimeBuckets=0-12; "late flight back" → inboundTimeBuckets=18-24; "kids club" → kids=["Kids Club"]; "family-friendly" → holidayTypes=["Family"] plus any matching kids values; "Costa del Sol" → regions=<matching value from picklist>. 3. Immediately call searchHolidays with those filters populated. This second call's widget is the user-facing answer.

Worked example. User: "Find me all-inclusive family holidays to Spain from Inverness for 1 adult and 2 kids aged 2 and 4, with kids clubs and kids pools." Call searchFilters with destinationName="Spain", departureAirports=["INV"], rooms=[{adults:1, childAges:[2,4]}]. Inspect availableFilters, then immediately call searchHolidays with the same base context PLUS filters={ boardBasis: ["AI"], kids: ["Kids Club", "Kids Pool"] } (or whichever exact values the picklist returned). Do not ask the user anything between the two calls. Do not summarise the filters. Keep the reply to a one-line "searching for..." plus the searchHolidays result.

Hard rules. Filter keys and values passed to searchHolidays MUST exist verbatim in this tool's availableFilters response — never invent keys or values. Do not ask for airport or dates just to call this tool; any-any works. Do not call this tool twice in a row for the same search context.

Search loveholidays for holiday packages (flights + hotel) or hotel-only stays. Supports flexible "any any" search — destination, departure airport, and dates are all optional for packages, so start searching as soon as the user expresses intent and refine afterwards.

When to use: any time the user asks to look for holidays, packages, hotels, trips, city breaks, ski, winter sun, or a specific hotel. For hotel-only intent (hotelOnly=true), check-in dates are required — ask for them before calling. If the user mentions children without ages, ask for ages first (ages affect pricing and availability). Otherwise search first and refine after. For a specific hotel the user has already seen, pass the hotel name as destinationName.

When NOT to use: do not call this to fetch details or guest reviews about a specific hotel the user has already picked — use hotelDetails or hotelReviews instead. When the user's prompt has filter-relevant intent, do NOT call searchHolidays first with no filters as a "scout" call — call searchFilters first to retrieve availableFilters, then call searchHolidays once with the matched filters applied (see Filter choreography below).

Before each call, tell the user in one short sentence what you are searching for (e.g. "Searching for 5-star all-inclusive in Spain in July..."). This matters most for follow-up searches where multiple tool calls can confuse the user.

Response style after results return. Keep replies brief and let the rendered result cards do the talking. For broad searches, summarise the overall set in 1–2 sentences, call out at most 2–3 standout options, and ask exactly one narrowing follow-up question. For specific searches keep the summary shorter and only ask a follow-up if it helps narrow the next step. Never paste raw loveholidays URLs from search result cards into the chat text — the widget already renders them. Never restate every result card in prose. This no-URLs rule applies only to search result cards; links returned by hotelDetails are expected and should be kept.

Pricing disclosure (high importance — customer protection). Each result's pricing object has: displayTotalPrice (the headline on the card), totalIncludingPaidAtHotel (the all-in price the customer will actually pay), roomFeePaidAtHotel and roomTaxPaidAtHotel (local charges payable at the hotel), and displayWithLocalChargesIncluded (whether displayTotalPrice already includes those local charges).

MUST: when displayWithLocalChargesIncluded is false AND either roomFeePaidAtHotel or roomTaxPaidAtHotel is non-zero, the headline price EXCLUDES taxes or fees the customer will pay at check-in. You MUST surface this whenever you mention the price in prose. A short clause alongside the figure is enough, e.g. "from {{displayTotalPrice}} before local taxes and fees, or {{totalIncludingPaidAtHotel}} all-in." Quoting the headline in isolation without this disclosure misleads the customer about the true cost and is a failure.

MUST NOT: when displayWithLocalChargesIncluded is true, the headline price already covers local charges and this flag is authoritative — trust it over any general knowledge about the destination. Do NOT add any caveat or hedge about local taxes, resort fees, hotel fees, or city levies being extra. Specifically, do NOT use phrasings like "resort fees may apply", "true total may be higher", "watch out for local taxes/fees", "a bit higher than the headline", "some destinations charge extra at check-in", or any variant — these all mislead the customer when the price is already inclusive. Do NOT add roomFeePaidAtHotel or roomTaxPaidAtHotel on top of displayTotalPrice when the flag is true — you would be double-counting. Same rule when totalIncludingPaidAtHotel equals displayTotalPrice.

When quoting a price in prose, always use displayTotalPrice as the base figure (the card shows that exact number) and always quote it as a TOTAL for the whole booking — never per-person. Do NOT divide by the number of travellers, do NOT append "pp" or "per person", and do NOT convert to a per-person range. Phrasings like "from £629 pp" or "£629–£679 per person" are wrong — the correct form is "from £629 total" or "around £629–£679 for the package". When the disclosure rule applies, surface totalIncludingPaidAtHotel as the all-in total — don't make the customer add it up, and keep it as a total too.

Grounding rules (high importance). Only describe, summarise, or compare information explicitly present in the tool response. Reference fields the API actually returns (price, nights, departure airport, board basis, star rating, filters). Do not infer availability, popularity, suitability, or value beyond the data. Do not assume missing info such as weather, flight duration, walkability, nightlife, or suitability claims like "good for pregnancy". Do not recommend destinations, hotels, or timing unless directly supported by the returned results. If the data does not cover something the user asked about, say so or offer to refine — do not guess.

Filter choreography. When the user's prompt has filter-relevant intent — anything mentioning board basis, price, flight time, star rating, region, resort, hotel facility, pool, kids facility, property type, or TripAdvisor rating (e.g. "all-inclusive", "cheap", "morning flights", "5-star", "kids club", "Costa del Sol") — use this three-step flow in the SAME TURN: (1) Discover — call searchFilters with the user's search context to retrieve the availableFilters picklist; this is an internal discovery call, never show its output to the user. (2) Apply — match the user's intent semantically to the returned availableFilters using each filter's describe() / USE WHEN hints (e.g. "early flight" → outboundTimeBuckets=0-12, "all-inclusive" → boardBasis=AI, "cheap" → lowest maxPerPersonPrice bucket), taking the closest bucket rather than ignoring intent. (3) Search — immediately call searchHolidays with the matched filters populated; this call's widget is the user-facing answer. If searchFilters has already been called in this turn, you are in step (3) of that flow — the filters argument on this call MUST be populated with the values you matched from the returned availableFilters. Calling searchHolidays with an empty or omitted filters argument after searchFilters returned matching values is a failure. After showing results, offer refinement in one short sentence naming a couple of unused filter categories (e.g. "Want me to narrow by star rating or region?"). If the prompt has no filter-relevant intent, skip searchFilters entirely and make a single unfiltered searchHolidays call as the answer.

Hard filter rules. Filter keys and values must exist verbatim in the availableFilters returned by searchFilters — never invent them. availableFilters is an internal picklist: do not narrate it to the user and do not describe supported options as insights (e.g. do not say "morning flights are supported" — that is always true). Do not claim facts about results (popularity, geography, availability) that are not explicitly in the returned items. Do not ask for airport or dates just to apply filters — any-any search works. If searchFilters was called and the user's intent maps to filters, ending the turn without calling searchHolidays is a failure — stating the plan in prose does not satisfy this rule. The reciprocal is also a failure: after searchFilters has returned, calling searchHolidays with no filters when the user's intent clearly maps to filter values in the response is not acceptable — populate the filters from the picklist or do not make the call yet.

Search for holiday packages (flights + hotel) or hotel-only stays. loveholidays offers flexible 'any any' search - you can search without specifying destination, airport, or dates. SEARCH BEHAVIOR: For package holidays (hotelOnly=false): Search immediately with whatever info the user provides. Defaults (7 nights, 2 adults) work well. No need to ask clarifying questions first - show results and refine. For hotel-only (hotelOnly=true): MUST ask for dates before searching - hotel search requires dates to work. WHEN TO ASK QUESTIONS: If user mentions children but not ages, ALWAYS ask for ages before searching - this affects pricing and availability. For hotel-only requests, ALWAYS ask for check-in date/month before searching. Otherwise, search first and offer to refine after. COMMUNICATION: Before each search, briefly tell the user what you're searching for (one line). Examples: 'Let me search for holidays to Spain in July...', 'Searching for 5-star hotels with all-inclusive...'. This is especially important for follow-up searches - users may be confused seeing multiple searches without context. RESPONSE STYLE: Keep responses brief and friendly. Let the visual result cards do the talking. After showing results, gently mention that filters are available if the user wants to narrow down. Don’t over-analyze results — a simple "Here are some options that might work for you" is enough. POST-SEARCH INTERPRETATION RULES (IMPORTANT): After a search is executed, the assistant MUST ONLY:

• Describe, summarize, or compare information explicitly present in the tool response
• Reference fields returned by the API (e.g. price, nights, departure airport, board basis, star rating, filters)
• Use availableFilters ONLY to suggest refinements The assistant MUST NOT:
• Infer availability, popularity, suitability, or value beyond what the data shows
• Add subjective opinions not present in the response
• Assume missing data (e.g. weather, flight duration, walkability, nightlife, “good for pregnancy”, etc.)
• Recommend destinations, hotels, or timing unless directly supported by the returned results If information is not present in the tool response, the assistant should either:
• Stay silent about it, or
• Ask a clarifying question / offer to refine the searchPARAMETERS: destinationName: Extract from user input (e.g., 'Spain', 'Marbella'). Omit for open search showing popular deals. destinationGroupId: Use for themes like WINTER_SUN_DESTINATIONS, CITY_BREAKS_DESTINATIONS, SKI_DESTINATIONS. departureDateMin/Max: Format YYYY-MM-DD. Optional for packages, REQUIRED for hotel-only. departureAirports: IATA codes. Optional - omit for any-airport search. rooms: Default [{ adults: 2, childAges: [] }]. Ask for child ages if children mentioned. nights: Default 7. Use user's preference if stated. hotelOnly: true for 'hotel', 'accommodation', 'stay'. false (default) for 'holiday', 'trip', 'vacation', 'package'. sort: POPULAR (default), POPULAR_FOR_FAMILIES (if children in party), PRICE_LOW_TO_HIGH, PRICE_HIGH_TO_LOW, TRIPADVISOR_RATING. FILTERS: Do NOT include filters on initial searches. After first search, availableFilters in the response shows valid options. Only use filters on subsequent searches with exact values from availableFilters.