Priceline

Use ONLY when the user is finding or comparing hotels (new lodging) for a destination and dates. If the user has not said where they want to stay, ask for a destination first. Every call must include countryName. Use the country established by the conversation or an unambiguous destination, such as IN for New Delhi. If the destination is ambiguous, ask which country and, when needed, state or region the user means before calling. Never assume US because the country was omitted. Do not ask again for destination details already established in the conversation. If the user names two or more distinct places that are not clearly in the same metro area (e.g. two different airports in different cities, like "LaGuardia or Newark"), do not guess one and drop the other—ask which one they mean before calling this tool. This includes finding a specific property the user already chose earlier in the conversation, including one surfaced before Priceline was invoked. When the conversation identifies that property, set hotelName to it and carry forward its known location into cityName, state, countryName, and neighborhoodsNames (street, area, or landmark), plus any known dates and occupancy; that location counts as the destination, so do not ask for it again—but still apply the date checks below, and if more than one property is in play, ask which one. When the user asks to book on Priceline, keep that property: search for it by hotelName and location if no Priceline hotel ID is available; if one is, use hotel_detail or hotel_room_options directly. Convert relative dates (e.g. 'next weekend') to YYYY-MM-DD. Validate dates before calling: checkIn and checkOut must be valid calendar dates in YYYY-MM-DD format, today or later—never in the past. Also, the checkOut date must be after the checkIn date. If the request implies past dates or the dates are ambiguous, ask the user to confirm before calling. When you can infer optional filters or stay fields, set them per the tool input schema. Results are standard retail hotel listings only. Brands: only chains the user named—do not add sibling sub-brands unless they said them. The model-visible structured result is lean: hotels plus resolved checkIn/checkOut—summarize in voice using hotel names, pricing, star and guest ratings from each row. Reuse the user's established destination on follow-up searches via cityName, state, countryName, and neighborhoodsNames as applicable, and reuse their dates via checkIn/checkOut. Always include countryName. If error is set or hotels is empty, say the search failed and offer to adjust destination, dates, filters, or occupancy. When summarizing, never read hotel IDs. Use hotel_detail for property detail, hotel_room_options for rates when needed, and hotel_prepare_checkout when the user is ready to proceed to checkout.

hotel_search