Almosafer.com

Tools (2)

Extracted live via the executor SDK.

• search_hotels

  Search for hotels in a specific location. Use this when the user wants to find hotels, accommodation, or places to stay. Returns top 8 hotels matching the criteria with photos, ratings, and prices.

  CRITICAL - PROMPT FIELD:

  • Copy the user's EXACT message into "prompt" - character-for-character, no changes.
  • If user wrote "أبحث عن فندق في دبي", pass that EXACT Arabic text.
  • NEVER translate the prompt field.

  OTHER FIELDS: Must be in English (location, dates, etc).

  IMPORTANT - LOCATION FORMAT: Always provide the full location name with city and country:

  • For cities: "City, Country" (e.g., "Dubai, United Arab Emirates", "Riyadh, Saudi Arabia")
  • For areas/neighborhoods: "Area, City, Country" (e.g., "Dubai Marina, Dubai, United Arab Emirates", "JBR, Dubai, United Arab Emirates", "Al Olaya, Riyadh, Saudi Arabia") Always use the official/correct area name as it appears on maps.

  PRICE FIELDS IN THE RESPONSE - read this carefully so you don't misquote prices: Each hotel has price.perNight (average per-night rate), price.total (sum across all nights), and price.nights (number of nights). When mentioning a price to the user, use the field that matches what they asked for:

  • "X per night" / "Y a night" / "ليلة" → use price.perNight
  • "total trip cost" / "for the whole stay" / "السعر الإجمالي" → use price.total
  • If unclear, mention both: "SAR 1,500/night (SAR 7,500 total for 5 nights)". NEVER invent a per-night value by dividing price.total by anything. NEVER claim price.total is a per-night rate. The two numbers are already computed for you.

  DATE PRE-VALIDATION (HARD — DO NOT CALL THE TOOL IF ANY OF THESE FAIL): Before calling search_hotels, validate the dates against today. If any check fails, do NOT call the tool. Reply directly to the user, explain which date is invalid, and ask them to provide corrected dates.

  • checkIn must be today or later. If checkIn is in the past, do NOT call the tool.
  • checkOut must be strictly after checkIn. If checkOut is the same day or earlier than checkIn, do NOT call the tool.
  • Stay length (checkOut - checkIn) must not exceed 28 nights. If longer, do NOT call. Calling the tool with invalid dates and letting the schema reject is NOT acceptable — catch it before the call.

  OCCUPANCY LIMITS (HARD — DO NOT CALL THE TOOL): The hotel search supports at most 4 rooms per query, and at most 8 total guests (adults + children) across all rooms combined. If the user asks for more (e.g. "5 rooms", "10 people", "9 guests across 3 rooms"), DO NOT call the tool — tell them the limit and ask them to reduce the party size or split the request.

  STAY LENGTH LIMIT (HARD): Maximum 28 nights per search (checkOut - checkIn ≤ 28 days). If the user requests a longer stay (e.g. "2 months", "30 days"), DO NOT call the tool — tell them the 28-night limit and ask them to split the stay into separate searches.

  FILTER RULES — READ CAREFULLY, THIS IS THE #1 SOURCE OF BUGS: The "filters" object must be OMITTED entirely unless the user's words explicitly match a specific filter. "Explicitly" means the user used words that directly name the filter concept. Common mistakes to AVOID:

  • "cheap" / "affordable" / "budget" → set sortBy: "priceAsc". Do NOT invent a priceRange.max number. Only set priceRange when the user states a specific number (e.g. "under $100", "less than 500 SAR", "max budget 200").
  • "comfy" / "nice" / "good" / "cozy" / "clean" → these are vibes, NOT filters. Do NOT add starRating, freeCancellation, or priceRange. Leave filters empty.
  • "organize a trip" / "plan a vacation" / "travel to X" → general travel intent. Do NOT add starRating (e.g. 3-5 stars) or any other filter. Leave filters empty.
  • "two bedroom" / "apartment" / "suite" → ONLY set propertyType if it matches the enum. Do NOT add freeCancellation or any other unrelated filter.
  • freeCancellation → ONLY when user literally says "free cancellation", "refundable", or "cancel for free". Words like "flexible", "affordable", "safe" do NOT mean free cancellation.
  • starRating → ONLY when user says "5-star", "at least 4 stars", "3-star or above", etc. General quality words ("nice", "good", "decent") are NOT star ratings. If in doubt, OMIT the filter. A search with no filters returns more results, which is always better than a search that silently excludes matches the user would have wanted.
• search_flights

  Search for flights between two airports. Use this when the user wants to find flights, airfare, or air travel options. Returns available flight itineraries with prices, schedules, and airline information.

  CRITICAL - PROMPT FIELD:

  • Copy the user's EXACT message into "prompt" - character-for-character, no changes.
  • If user wrote "أبحث عن رحلة إلى دبي", pass that EXACT Arabic text.
  • NEVER translate the prompt field.

  IMPORTANT - ENGLISH ONLY: All OTHER input argument string values MUST be in English. If the user writes in Arabic, translate the intent to English before calling this tool. Do NOT include Arabic script in any argument values except "prompt".

  IMPORTANT - AIRPORT CODES: Always use 3-letter IATA airport codes:

  • Riyadh: RUH
  • Jeddah: JED
  • Dubai: DXB
  • Abu Dhabi: AUH
  • Doha: DOH
  • Kuwait: KWI
  • Bahrain: BAH
  • Muscat: MCT
  • Cairo: CAI
  • London Heathrow: LHR

  DATE PRE-VALIDATION (HARD — DO NOT CALL THE TOOL IF ANY OF THESE FAIL): Before calling search_flights, validate the dates against today. If any check fails, do NOT call the tool. Reply directly to the user, explain which date is invalid, and ask them to provide corrected dates.

  • departureDate must be today or later. If departureDate is in the past, do NOT call.
  • If returnDate is provided, it must be strictly after departureDate. If returnDate is the same day or earlier than departureDate, do NOT call the tool. Calling the tool with invalid dates and letting the schema reject is NOT acceptable — catch it before the call.

  ROUND-TRIP DURATION LIMIT (HARD): Round-trip searches are capped at 110 days (returnDate - departureDate ≤ 110). If the user asks for a longer trip (e.g. "6 months", "leave in May, return in October"), DO NOT call the tool — tell them the 110-day limit and ask them to shorten the trip or split into separate one-way searches.

  FILTER RULES — READ CAREFULLY: The "filters" object must be OMITTED entirely unless the user's words explicitly name a specific filter concept. Common mistakes to AVOID:

  • "cheap" / "affordable" / "budget" → use sortBy: "cheapest". Do NOT add any filter.
  • "plan a trip" / "organize travel" / "I want to go to X" → general intent. Do NOT add directOnly, departureTime, or any filter. Leave filters empty.
  • "business trip" → does NOT mean cabin: "Business". Only set cabin when user explicitly says "business class" or "first class".
  • "comfortable" / "good" / "nice" → vibes, NOT filters. Leave filters empty. If in doubt, OMIT the filter. More results is always better than silently excluding flights the user would have wanted.