create_itinerary
ChatGPTcreate_itinerary - Create a bookable itinerary from flat parameter values (no Redis search/interstitial cache). Accepts simple scalar values — search_id, data_id, origin, destination, depart_date, travel_option_id, fare_id, price, optional card_id / return_card_id, and optional passenger/cabin/return-leg parameters — and assembles the Cleartrip payload internally. When to use: After search_flight has been called and a flight card has been selected. This is the itinerary-creation tool for external/OAuth clients using the stateless path. Can be called in two ways: 1. With fare family selection (recommended for user-facing flows): search_flight → fetch_fare_options → user picks a fare → create_itinerary with the selected fareId and price from fetch_fare_options. 2. Without fare family selection (internal client/testing flows): search_flight / search_flights_raw → extract fareId and price directly from the raw search response's fares map (using pricing.totalPricing.totalPrice) → create_itinerary. This skips fetch_fare_options entirely and uses the default/cheapest fare from search. When NOT to use: Do not use while the user is still comparing fare families/flights in a user-facing flow without explicit fare selection. For internal Cleartrip agent flows that use Redis-cached search data, use create_itinerary_info instead. Flow position: Requires: `search_flight` (or `search_flights_raw`) has already run. For user-facing flows, `fetch_fare_options` should also have been called and the user must pick a fare before calling. For internal flows, `fetch_fare_options` may be skipped if `fareId` and `price` are extracted directly from the search response. Next step: On success, use information from nextSteps—proceed to update_user_data (to fill out contact and traveller details from tripContext.expectedTravellers), then proceed_to_payment for payment and booking completion. Cancellation / amendment / ClearChoice: If the user then asks about cancellation charges, refunds, date change, or add-on cards (ClearChoice Max/Plus), call `get_itinerary_addon_cards` with the returned `itineraryId`—do not rely only on `fetch_fare_options` or `summary` for those topics. Returns (processed external response): itineraryId, infoUrl: Unique itinerary id and user-facing info page URL. `tripContext`: Structure including `cabin`, `expectedTravellers`, `specialFareType`, and `sectorType` (`domestic` / `international`). summary: Benefits summary for the selected fare, potentially including cancellationPolicyTable, dateChangePolicyTable, and display notes. `nextSteps`: Structured instructions for `update_user_data` then `proceed_to_payment`. Constraints: ⚠️ Special Restrictions: depart_date / return_date must use DD/MM/YYYY format (not YYYY-MM-DD). One-way: omit all `return_ parameters. * Round-trip: provide return_date plus return_travel_option_id, return_fare_id, return_price. card_id and return_card_id are optional; if either is set for round-trip, set both. Return-leg origin/destination are auto-swapped from the outbound. * fare_id / return_fare_id must be copied in full from fetch_fare_options or the search fares map (including any ~~V2 suffix); truncation causes backend errors. * **data_id** must be the complete top-level **dataId** from the same search response as fetch_fare_options (mandatory; same rule). Do not pass searchId`. Do not truncate or retype.
create_itinerary
ChatGPTcreate_itinerary - Create a bookable itinerary from flat parameter values (no Redis search/interstitial cache). Accepts simple scalar values — search_id, data_id, origin, destination, depart_date, travel_option_id, fare_id, price, optional card_id / return_card_id, and optional passenger/cabin/return-leg parameters — and assembles the Cleartrip payload internally. When to use: After search_flight has been called and a flight card has been selected. This is the itinerary-creation tool for external/OAuth clients using the stateless path. Can be called in two ways: 1. With fare family selection (recommended for user-facing flows): search_flight → fetch_fare_options → user picks a fare → create_itinerary with the selected fareId and price from fetch_fare_options. 2. Without fare family selection (internal client/testing flows): search_flight / search_flights_raw → extract fareId and price directly from the raw search response's fares map (using pricing.totalPricing.totalPrice) → create_itinerary. This skips fetch_fare_options entirely and uses the default/cheapest fare from search. When NOT to use: Do not use while the user is still comparing fare families/flights in a user-facing flow without explicit fare selection. For internal Cleartrip agent flows that use Redis-cached search data, use create_itinerary_info instead. Flow position: Requires: `search_flight` (or `search_flights_raw`) has already run. For user-facing flows, `fetch_fare_options` should also have been called and the user must pick a fare before calling. For internal flows, `fetch_fare_options` may be skipped if `fareId` and `price` are extracted directly from the search response. Next step: On success, use information from nextSteps—proceed to update_user_data (to fill out contact and traveller details from tripContext.expectedTravellers), then proceed_to_payment for payment and booking completion. Cancellation / amendment / ClearChoice: If the user then asks about cancellation charges, refunds, date change, or add-on cards (ClearChoice Max/Plus), call `get_itinerary_addon_cards` with the returned `itineraryId`—do not rely only on `fetch_fare_options` or `summary` for those topics. Returns (processed external response): itineraryId, infoUrl: Unique itinerary id and user-facing info page URL. `tripContext`: Structure including `cabin`, `expectedTravellers`, `specialFareType`, and `sectorType` (`domestic` / `international`). summary: Benefits summary for the selected fare, potentially including cancellationPolicyTable, dateChangePolicyTable, and display notes. `nextSteps`: Structured instructions for `update_user_data` then `proceed_to_payment`. Constraints: ⚠️ Special Restrictions: depart_date / return_date must use DD/MM/YYYY format (not YYYY-MM-DD). One-way: omit all `return_ parameters. * Round-trip: provide return_date plus return_travel_option_id, return_fare_id, return_price. card_id and return_card_id are optional; if either is set for round-trip, set both. Return-leg origin/destination are auto-swapped from the outbound. * fare_id / return_fare_id must be copied in full from fetch_fare_options or the search fares map (including any ~~V2 suffix); truncation causes backend errors. * **data_id** must be the complete top-level **dataId** from the same search response as fetch_fare_options (mandatory; same rule). Do not pass searchId`. Do not truncate or retype.
fetch_fare_options
ChatGPTfetch_fare_options - Stateless version of get_fare_options: fetch fare options (fare families/cards) for a specific flight selection without Redis dependency. Accepts simple parameters, builds the CT backend payload internally, and returns fare options without reading from or writing to Redis. When to use: After search_flight has been called and the user has selected a specific flight from the presented options. This is the fare-options tool for external/OAuth clients that use the stateless search_flight path. When NOT to use: Do not call for all flights at once; only fetch for the user's explicit selection. For internal Cleartrip agent flows that use Redis-cached search data, use get_fare_options instead. Flow position: Requires: A prior `search_flight` response in context. Extract: `travel_option_id` from the selected card; `data_id` must be the top-level `dataId` from that same response (mandatory opaque token, full copy — same string Cleartrip puts in the interstitial JSON field `dataId`). Example: `"dataId": "AVN+Z5...="` → pass `data_id` exactly that value; `searchId` (`DC_Search-...`) is a different field and must not be used as `data_id`. Also need `origin`, `destination`, `departure_date`. For round-trip J2 calls, also provide `j1_travel_option_id` and `onward_departure_date`. Also pass `search_id` (same response’s `searchId`, `DC_Search-…`) and optional `card_id` (selected card’s `cardId`) so the tool response echoes `searchId` / `cardId` for the embedded fare UI and for `create_itinerary`. Next step: Render fareComparisonTable using every column in requiredDisplayColumns. Wait for the user to pick a fare (fareId). Follow flowInstruction / nextSteps—do not auto-pick cheapest or call create_itinerary until the user confirms. Returns (processed response, same shape as get_fare_options): `fareOptions`: Full fare rows for the selected card—each includes `fareId` (booking key), `displayTitle` / `displaySubTitle`, `price`, `baseFare`, `taxes`, `brand`, `fareCategory`, `isCheapest`, `benefitTags`, baggage strings (`cabinBagPerAdult`, `checkInBagPerAdult`), seat/meal fields, and fee slots (`cancellationFee`, `dateChangeFee`). fareComparisonTable: Tabular data for display; use with requiredDisplayColumns for column ordering. `flightSummary`: Summary of the selected flight including `travelOptionId`, `subTravelOptionIds`. When search_id / card_id are supplied: response also includes searchId and/or cardId for downstream booking. `requiredDisplayColumns`: Ordered column names for the fare table. flowInstruction / nextSteps: Guidance for the next action. Post-itinerary: Once create_itinerary has succeeded, any user question about cancellation charges, refunds, amendment/date-change fees, or ClearChoice requires `get_itinerary_addon_cards` (itinerary_id) in addition to this tool’s fare rows; do not infer card-add-on terms from fareOptions alone. Display Rules: Present fare options in a tabular format using all columns from requiredDisplayColumns. Each row corresponds to a unique fare option. Present all fare options (do NOT auto-select or highlight the cheapest unless the user asks). Wait for the user to confirm their selection—only then proceed to create_itinerary. Constraints: ⚠️ Special Restrictions: Must be called individually for each journey leg: for round-trip, call separately for 'J1' (onward) and 'J2' (return). Only supply the user's explicit flight selection (never call for all possible flights). * Do not auto-select a fare. Always show all options to the user and wait for their input.
fetch_fare_options
ChatGPTfetch_fare_options - Stateless version of get_fare_options: fetch fare options (fare families/cards) for a specific flight selection without Redis dependency. Accepts simple parameters, builds the CT backend payload internally, and returns fare options without reading from or writing to Redis. When to use: After search_flight has been called and the user has selected a specific flight from the presented options. This is the fare-options tool for external/OAuth clients that use the stateless search_flight path. When NOT to use: Do not call for all flights at once; only fetch for the user's explicit selection. For internal Cleartrip agent flows that use Redis-cached search data, use get_fare_options instead. Flow position: Requires: A prior `search_flight` response in context. Extract: `travel_option_id` from the selected card; `data_id` must be the top-level `dataId` from that same response (mandatory opaque token, full copy — same string Cleartrip puts in the interstitial JSON field `dataId`). Example: `"dataId": "AVN+Z5...="` → pass `data_id` exactly that value; `searchId` (`DC_Search-...`) is a different field and must not be used as `data_id`. Also need `origin`, `destination`, `departure_date`. For round-trip J2 calls, also provide `j1_travel_option_id` and `onward_departure_date`. Also pass `search_id` (same response’s `searchId`, `DC_Search-…`) and optional `card_id` (selected card’s `cardId`) so the tool response echoes `searchId` / `cardId` for the embedded fare UI and for `create_itinerary`. Next step: Render fareComparisonTable using every column in requiredDisplayColumns. Wait for the user to pick a fare (fareId). Follow flowInstruction / nextSteps—do not auto-pick cheapest or call create_itinerary until the user confirms. Returns (processed response, same shape as get_fare_options): `fareOptions`: Full fare rows for the selected card—each includes `fareId` (booking key), `displayTitle` / `displaySubTitle`, `price`, `baseFare`, `taxes`, `brand`, `fareCategory`, `isCheapest`, `benefitTags`, baggage strings (`cabinBagPerAdult`, `checkInBagPerAdult`), seat/meal fields, and fee slots (`cancellationFee`, `dateChangeFee`). fareComparisonTable: Tabular data for display; use with requiredDisplayColumns for column ordering. `flightSummary`: Summary of the selected flight including `travelOptionId`, `subTravelOptionIds`. When search_id / card_id are supplied: response also includes searchId and/or cardId for downstream booking. `requiredDisplayColumns`: Ordered column names for the fare table. flowInstruction / nextSteps: Guidance for the next action. Post-itinerary: Once create_itinerary has succeeded, any user question about cancellation charges, refunds, amendment/date-change fees, or ClearChoice requires `get_itinerary_addon_cards` (itinerary_id) in addition to this tool’s fare rows; do not infer card-add-on terms from fareOptions alone. Display Rules: Present fare options in a tabular format using all columns from requiredDisplayColumns. Each row corresponds to a unique fare option. Present all fare options (do NOT auto-select or highlight the cheapest unless the user asks). Wait for the user to confirm their selection—only then proceed to create_itinerary. Constraints: ⚠️ Special Restrictions: Must be called individually for each journey leg: for round-trip, call separately for 'J1' (onward) and 'J2' (return). Only supply the user's explicit flight selection (never call for all possible flights). * Do not auto-select a fare. Always show all options to the user and wait for their input.
fetch_flight_benefits
ChatGPTfetch_flight_benefits - Stateless version of get_flight_benefits: fetch segment-level benefits for a selected international flight (baggage, penalties, meal/seat) without Redis dependency. Accepts flat parameters and builds the CT backend payload internally. When to use: After search_flight has been called for an international flight and the user has picked a card, and you need full cancellation/date-change windows, charges/refunds breakdown, or per-hop baggage details—typically alongside or after fetch_fare_options. This is the benefits tool for external/OAuth clients using the stateless path. When NOT to use: Domestic-only benefit comparison; prefer fetch_fare_options for fare-family grids. Do not call for every card—only the user's chosen itinerary. For internal Cleartrip agent flows that use Redis-cached search data, use get_flight_benefits instead. Flow position: Requires: A prior `search_flight` response for an international flight. Extract: `travel_option_id`, `sub_travel_option_id`, `origin`, `destination`, `fare_id` (from fare options), `departure_date`, `departure_time`, `per_pax_total_price`. Optional: `journey_id` (J1/J2), `departure_timezone`, passenger counts. Next step: Summarise benefits.segments for the user and present in a tabular format. When they are ready to book, follow flowInstruction / nextSteps (usually create_itinerary with the ids in the payload). Returns (processed response, similar shape to get_flight_benefits): `benefits`: Segment map keyed by route keys (e.g. `DEL_DXB`). Each segment includes `subTravelOptionId`, `subTravelOptionKey`, `benefitKey`, one-line `cancellationFee` / `dateChangeFee`, `cancellationPolicy` and `dateChangePolicy` (time-bounded windows with `fromDateTime` / `toDateTime`, `totalCharges`, `amountRefundable`, `chargesBreakup`), `benefitIds`, `mealDetails` / `seatDetails` (`chargeable`, `amount`, `description`), `cabinBagPerAdult` / `checkInBagPerAdult`, `baggageDetails` by pax type, and `flightBenefits` (per flight hop with `baggageAllowances`). flowInstruction: Guidance for the next action. Constraints: International supplementary detail only; round-trip: call per leg (`J1`, `J2`) when both need benefits. Prefer structured cancellationPolicy / dateChangePolicy and chargesBreakup when explaining fees.
fetch_flight_benefits
ChatGPTfetch_flight_benefits - Stateless version of get_flight_benefits: fetch segment-level benefits for a selected international flight (baggage, penalties, meal/seat) without Redis dependency. Accepts flat parameters and builds the CT backend payload internally. When to use: After search_flight has been called for an international flight and the user has picked a card, and you need full cancellation/date-change windows, charges/refunds breakdown, or per-hop baggage details—typically alongside or after fetch_fare_options. This is the benefits tool for external/OAuth clients using the stateless path. When NOT to use: Domestic-only benefit comparison; prefer fetch_fare_options for fare-family grids. Do not call for every card—only the user's chosen itinerary. For internal Cleartrip agent flows that use Redis-cached search data, use get_flight_benefits instead. Flow position: Requires: A prior `search_flight` response for an international flight. Extract: `travel_option_id`, `sub_travel_option_id`, `origin`, `destination`, `fare_id` (from fare options), `departure_date`, `departure_time`, `per_pax_total_price`. Optional: `journey_id` (J1/J2), `departure_timezone`, passenger counts. Next step: Summarise benefits.segments for the user and present in a tabular format. When they are ready to book, follow flowInstruction / nextSteps (usually create_itinerary with the ids in the payload). Returns (processed response, similar shape to get_flight_benefits): `benefits`: Segment map keyed by route keys (e.g. `DEL_DXB`). Each segment includes `subTravelOptionId`, `subTravelOptionKey`, `benefitKey`, one-line `cancellationFee` / `dateChangeFee`, `cancellationPolicy` and `dateChangePolicy` (time-bounded windows with `fromDateTime` / `toDateTime`, `totalCharges`, `amountRefundable`, `chargesBreakup`), `benefitIds`, `mealDetails` / `seatDetails` (`chargeable`, `amount`, `description`), `cabinBagPerAdult` / `checkInBagPerAdult`, `baggageDetails` by pax type, and `flightBenefits` (per flight hop with `baggageAllowances`). flowInstruction: Guidance for the next action. Constraints: International supplementary detail only; round-trip: call per leg (`J1`, `J2`) when both need benefits. Prefer structured cancellationPolicy / dateChangePolicy and chargesBreakup when explaining fees.
get_calendar_fares
ChatGPTget_calendar_fares - Fetch day-by-day fare calendar for a route (trend/pricing by date), not full flight inventory. When to use: User wants fare levels across dates—a whole month, or roughly a week around a specific day. When NOT to use: Listing specific flights, times, or cards (use search_flights_live). Flow position: Requires: `origin`, `destination` (IATA), `date` (`YYYY-MM-DD`). Set `around_specific_date`: `True` = ~7 days centered on `date`; `False` = full month containing `date` (e.g. “fares for June”). Next step: If user picks dates, run search_flights_live for concrete options. Returns: Per-day amounts (INR), `fareCategory` (CHEAPEST / AVERAGE / COSTLIER), and `dayData` mapping date strings to `{amount, fareCategory, tripSavings, events}`. Optional parameters: `travel_class`, `adults`, `children`, `infants`, `fare_calendar_type`, `number_of_days`. Display Rules: Present as a readable calendar or table by date—this is aggregate fare insight, not a substitute for live search.
get_calendar_fares
ChatGPTget_calendar_fares - Fetch day-by-day fare calendar for a route (trend/pricing by date), not full flight inventory. When to use: User wants fare levels across dates—a whole month, or roughly a week around a specific day. When NOT to use: Listing specific flights, times, or cards (use search_flights_live). Flow position: Requires: `origin`, `destination` (IATA), `date` (`YYYY-MM-DD`). Set `around_specific_date`: `True` = ~7 days centered on `date`; `False` = full month containing `date` (e.g. “fares for June”). Next step: If user picks dates, run search_flights_live for concrete options. Returns: Per-day amounts (INR), `fareCategory` (CHEAPEST / AVERAGE / COSTLIER), and `dayData` mapping date strings to `{amount, fareCategory, tripSavings, events}`. Optional parameters: `travel_class`, `adults`, `children`, `infants`, `fare_calendar_type`, `number_of_days`. Display Rules: Present as a readable calendar or table by date—this is aggregate fare insight, not a substitute for live search.
get_price_insights
ChatGPTget_price_insights - Analyze price trends for a route using search context and the cheapest observed fare to guide booking timing. When to use: After search_flights_live, when the user asks whether today’s price looks high/low vs history or typical range. When NOT to use: Without search parameters and a defensible cheapest-fare input; as a substitute for live availability. Flow position: Requires: `origin`, `destination`, dates, cabin, and cheapest fare derived from search. One-way: minimum `pricingPerAdult` across cards. Round-trip: minimum of (cheapest onward + cheapest return) or cheapest special round-trip bundle, per product rules. Next step: Share the narrative summary; user may still book via get_fare_options → create_itinerary_info. Returns: Trend verdict (e.g. higher/lower/in range), delta from median, sample size, pricing buckets, human-readable summary. Partial response: HTTP 206 when data is thin; error codes PI-001, PI-002, PI-003 explain insufficient or invalid inputs.
get_price_insights
ChatGPTget_price_insights - Analyze price trends for a route using search context and the cheapest observed fare to guide booking timing. When to use: After search_flights_live, when the user asks whether today’s price looks high/low vs history or typical range. When NOT to use: Without search parameters and a defensible cheapest-fare input; as a substitute for live availability. Flow position: Requires: `origin`, `destination`, dates, cabin, and cheapest fare derived from search. One-way: minimum `pricingPerAdult` across cards. Round-trip: minimum of (cheapest onward + cheapest return) or cheapest special round-trip bundle, per product rules. Next step: Share the narrative summary; user may still book via get_fare_options → create_itinerary_info. Returns: Trend verdict (e.g. higher/lower/in range), delta from median, sample size, pricing buckets, human-readable summary. Partial response: HTTP 206 when data is thin; error codes PI-001, PI-002, PI-003 explain insufficient or invalid inputs.
manage_auth
ChatGPTmanage_auth - Primary auth orchestrator for the flight booking flow: check login status, initiate OTP login, or logout. When to use: Before starting a booking or selfcare flow when you need to know or change login state; to send an OTP; or to log the user out. When NOT to use: To verify the OTP code (use verify_otp_login after a successful login). Flow position: Requires: `action` — one of `login_status`, `login`, `logout`. For `login`, `phone_number` (10 digits, Indian format, e.g. `9876543210`). Next step: After login succeeds and the user receives SMS, call verify_otp_login with the same phone_number and the 4-digit OTP. Returns: login_status: `loginStatus` `LOGGED_IN` or `NON_LOGGED_IN`. login: already_logged_in if already logged in; else OTP sent—then user must use verify_otp_login. logout: Clears session cookies; may return `already_logged_out`. Response also includes status, message, and next_step guidance. Each OAuth client_id has independent auth state. Constraints: * Typical flow: login_status → if logged out, login with phone → SMS OTP → verify_otp_login.
manage_auth
ChatGPTmanage_auth - Primary auth orchestrator for the flight booking flow: check login status, initiate OTP login, or logout. When to use: Before starting a booking or selfcare flow when you need to know or change login state; to send an OTP; or to log the user out. When NOT to use: To verify the OTP code (use verify_otp_login after a successful login). Flow position: Requires: `action` — one of `login_status`, `login`, `logout`. For `login`, `phone_number` (10 digits, Indian format, e.g. `9876543210`). Next step: After login succeeds and the user receives SMS, call verify_otp_login with the same phone_number and the 4-digit OTP. Returns: login_status: `loginStatus` `LOGGED_IN` or `NON_LOGGED_IN`. login: already_logged_in if already logged in; else OTP sent—then user must use verify_otp_login. logout: Clears session cookies; may return `already_logged_out`. Response also includes status, message, and next_step guidance. Each OAuth client_id has independent auth state. Constraints: * Typical flow: login_status → if logged out, login with phone → SMS OTP → verify_otp_login.
search_flight
ChatGPTsearch_flight - Live flight search with processed response (flights cards, searchId, totalFlightsAvailable, displaying, sortData, filterData, metaData, nextSteps, isRoundTrip). Does not write search data to Redis (pass-through). When to use: When a user requests real-time flight availability, pricing, or schedules between two cities and the client does not need server-cached search state (e.g. external/OAuth clients). This is the primary search tool for external clients. When NOT to use: If you only need to check the rules or final price of a flight the user has already selected (use fetch_fare_options instead). For internal Cleartrip agent flows that require Redis-cached search data downstream (e.g. get_fare_options, create_itinerary_info), use search_flights_live instead. Flow position: Requires: None (entry-point tool for external clients). Next step: After the user picks a card, call fetch_fare_options with identifiers from this response (see nextSteps in the payload). Never auto-select fares; present options and wait for explicit selection. Returns (processed external response): `searchId` (string): Readable correlation id (e.g. `DC_Search-<uuid>`); keep for logging and steps that explicitly require `search_id`. dataId (string): Required opaque token for fetch_fare_options / interstitial — pass this entire value as parameter `data_id` (never pass searchId as data_id; wrong id type causes HTTP 500). If dataId is absent from the response, run search_flight again; do not substitute searchId. `flights` (array): Result cards, each containing `journeyId`, `cardId` (stable index), `flights` (carrier/flight number label), `departure` / `arrival` (airport code, ISO time, terminal), `duration`, `stops`, `timeline`, `layovers`, `segments` (per-hop detail with `flightNumber`, `airlineCode`, `aircraftType`), `price` (total numeric fare), `currency`. totalFlightsAvailable / displaying: Count of flights found vs displayed. `sortData`, `filterData`: Available sort and filter options for the result set. metaData: Shared lookups — airlineDetail and airportDetail maps keyed by codes. `nextSteps`: Structured guidance for the next action (typically `fetch_fare_options`). Display Rules: The response must be displayed in a tabular format showing the first 10 rows of the cheapest flights. The results table must be sorted by increasing (cheapest) total price, with each row representing a single flight option. The table must include, at minimum, columns for flight code, airline, departure, arrival, duration, stops, and price. For round-trip searches, each journey leg should have its own table. Do not shorten, collapse, or otherwise compress the generated results table. Constraints: ⚠️ Special Restrictions: Cleartrip For Work fares are mutually exclusive with special_fare_type. You cannot combine these options in the same search. Origin (source) and destination airports cannot be the same; provide two distinct cities or airport codes. The search date must not be in the past; please provide a valid current or future date. * STUDENT and SENIOR_CITIZEN fares cannot be combined with children or infants.
search_flight
ChatGPTsearch_flight - Live flight search with processed response (flights cards, searchId, totalFlightsAvailable, displaying, sortData, filterData, metaData, nextSteps, isRoundTrip). Does not write search data to Redis (pass-through). When to use: When a user requests real-time flight availability, pricing, or schedules between two cities and the client does not need server-cached search state (e.g. external/OAuth clients). This is the primary search tool for external clients. When NOT to use: If you only need to check the rules or final price of a flight the user has already selected (use fetch_fare_options instead). For internal Cleartrip agent flows that require Redis-cached search data downstream (e.g. get_fare_options, create_itinerary_info), use search_flights_live instead. Flow position: Requires: None (entry-point tool for external clients). Next step: After the user picks a card, call fetch_fare_options with identifiers from this response (see nextSteps in the payload). Never auto-select fares; present options and wait for explicit selection. Returns (processed external response): `searchId` (string): Readable correlation id (e.g. `DC_Search-<uuid>`); keep for logging and steps that explicitly require `search_id`. dataId (string): Required opaque token for fetch_fare_options / interstitial — pass this entire value as parameter `data_id` (never pass searchId as data_id; wrong id type causes HTTP 500). If dataId is absent from the response, run search_flight again; do not substitute searchId. `flights` (array): Result cards, each containing `journeyId`, `cardId` (stable index), `flights` (carrier/flight number label), `departure` / `arrival` (airport code, ISO time, terminal), `duration`, `stops`, `timeline`, `layovers`, `segments` (per-hop detail with `flightNumber`, `airlineCode`, `aircraftType`), `price` (total numeric fare), `currency`. totalFlightsAvailable / displaying: Count of flights found vs displayed. `sortData`, `filterData`: Available sort and filter options for the result set. metaData: Shared lookups — airlineDetail and airportDetail maps keyed by codes. `nextSteps`: Structured guidance for the next action (typically `fetch_fare_options`). Display Rules: The response must be displayed in a tabular format showing the first 10 rows of the cheapest flights. The results table must be sorted by increasing (cheapest) total price, with each row representing a single flight option. The table must include, at minimum, columns for flight code, airline, departure, arrival, duration, stops, and price. For round-trip searches, each journey leg should have its own table. Do not shorten, collapse, or otherwise compress the generated results table. Constraints: ⚠️ Special Restrictions: Cleartrip For Work fares are mutually exclusive with special_fare_type. You cannot combine these options in the same search. Origin (source) and destination airports cannot be the same; provide two distinct cities or airport codes. The search date must not be in the past; please provide a valid current or future date. * STUDENT and SENIOR_CITIZEN fares cannot be combined with children or infants.
verify_otp_login
ChatGPTverify_otp_login - Complete OTP login (step 2): verify the SMS code and persist session cookies for the client. When to use: Immediately after manage_auth(action='login') succeeded and the user provides the 4-digit OTP from SMS. When NOT to use: Before an OTP was requested, or with a different phone_number than used in the login step. Flow position: Requires: `otp` (4-digit code) and `phone_number` (must match the `manage_auth` login request exactly). Next step: On success, proceed to flight search (search_flights_live) or other tools that need a logged-in session. Returns: Success: `loginStatus='LOGGED_IN'`, `mobile_number`, stored cookies for subsequent calls. Failure codes: invalid_otp, otp_expired (>5 minutes), phone_mismatch, max_attempts_exceeded (after 3 failures—request new OTP), no_otp_pending (call manage_auth login first). Constraints: * OTP valid for 5 minutes; after 3 failed attempts, request a new OTP via manage_auth.
verify_otp_login
ChatGPTverify_otp_login - Complete OTP login (step 2): verify the SMS code and persist session cookies for the client. When to use: Immediately after manage_auth(action='login') succeeded and the user provides the 4-digit OTP from SMS. When NOT to use: Before an OTP was requested, or with a different phone_number than used in the login step. Flow position: Requires: `otp` (4-digit code) and `phone_number` (must match the `manage_auth` login request exactly). Next step: On success, proceed to flight search (search_flights_live) or other tools that need a logged-in session. Returns: Success: `loginStatus='LOGGED_IN'`, `mobile_number`, stored cookies for subsequent calls. Failure codes: invalid_otp, otp_expired (>5 minutes), phone_mismatch, max_attempts_exceeded (after 3 failures—request new OTP), no_otp_pending (call manage_auth login first). Constraints: * OTP valid for 5 minutes; after 3 failed attempts, request a new OTP via manage_auth.
