flights_poll
ClaudeInternal. Invoked automatically by the flight results widget after flights_search to progressively load more results. Do not call directly.
flights_search
ClaudeSearches for flights between airports or cities. Not for flight status, price tracking, visa information, bookings, or reservation management. Returns results from a Wego metasearch in a single call. Parameters: - newSearch: Route (from/to as IATA codes), dates (fromDate, toDate in YYYY-MM-DD), passengers, and cabin class. Omit toDate for one-way trips. - Defaults when not specified: 1 adult, 0 children, 0 infants, economy cabin. - filters: Include only when the user mentions specific preferences (airlines, stops, times, price range, etc.). - sorting: A single string value. Options: score_desc (recommended, default), price_asc (cheapest), duration_asc (fastest), leg1_departure_time_asc/desc (outbound departure), leg2_departure_time_asc/desc (return departure, round-trip only). Time filtering (time ranges in minutes from midnight, 0-1440): - Format: {min: minutesFromMidnight, max: minutesFromMidnight} - Example: "flights after 10pm" → outboundDepartureTimeRange: {min: 1320, max: 1440} - Example: "depart 8am-1pm" → outboundDepartureTimeRange: {min: 480, max: 780} - Supports wraparound: {min: 1380, max: 60} = 11pm-1am (crosses midnight) Refinement: Provide the searchId from a previous response with updated filters or sorting. Refinement replaces all previous filters and sorting entirely — include existing values alongside new ones to preserve them. Example — changing return to after 10pm while keeping existing airlines ["SQ", "KE"], outbound 6am-8am, and price_asc sorting: { "searchId": "abc", "filters": { "airlines": ["SQ", "KE"], "outboundDepartureTimeRange": { "min": 360, "max": 480 }, "inboundDepartureTimeRange": { "min": 1320, "max": 1440 } }, "sorting": "price_asc" } Default behavior: - One date provided → one-way trip - Return date mentioned → round-trip - No preferences stated → omit filters - City name without specific airport → use the city IATA code (e.g., "London" → LON, "New York" → NYC, "Tokyo" → TYO). City codes automatically search all airports in that city. Format URLs as markdown links: [text](url).
hotels_poll
ClaudeInternal. Invoked automatically by the hotel results widget after hotels_search. Do not call directly.
hotels_search
ClaudeSearches for hotel accommodations by city, geo-location, or hotel ID. Not for restaurants, activities, car rentals, or non-travel queries. Returns paginated results in a single call. Common city codes (DXB, PAR, SIN, TYO, LON, NYC) can be used directly; use places_find_location for specific hotels, POI coordinates, or ambiguous locations. Refinement: When changing filters or sorting, provide the searchId from a previous response along with updated parameters. Search type objects are not needed for refinements. Example: { searchId: "abc123", filters: { amenities: ["wifi"], starRating: { min: 4 } } } Search types (one per new search): 1. citySearch — Hotels in a city. Suitable for generic proximity queries (e.g., "near airports" or "downtown") when combined with sorting. 2. geoSearch — Hotels near a specific location (airport, landmark, POI). Requires latitude and longitude coordinates. Use places_find_location to get coordinates for landmarks. Recommended radius: 10km for landmarks, 20km for airports. 3. hotelSearch — Single hotel by ID. Children ages: When children are included, their ages affect pricing and availability. Missing or incorrect ages produce unreliable pricing and may return zero results. Parameter format: All field names are camelCase (checkIn, checkOut, adultsCount, childrenCount). Coordinates go inside the geoSearch object, not as top-level parameters. Proximity guidance: - Generic proximity (e.g., "hotels near airport") → citySearch + distance_from_nearest_airport_asc sorting - Generic city center (e.g., "downtown hotels") → citySearch + distance_from_center_asc sorting - Named location (e.g., "hotels near Changi Airport") → geoSearch with POI coordinates - Explicit radius (e.g., "hotels within 15km of Eiffel Tower") → geoSearch with POI coordinates and radius Integration with places_find_location: - citySearch: get cityCode with types=["city"] - geoSearch: get coordinates with types=["poi"] Examples: New search: { citySearch: { cityCode: "DXB" }, checkIn: "2025-11-06", checkOut: "2025-11-07", rooms: [{ adultsCount: 2, childrenCount: 0 }] } With amenity filter: { citySearch: { cityCode: "DXB" }, filters: { amenities: ["wifi", "pool"] }, ... } Refinement: { searchId: "abc123", filters: { amenities: ["pool"], starRating: { min: 4 } } } Near airports: { citySearch: { cityCode: "SIN" }, sorting: "distance_from_nearest_airport_asc", ... } Near city center: { citySearch: { cityCode: "PAR" }, sorting: "distance_from_center_asc", ... } Near specific airport: { geoSearch: { latitude: 1.3644, longitude: 103.9915, radius: 20, name: "Changi Airport" }, ... } Near specific landmark: { geoSearch: { latitude: 48.8584, longitude: 2.2945, name: "Eiffel Tower" }, ... } Refinements use the searchId from the previous response with new filters or sorting parameters. Format URLs as markdown links: [text](url).
places_find_location
ClaudeOptional helper to resolve travel location identifiers for hotels and flights (cityCode, hotelId, airport IATA codes, coordinates). Returns location codes, IDs, and coordinates. PURPOSE: Provides specific identifiers for other tools: - Coordinates for hotels_search geoSearch (e.g., "Eiffel Tower" → latitude, longitude) - geoSearch requires coordinates for landmarks - hotelId for hotels_search hotelSearch (e.g., "Burj Al Arab" → hotelId) - City code when needed (e.g., "Kota Kinabalu" → cityCode) - Airport IATA codes when needed (e.g., "New York airports" → JFK, LGA, EWR) Not for restaurants, shops, recipes, or general non-travel queries. PLACE TYPES: Filter by specific types using the 'types' parameter: - city: Major cities (returns cityCode like "DXB", "PAR") - airport: Airports (returns IATA codes like "JFK", "LHR") - district: Neighborhoods within cities (returns districtId) - state: States, provinces, regions - hotel: Individual hotels (returns hotelId) - poi: Points of interest, landmarks (returns coordinates) If 'types' is omitted, returns all matching place types. POI SEARCH WITH LOCATION BIAS: For POI searches, locationBias (approximate coordinates) can optionally improve result relevance when geographic context is known. When to provide locationBias: - User mentions a city: "Eiffel Tower in Paris" (provide Paris coordinates) - Previous conversation context provides location - The landmark location is recognized When locationBias is not needed: - No geographic context available - Uncertain about location - Global/ambiguous landmarks EXAMPLES: Resolve city: { query: "Kota Kinabalu", types: ["city"] } → cityCode Resolve district: { query: "Downtown Dubai", types: ["district"] } → districtId Resolve airports: { query: "New York", types: ["airport"] } → JFK, LGA, EWR Resolve hotel: { query: "Burj Al Arab", types: ["hotel"] } → hotelId Resolve POI with bias: { query: "Eiffel Tower", types: ["poi"], locationBias: { latitude: 48.85, longitude: 2.35 } } Resolve POI without bias: { query: "Marina Bay Sands", types: ["poi"] } AMBIGUITY HANDLING: When multiple locations match, response includes hasAmbiguity: true and disambiguationHint. Ask user to specify which location. NOTES: - locationBias is optional (text search works without it) - Approximate coordinates are fine (city-level accuracy) - Location bias improves relevance but doesn't exclude other regions