RouteStack.ai

Lookup car pickup/dropoff locations by a search term. Pass the traveler's place name as given (e.g. "London Airport", "New York Airport") — when a city has multiple airports, the results list every matching airport; present them to the traveler and let them choose. Never auto-select a single airport on behalf of the traveler.

car_locations

Look up airports and cities by name or IATA code. Use when the user names origin or destination for a flight search.

flight_locations

Search flights. Returns compact offers[] — each has fareSourceCode and flight (for checkout). Also echoes origin/destination/departureDate/adults/children/infants/searchFilterObj/correlationId. Persist those; do not invent fareSourceCode.

search_flights

Look up cities/neighborhoods/hotels. For a named property (e.g. Avari Apartments), query the full hotel name and use the Hotel-type row. MCP remembers that row so hotel_search can apply hotel focus even if destinationType/hotel_name are omitted. Use destinationId, lat, and long from the chosen result row for hotel_search — never invent IDs.

search_destinations

CRITICAL for a named hotel: pass filters.hotel_name (e.g. "Avari Apartments") OR destinationType "Hotel" / isFromSingleHotel true. If you only pass destinationId from a Hotel destinations row, MCP still applies hotel focus from remembered metadata. City/area search → City destinationId, no hotel_name. Occupancy is required from the traveler (rooms[].adults); never invent 2 adults. Optional sortBy is one of { price: "ASC"|"DESC" }, { rating: "ASC"|"DESC" }, { saving: "ASC"|"DESC" } and is applied to the full listing. Returns compact hotels[] plus correlationId/token.

search_hotels

Search rental cars. Returns compact offers[] — each has fareCode and car (for checkout). Also echoes pickup/dropoff/pickupDate/dropoffDate/correlationId. Persist those; do not invent fareCode. Location and schedule fields (MCP normalizes aliases for all clients — AI Chat, ChatGPT, Claude, MCP connectors, etc.): Preferred shape: pickup/dropoff objects each with { name, code?, date, time }. Accepted flat aliases on the same tool call: pickupPlace, dropoffPlace, pickupDate, dropoffDate, pickupTime, dropoffTime (and snake_case pickup_location, pickup_date, pickup_time, pickup_location_code, etc.). Empty pickup/dropoff {} objects are ignored when flat aliases are present. Interpret the traveler's natural language into these structured fields — MCP does not parse raw chat. Airport codes (IATA): when the traveler gives a code such as SFO, LHR, or LAX, set pickup.name (and preferably pickup.code) to that code; MCP resolves it via CTS car locations autocomplete for every MCP client — do not invent internal location IDs. Use car_locations (car_search_locations) to resolve name/code when unsure — never put rental company names in pickup.name. Ambiguous cities/airports (works worldwide, not just London — MCP resolves this from live location data, not a hardcoded list): When the traveler names only a city/region that has multiple airports and does not name one specific airport (examples: "London Airport", "airport in London", "any airport near London", "flying into London", "car rental at a London airport", "New York Airport", "Paris Airport", "Tokyo Airport", "Dubai Airport", "Mumbai Airport", "Delhi Airport"), pass the traveler's place name plus "Airport" as pickup.name/dropoff.name exactly as given (e.g. name: "London Airport") — do NOT silently pick one specific airport (e.g. do not default to Heathrow/LHR or any other single airport) and do not invent a code. If car_search (or car_locations) responds with code "CAR_LOCATION_AMBIGUOUS", it means multiple airports matched — the response includes a candidates[] array of { name, code } for every matching airport. You MUST stop and ask the traveler to choose one from that exact list before calling car_search again; never auto-select a candidate, even if one seems "most likely" or most popular. Once the traveler names one airport (by name or code), call car_search again with that exact airport in pickup.name/pickup.code (and dropoff too, if it was also ambiguous). Every user-requested constraint must appear together in filters on the same car_search call. Each supported filter dimension is independent — any subset (2, 5, 9, or all filters) uses the same flow with logical AND. Do not drop, omit, or merge away a filter because others are present. Never split inventory filters across findData — prefer filters.* keys; MCP merges aliases and applies every dimension. You must infer the total traveler/seat count from natural language and emit structured numbers — MCP does not parse raw chat text. Count every person who needs a seat (adults, children, infants unless the user excludes infants). Examples (emit minPassengers; add maxPassengers equal to the same N when the user wants exactly N seats): "7 seater" / "7-seater" / "7 passenger" / "7 seats" / "7 people" / "car for 7 adults" / "we are 7" → minPassengers 7, maxPassengers 7; "5 passenger car" / "for 5 people" / "five seats" → minPassengers 5 (maxPassengers 5 if exact); "me and my friend" → 2; "me and my wife" → 2; "me and my wife with 3 kids" → 5; "family of 4" → 4; "travelling with 3 people" / "group of 6" / "5 friends" → minPassengers equals the counted total; "need a family car" without a number → infer a reasonable minimum from context (often 4–5) or ask one clarifying question before searching. For "at least N" or "N or more" set minPassengers only (omit maxPassengers). For exact N-seater requests ALWAYS set minPassengers and maxPassengers to the same N — never rely on carCapacity 6_or_more alone for a specific count. Use carCapacity buckets (2_to_5, 6_or_more) only when the user asks for a broad range with no exact number.

search_cars