Google Flights Search (Real-Time Fares)
Server Details
Real-time Google Flights fares for agents. Three things people do with this server. Scan for deals: one call takes a date range and a list of destination airports, expands every combination server side, and returns each fare with Google's own low, typical or high verdict. Put live search in your app: flat JSON with a bookable link on every result, and round trips priced as paired legs. Run a 24/7 AI travel agent: add the server, sign in with Google, and schedule it. No ads, no sponsored content. You bring your own RapidAPI key, so every search is billed to your plan and never to anyone else's. Add https://flights.flightpowers.com/mcp , click Sign in, sign in with Google, and paste your RapidAPI key once on the page that opens. Scripts and clients without a sign-in button send the key as x-rapidapi-key on the same URL.
- Status
- Healthy
- Uptime
- 100.0% over 64 days
- OAuth
- Works in Glama
- Last Tested
- Transport
- Streamable HTTP ยท MCP 2025-11-25
- URL
- Repository
- mtnrabi/google-flights-mcp
- GitHub Stars
- 1
- Server Listing
- google-flights-mcp
TDQS
Scored across 2 tools
The two tools split cleanly along trip type: one-way vs. round-trip, which is the single most natural axis for fare search. Descriptions reinforce the boundary with explicit 'use it for any one-way fare question' / 'use it for any return-trip fare question' guidance, so misselection is unlikely.
Both names follow the identical verb_noun pattern search_<triptype>_flights, using lowercase snake_case and parallel structure. No deviation in style or convention.
Two tools is on the thin side for a fare-search server, even though each is parameter-rich (date ranges, multiple destinations, trip lengths). The one-way/round-trip pair is defensible, but a third tool for multi-city or airport/date flexibility would round out the surface.
One-way and round-trip fare search cover the dominant booking flows, with good support for ranges, multiple destinations, and price insight metadata. The obvious gap is multi-city / open-jaw itineraries with three or more legs, which no tool handles.
Available Tools
2 toolssearch_oneway_flightsFlightPowers: search one-way flightsARead-onlyInspect
FlightPowers one-way fare search: live prices read from Google Flights. Input: origin and destination IATA codes -- the destination may be several codes, as "BCN,LIS,ATH" or ["BCN","LIS","ATH"] -- plus either one departure date or a date range. Returns each flight's price, airline, duration, stops, a bookable buy_link, and Google's historical price range (price_insights_low / price_insights_high) so you can say whether a fare is actually a good deal.
Use it for any one-way fare question, including open-ended ones. For a flexible search make ONE call with a date range and/or several destinations -- do NOT call it once per date. 'Cheapest flight to Sri Lanka anywhere in October' is one call, not thirty.
Each date/destination combination is one billed request; the count and the plan's remaining quota come back in api_usage.
by_destination carries one entry per destination you asked for -- empty ones included, each with a reason -- so read it before telling a user a destination has no flights.
Requires the caller's own RapidAPI key for the Google Flights Live API. Get one (free tier available) at https://rapidapi.com/mtnrabi/api/google-flights-live-api, then pass it as an x-rapidapi-key header (preferred), a ?rapidapi_key= query parameter on the server URL, or your client's own API key field -- first non-empty wins. Usage counts against the caller's own RapidAPI plan, not ours; every response reports what it spent and what is left in api_usage. No key? Sign in with Google and the first 10 searches each day are free on this server -- ad-free, nothing to paste. Connect your own RapidAPI key at https://flights.flightpowers.com/connect to remove the cap.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum flights to return, after merging and sorting. | |
| sort_by | No | "best", "price", or "duration". Applied across all results. | best |
| verbose | No | Return every field the upstream sends on each fare, and every fare that was selected, with no row bound. Off by default: a result carries the best rows by your sort_by in a compact shape (dates, destination, airline, stops, duration, price, trip length and the booking link), because a wide search over a month and several destinations otherwise produces a megabyte of JSON that some hosts refuse to put in the conversation at all. Turn it on when you need the arrival times, the per-leg stop counts, the raw stop details or more rows than results_returned; results_total always says how many there were. | |
| currency | No | ISO currency code, default "usd". | usd |
| max_price | No | Only return flights at or below this price. | |
| max_stops | No | Maximum stops per flight. 0 means non-stop only. | |
| seat_type | No | 1 economy, 2 premium economy, 3 business, 4 first. | |
| passengers | No | One entry per traveller, not a count: 1 adult, 2 child (aged 2-11), 3 infant on lap, 4 infant in seat, e.g. [1, 1, 2] for two adults and a child. At least one adult, each infant on lap needs its own adult, at most 9. Omit for one adult. A counts list [adults, children, infants], e.g. [2, 1, 0], or a bare [2] for two adults, is recognised and converted to codes before the search; a list that is valid as codes is searched as codes. | |
| to_airport | Yes | Destination airport. One IATA code ("BCN"), several separated by commas ("BCN,LIS,ATH"), or a list (["BCN","LIS","ATH"]) -- every shape is accepted and the destinations are compared in the same search. | |
| from_airport | Yes | Origin IATA code, e.g. "TLV". One origin per search; a second one is refused rather than searched. | |
| max_searches | No | The billed requests this call may make, up or down. Leave it out for the normal behaviour: the cap covers the request when the request is reasonable (a whole month at three trip lengths is 93 combinations and a whole month x 3 nights x 3 destinations is 279; both run in full) and anything past it is sampled evenly across the range rather than cut short. Set it lower to spend less of the plan's quota on a wide search, or higher -- to a hard maximum of 300 -- for a grid wider than that. | |
| use_fallback | No | Leave unset. Switches the search to a second, independent flight data source instead of the usual Google Flights page read. Unset already escalates to that source once, automatically, after a search's retries have failed. true forces it inline on every attempt -- much slower, and it can time out. false disables it entirely, that automatic retry included. | |
| airline_codes | No | Restrict to these airline codes, e.g. ["LY"]. | |
| departure_date | No | Single departure date, "YYYY-MM-DD". | |
| arrival_time_max | No | Latest arrival hour, 0-23. | |
| arrival_time_min | No | Earliest arrival hour, 0-23. | |
| departure_date_to | No | Last date of a departure range. | |
| departure_time_max | No | Latest departure hour, 0-23. | |
| departure_time_min | No | Earliest departure hour, 0-23. | |
| departure_date_from | No | First date of a departure range. | |
| exclude_airline_codes | No | Exclude these airline codes. |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | No | Present when there is something the model must relay to the user rather than silently absorb -- no results, a degraded search, a missing key or a spent quota. |
| partial | No | Present when some searches failed but others succeeded. Plain text saying how much of the request the results cover. |
| results | Yes | The fares found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'. This is the TOP results_returned of results_total rows by the sort you asked for -- cheapest first by default, shortest first on sort_by 'duration' -- with every destination that has fares still represented. Each row is in a compact shape: destination, the date or dates, trip length in nights on a round trip, airline (both legs on a round trip), stops, duration, the price as a string and a number, Google's price band with its verdict, and the booking link. The origin is on the response as from_airport rather than repeated on every row. Arrival descriptions, per-leg stop counts, raw stop details and the duration in seconds are dropped; `verbose: true` returns them, and every row that was selected, on that call. |
| api_usage | No | What this call cost the caller's own RapidAPI plan, and what remains on it. Present on every response that reached the upstream, including a degraded one -- a search that failed was still billed. |
| signup_url | No | Where the caller subscribes or changes plan. |
| from_airport | No | The origin, as the upstream renders it ('Tel Aviv (TLV)'). One origin per search, so it is on the response rather than repeated on every row. |
| result_count | No | How many rows are in `results`; same as results_returned. |
| needs_api_key | No | True when no usable RapidAPI key arrived with the call, or the upstream rejected the one that did. No search was run and nothing was billed; signup_url and message say how to fix it. |
| results_total | No | How many fares the search selected across every searched combination, before any row bound. Equal to results_returned unless the server bounded a response it had widened itself. |
| search_status | No | Whether the underlying search actually completed, read from the backend's X-Search-Status header. 'ok': every combination searched returned results. 'empty': the search completed and Google genuinely has no itineraries for it -- a real answer, not a failure. 'partial': some combinations returned results and some failed, so the list is incomplete. 'degraded': every combination failed, so the search did not happen and an empty list means nothing; this case is also flagged with isError: true and is safe to retry. 'trial_exhausted': the free signed-in allowance on this server is spent for today, so nothing was searched and nothing was billed; it renews at 00:00 UTC and connecting your own RapidAPI key removes the cap. Retrying does not help. 'quota_exceeded': the search was refused because the caller's remaining allowance or plan quota cannot cover the number of combinations asked for; combos_requested and combos_allowed_now carry the two numbers. Nothing was searched beyond what it cost to read the quota. Retrying the same search does not help -- ask for fewer dates or nights, or move to a larger plan. |
| by_destination | No | One entry per destination the REQUEST asked for, in request order, present whether or not that destination has any flights in `results`. A destination with an empty `rows` array is a hole in the answer, and `reason` says which kind of hole: 'no_flights' (searched, answered, Google has nothing), 'search_failed' (searched and the search errored, so nothing is known), 'not_in_limit' (searched, found flights, none fitted in `limit`) or 'not_searched' (never searched -- the per-call fan-out cap sampled it away). 'ok' means it has rows. Read this rather than inferring coverage from `results`: a destination missing from `results` looks identical to one that has no flights, and they are not the same answer. `row_count` is how many of this destination's fares were selected; the fares themselves are in `results` and are not repeated here. `verbose: true` restores the `rows` array for callers that read it. |
| quota_exhausted | No | True when the caller's RapidAPI plan has no requests left for the current period. |
| search_coverage | No | What was actually searched. Present whether or not the request was truncated, so a model can state honestly what its answer rests on. |
| results_returned | No | How many of them are in `results` -- the best ones by the sort_by asked for, cheapest first by default, and never all of one destination at the expense of another. Lower than results_total only when `limit` was raised by the server to cover the fan-out rather than asked for; search_coverage.note says so when it happens, and `verbose: true` returns them all. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses the caller-supplied RapidAPI key requirement and the three accepted key channels, free-tier quota behavior, per-date/destination billing, the api_usage quota report, and the by_destination empty-entry-plus-reason convention. These are real operational traits an agent must know before calling, not restatements of readOnlyHint/openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well front-loaded with purpose then usage, but it runs six paragraphs and repeats material already in the schema (the 'BCN,LIS,ATH' destination formats appear in both) and mentions api_usage twice. The RapidAPI signup/marketing paragraph ('ad-free, nothing to paste') is longer than the operational need requires.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 21-parameter tool with an output schema, the description supplies the missing pieces: auth channel, billing/quota semantics, flexible-search strategy, and the by_destination/reason edge case. Nothing an agent needs to call it correctly and interpret the response is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (max_searches escalation, verbose, passengers code formats, etc.) is already documented in the schema; baseline is 3. The description's own parameter-level content is largely duplicated from the schema (destination code formats), adding little meaning beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('one-way fare search: live prices read from Google Flights') and the one-way framing cleanly separates it from the sibling search_roundtrip_flights. An agent can tell what it does and which of the two flight tools it needs without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('any one-way fare question, including open-ended ones') and a concrete when-not for invocation pattern ('make ONE call with a date range... do NOT call it once per date', with the Sri Lanka example). It never names search_roundtrip_flights as the alternative for round-trip questions, so routing between the two siblings is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_roundtrip_flightsFlightPowers: search round-trip flightsARead-onlyInspect
FlightPowers round-trip fare search: live prices read from Google Flights, priced as paired legs rather than two separate one-ways. Input: origin and destination IATA codes -- the destination may be several codes, as "BCN,LIS,ATH" or ["BCN","LIS","ATH"] -- a departure date or range, and either a return date or a trip length in nights. Returns the total price for both legs, per-leg airline, stops and duration, and a single bookable buy_link for the trip.
Use it for any return-trip fare question. For a flexible search make ONE call: pass departure_date_from / departure_date_to for the outbound range and nights instead of return_date to compare trip lengths -- '5 to 7 nights in Rome sometime in May' is one call.
A WHOLE MONTH is one call too. departure_date_from "2026-10-01", departure_date_to "2026-10-31" and nights [3, 4, 5] prices every departure day in October at three trip lengths and tells you which combination is cheapest. That is 93 date/night combinations and the cap rises to cover them by itself -- do not narrow the question to make it fit, and do not split it into several calls.
Each date/night/destination combination is ONE request billed to the caller's plan, so a month at three trip lengths costs 93 of them and the same month across two destinations costs 186. Say that number before running a search that large if the user has not asked for it in so many words. A search that fails with a server error is retried once and RapidAPI bills the retry, so the figure to quote back is api_usage.hub_requests_billed (what the plan was actually charged), not the combination count. Both come back in api_usage, with the plan's remaining quota.
by_destination carries one entry per destination you asked for -- empty ones included, each with a reason -- so read it before telling a user a destination has no flights.
Requires the caller's own RapidAPI key for the Google Flights Live API. Get one (free tier available) at https://rapidapi.com/mtnrabi/api/google-flights-live-api, then pass it as an x-rapidapi-key header (preferred), a ?rapidapi_key= query parameter on the server URL, or your client's own API key field -- first non-empty wins. Usage counts against the caller's own RapidAPI plan, not ours; every response reports what it spent and what is left in api_usage. No key? Sign in with Google and the first 10 searches each day are free on this server -- ad-free, nothing to paste. Connect your own RapidAPI key at https://flights.flightpowers.com/connect to remove the cap.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum trips to return, after merging and sorting. | |
| nights | No | Trip length in nights; a number, or a list like [5, 6, 7]. The return date is derived from each departure date. | |
| sort_by | No | "best", "price", or "duration". Applied across all results. | best |
| verbose | No | Return every field the upstream sends on each fare, and every fare that was selected, with no row bound. Off by default: a result carries the best rows by your sort_by in a compact shape (dates, destination, airline, stops, duration, price, trip length and the booking link), because a wide search over a month and several destinations otherwise produces a megabyte of JSON that some hosts refuse to put in the conversation at all. Turn it on when you need the arrival times, the per-leg stop counts, the raw stop details or more rows than results_returned; results_total always says how many there were. | |
| currency | No | ISO currency code, default "usd". | usd |
| max_price | No | Only return trips at or below this total price. | |
| seat_type | No | 1 economy, 2 premium economy, 3 business, 4 first. | |
| passengers | No | One entry per traveller, not a count: 1 adult, 2 child (aged 2-11), 3 infant on lap, 4 infant in seat, e.g. [1, 1, 2] for two adults and a child. At least one adult, each infant on lap needs its own adult, at most 9. Omit for one adult. A counts list [adults, children, infants], e.g. [2, 1, 0], or a bare [2] for two adults, is recognised and converted to codes before the search; a list that is valid as codes is searched as codes. | |
| to_airport | Yes | Destination airport. One IATA code ("BCN"), several separated by commas ("BCN,LIS,ATH"), or a list (["BCN","LIS","ATH"]) -- every shape is accepted and the destinations are compared in the same search. | |
| return_date | No | Fixed return date. Use this OR nights, not both. | |
| from_airport | Yes | Origin IATA code, e.g. "TLV". One origin per search; a second one is refused rather than searched. | |
| max_searches | No | The billed requests this call may make, up or down. Leave it out for the normal behaviour: the cap covers the request when the request is reasonable (a whole month at three trip lengths is 93 combinations and a whole month x 3 nights x 3 destinations is 279; both run in full) and anything past it is sampled evenly across the range rather than cut short. Set it lower to spend less of the plan's quota on a wide search, or higher -- to a hard maximum of 300 -- for a grid wider than that. | |
| use_fallback | No | Leave unset. Switches the search to a second, independent flight data source instead of the usual Google Flights page read. Unset already escalates to that source once, automatically, after a search's retries have failed. true forces it inline on every attempt -- much slower, and it can time out. false disables it entirely, that automatic retry included. | |
| departure_date | No | Single outbound date, "YYYY-MM-DD". | |
| max_return_stops | No | Maximum stops on the return leg. | |
| departure_date_to | No | Last date of an outbound range. | |
| departure_date_from | No | First date of an outbound range. | |
| max_departure_stops | No | Maximum stops on the outbound leg. | |
| return_airline_codes | No | Restrict the return leg to these airlines. | |
| returns_per_outbound | No | How many return flights to pair with each outbound flight, 1 to 5 (default 2). Each date/destination combination searched still returns at most 10 trips; at 5 they are picked from up to 50 pairings instead of 20. It adds no requests. Not applied when results come from the fallback source. | |
| departure_airline_codes | No | Restrict the outbound leg to these airlines. |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | No | Present when there is something the model must relay to the user rather than silently absorb -- no results, a degraded search, a missing key or a spent quota. |
| partial | No | Present when some searches failed but others succeeded. Plain text saying how much of the request the results cover. |
| results | Yes | The fares found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'. This is the TOP results_returned of results_total rows by the sort you asked for -- cheapest first by default, shortest first on sort_by 'duration' -- with every destination that has fares still represented. Each row is in a compact shape: destination, the date or dates, trip length in nights on a round trip, airline (both legs on a round trip), stops, duration, the price as a string and a number, Google's price band with its verdict, and the booking link. The origin is on the response as from_airport rather than repeated on every row. Arrival descriptions, per-leg stop counts, raw stop details and the duration in seconds are dropped; `verbose: true` returns them, and every row that was selected, on that call. |
| api_usage | No | What this call cost the caller's own RapidAPI plan, and what remains on it. Present on every response that reached the upstream, including a degraded one -- a search that failed was still billed. |
| signup_url | No | Where the caller subscribes or changes plan. |
| from_airport | No | The origin, as the upstream renders it ('Tel Aviv (TLV)'). One origin per search, so it is on the response rather than repeated on every row. |
| result_count | No | How many rows are in `results`; same as results_returned. |
| needs_api_key | No | True when no usable RapidAPI key arrived with the call, or the upstream rejected the one that did. No search was run and nothing was billed; signup_url and message say how to fix it. |
| results_total | No | How many fares the search selected across every searched combination, before any row bound. Equal to results_returned unless the server bounded a response it had widened itself. |
| search_status | No | Whether the underlying search actually completed, read from the backend's X-Search-Status header. 'ok': every combination searched returned results. 'empty': the search completed and Google genuinely has no itineraries for it -- a real answer, not a failure. 'partial': some combinations returned results and some failed, so the list is incomplete. 'degraded': every combination failed, so the search did not happen and an empty list means nothing; this case is also flagged with isError: true and is safe to retry. 'trial_exhausted': the free signed-in allowance on this server is spent for today, so nothing was searched and nothing was billed; it renews at 00:00 UTC and connecting your own RapidAPI key removes the cap. Retrying does not help. 'quota_exceeded': the search was refused because the caller's remaining allowance or plan quota cannot cover the number of combinations asked for; combos_requested and combos_allowed_now carry the two numbers. Nothing was searched beyond what it cost to read the quota. Retrying the same search does not help -- ask for fewer dates or nights, or move to a larger plan. |
| by_destination | No | One entry per destination the REQUEST asked for, in request order, present whether or not that destination has any flights in `results`. A destination with an empty `rows` array is a hole in the answer, and `reason` says which kind of hole: 'no_flights' (searched, answered, Google has nothing), 'search_failed' (searched and the search errored, so nothing is known), 'not_in_limit' (searched, found flights, none fitted in `limit`) or 'not_searched' (never searched -- the per-call fan-out cap sampled it away). 'ok' means it has rows. Read this rather than inferring coverage from `results`: a destination missing from `results` looks identical to one that has no flights, and they are not the same answer. `row_count` is how many of this destination's fares were selected; the fares themselves are in `results` and are not repeated here. `verbose: true` restores the `rows` array for callers that read it. |
| quota_exhausted | No | True when the caller's RapidAPI plan has no requests left for the current period. |
| search_coverage | No | What was actually searched. Present whether or not the request was truncated, so a model can state honestly what its answer rests on. |
| results_returned | No | How many of them are in `results` -- the best ones by the sort_by asked for, cheapest first by default, and never all of one destination at the expense of another. Lower than results_total only when `limit` was raised by the server to cover the fan-out rather than asked for; search_coverage.note says so when it happens, and `verbose: true` returns them all. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations (readOnly/openWorld/non-idempotent): it discloses the per-combination billing model (93 combos for a month at three trip lengths), that failed searches are retried once and the retry is billed, that api_usage.hub_requests_billed is the number to quote, that by_destination includes empty entries with a reason, and the full auth path (x-rapidapi-key header, query param, client field, free Google-sign-in tier). That is exactly the operational context annotations cannot carry, and nothing contradicts readOnlyHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then call-shaping, then cost/auth. It is long but each paragraph carries distinct operational value; the deduction is for mild redundancy, since the billing/api_usage accounting is restated in both the cost paragraph and the RapidAPI-key paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 21-parameter, open-world, billable search with an output schema present, the description covers everything an agent needs before calling: required inputs, the one-call strategies, cost and consent expectations, cap behavior, fallback behavior, and authentication. Return-value details are correctly left to the output schema rather than duplicated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; the description nonetheless adds cross-parameter meaning the schema does not, notably the departure_date_from/departure_date_to + nights pairing pattern, use_fallback's 'Leave unset' escalation behavior, from_airport being single-or-refused, and max_searches auto-rising to cover a reasonable grid (hard max 300). It does not add format detail the schema lacks for most other fields, so it sits just above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('round-trip fare search: live prices read from Google Flights') and immediately distinguishes itself from the sibling by scope: 'priced as paired legs rather than two separate one-ways.' It also names the concrete return payload (total price for both legs, per-leg airline, stops, duration, buy_link), so an agent can identify it against search_oneway_flights without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing ('Use it for any return-trip fare question') and concrete call-shaping rules: one call for a flexible search via departure_date_from/to plus nights, one call for a whole month, and an explicit instruction not to narrow or split. It never names search_oneway_flights as the alternative, so the when-not side is left to inference, which holds it at 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
search_roundtrip_flights1 field changed- added
Input schema / properties / returns_per_outboundAdded value: +{ + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "description": "How many return flights to pair with each outbound flight, 1 to 5 (default 2). Each date/destination combination searched still returns at most 10 trips; at 5 they are picked from up to 50 pairings instead of 20. It adds no requests. Not applied when results come from the fallback source." +}
2 tool updates
- Changed
search_oneway_flights1 field changed- changed
Input schema / properties / passengers / descriptionPrevious value: -"One entry per traveller, not a count: 1 adult, 2 child (aged 2-11), 3 infant on lap, 4 infant in seat, e.g. [1, 1, 2] for two adults and a child. At least one adult, each infant on lap needs its own adult, at most 9. Omit for one adult."New value: +"One entry per traveller, not a count: 1 adult, 2 child (aged 2-11), 3 infant on lap, 4 infant in seat, e.g. [1, 1, 2] for two adults and a child. At least one adult, each infant on lap needs its own adult, at most 9. Omit for one adult. A counts list [adults, children, infants], e.g. [2, 1, 0], or a bare [2] for two adults, is recognised and converted to codes before the search; a list that is valid as codes is searched as codes."
- Changed
search_roundtrip_flights1 field changed- changed
Input schema / properties / passengers / descriptionPrevious value: -"One entry per traveller, not a count: 1 adult, 2 child (aged 2-11), 3 infant on lap, 4 infant in seat, e.g. [1, 1, 2] for two adults and a child. At least one adult, each infant on lap needs its own adult, at most 9. Omit for one adult."New value: +"One entry per traveller, not a count: 1 adult, 2 child (aged 2-11), 3 infant on lap, 4 infant in seat, e.g. [1, 1, 2] for two adults and a child. At least one adult, each infant on lap needs its own adult, at most 9. Omit for one adult. A counts list [adults, children, infants], e.g. [2, 1, 0], or a bare [2] for two adults, is recognised and converted to codes before the search; a list that is valid as codes is searched as codes."
2 tool updates
- Changed
search_oneway_flights1 field changed- changed
Input schema / properties / passengers / descriptionPrevious value: -"Passenger counts as [adults, children, infants]."New value: +"One entry per traveller, not a count: 1 adult, 2 child (aged 2-11), 3 infant on lap, 4 infant in seat, e.g. [1, 1, 2] for two adults and a child. At least one adult, each infant on lap needs its own adult, at most 9. Omit for one adult."
- Changed
search_roundtrip_flights1 field changed- changed
Input schema / properties / passengers / descriptionPrevious value: -"Passenger counts as [adults, children, infants]."New value: +"One entry per traveller, not a count: 1 adult, 2 child (aged 2-11), 3 infant on lap, 4 infant in seat, e.g. [1, 1, 2] for two adults and a child. At least one adult, each infant on lap needs its own adult, at most 9. Omit for one adult."
2 tool updates
- Changed
search_oneway_flights10 fields changed- added
Input schema / properties / verboseAdded value: +{ + "default": false, + "description": "Return every field the upstream sends on each fare, and every fare that was selected, with no row bound. Off by default: a result carries the best rows by your sort_by in a compact shape (dates, destination, airline, stops, duration, price, trip length and the booking link), because a wide search over a month and several destinations otherwise produces a megabyte of JSON that some hosts refuse to put in the conversation at all. Turn it on when you need the arrival times, the per-leg stop counts, the raw stop details or more rows than results_returned; results_total always says how many there were.", + "type": "boolean" +} - added
Output schema / properties / by_destination / additionalProperties / properties / row_countAdded value: +{ + "description": "How many of this destination's fares were selected. Not all of them are necessarily in `results`: a wide search returns the top results_returned of results_total overall, and `cheapest` below is this destination's own best fare either way.", + "minimum": 0, + "type": "integer" +} - added
Output schema / properties / by_destination / additionalProperties / properties / rows / descriptionAdded value: +"Only on `verbose: true`: this destination's selected rows, the same objects that are in `results`." - changed
Output schema / properties / by_destination / additionalProperties / requiredPrevious value: -[ - "rows", - "searched", - "reason" -]New value: +[ + "row_count", + "searched", + "reason" +] - changed
Output schema / properties / by_destination / descriptionPrevious value: -"One entry per destination the REQUEST asked for, in request order, present whether or not that destination has any flights in `results`. A destination with an empty `rows` array is a hole in the answer, and `reason` says which kind of hole: 'no_flights' (searched, answered, Google has nothing), 'search_failed' (searched and the search errored, so nothing is known), 'not_in_limit' (searched, found flights, none fitted in `limit`) or 'not_searched' (never searched -- the per-call fan-out cap sampled it away). 'ok' means it has rows.\n\nRead this rather than inferring coverage from `results`: a destination missing from `results` looks identical to one that has no flights, and they are not the same answer. `rows` are the same row objects that are in `results`, in the same order -- nothing here is data the answer does not already contain."New value: +"One entry per destination the REQUEST asked for, in request order, present whether or not that destination has any flights in `results`. A destination with an empty `rows` array is a hole in the answer, and `reason` says which kind of hole: 'no_flights' (searched, answered, Google has nothing), 'search_failed' (searched and the search errored, so nothing is known), 'not_in_limit' (searched, found flights, none fitted in `limit`) or 'not_searched' (never searched -- the per-call fan-out cap sampled it away). 'ok' means it has rows.\n\nRead this rather than inferring coverage from `results`: a destination missing from `results` looks identical to one that has no flights, and they are not the same answer. `row_count` is how many of this destination's fares were selected; the fares themselves are in `results` and are not repeated here. `verbose: true` restores the `rows` array for callers that read it." - added
Output schema / properties / from_airportAdded value: +{ + "description": "The origin, as the upstream renders it ('Tel Aviv (TLV)'). One origin per search, so it is on the response rather than repeated on every row.", + "type": "string" +} - added
Output schema / properties / result_count / descriptionAdded value: +"How many rows are in `results`; same as results_returned." - changed
Output schema / properties / results / descriptionPrevious value: -"The itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'."New value: +"The fares found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'.\n\nThis is the TOP results_returned of results_total rows by the sort you asked for -- cheapest first by default, shortest first on sort_by 'duration' -- with every destination that has fares still represented. Each row is in a compact shape: destination, the date or dates, trip length in nights on a round trip, airline (both legs on a round trip), stops, duration, the price as a string and a number, Google's price band with its verdict, and the booking link. The origin is on the response as from_airport rather than repeated on every row. Arrival descriptions, per-leg stop counts, raw stop details and the duration in seconds are dropped; `verbose: true` returns them, and every row that was selected, on that call." - added
Output schema / properties / results_returnedAdded value: +{ + "description": "How many of them are in `results` -- the best ones by the sort_by asked for, cheapest first by default, and never all of one destination at the expense of another. Lower than results_total only when `limit` was raised by the server to cover the fan-out rather than asked for; search_coverage.note says so when it happens, and `verbose: true` returns them all.", + "minimum": 0, + "type": "integer" +} - added
Output schema / properties / results_totalAdded value: +{ + "description": "How many fares the search selected across every searched combination, before any row bound. Equal to results_returned unless the server bounded a response it had widened itself.", + "minimum": 0, + "type": "integer" +}
- Changed
search_roundtrip_flights10 fields changed- added
Input schema / properties / verboseAdded value: +{ + "default": false, + "description": "Return every field the upstream sends on each fare, and every fare that was selected, with no row bound. Off by default: a result carries the best rows by your sort_by in a compact shape (dates, destination, airline, stops, duration, price, trip length and the booking link), because a wide search over a month and several destinations otherwise produces a megabyte of JSON that some hosts refuse to put in the conversation at all. Turn it on when you need the arrival times, the per-leg stop counts, the raw stop details or more rows than results_returned; results_total always says how many there were.", + "type": "boolean" +} - added
Output schema / properties / by_destination / additionalProperties / properties / row_countAdded value: +{ + "description": "How many of this destination's fares were selected. Not all of them are necessarily in `results`: a wide search returns the top results_returned of results_total overall, and `cheapest` below is this destination's own best fare either way.", + "minimum": 0, + "type": "integer" +} - added
Output schema / properties / by_destination / additionalProperties / properties / rows / descriptionAdded value: +"Only on `verbose: true`: this destination's selected rows, the same objects that are in `results`." - changed
Output schema / properties / by_destination / additionalProperties / requiredPrevious value: -[ - "rows", - "searched", - "reason" -]New value: +[ + "row_count", + "searched", + "reason" +] - changed
Output schema / properties / by_destination / descriptionPrevious value: -"One entry per destination the REQUEST asked for, in request order, present whether or not that destination has any flights in `results`. A destination with an empty `rows` array is a hole in the answer, and `reason` says which kind of hole: 'no_flights' (searched, answered, Google has nothing), 'search_failed' (searched and the search errored, so nothing is known), 'not_in_limit' (searched, found flights, none fitted in `limit`) or 'not_searched' (never searched -- the per-call fan-out cap sampled it away). 'ok' means it has rows.\n\nRead this rather than inferring coverage from `results`: a destination missing from `results` looks identical to one that has no flights, and they are not the same answer. `rows` are the same row objects that are in `results`, in the same order -- nothing here is data the answer does not already contain."New value: +"One entry per destination the REQUEST asked for, in request order, present whether or not that destination has any flights in `results`. A destination with an empty `rows` array is a hole in the answer, and `reason` says which kind of hole: 'no_flights' (searched, answered, Google has nothing), 'search_failed' (searched and the search errored, so nothing is known), 'not_in_limit' (searched, found flights, none fitted in `limit`) or 'not_searched' (never searched -- the per-call fan-out cap sampled it away). 'ok' means it has rows.\n\nRead this rather than inferring coverage from `results`: a destination missing from `results` looks identical to one that has no flights, and they are not the same answer. `row_count` is how many of this destination's fares were selected; the fares themselves are in `results` and are not repeated here. `verbose: true` restores the `rows` array for callers that read it." - added
Output schema / properties / from_airportAdded value: +{ + "description": "The origin, as the upstream renders it ('Tel Aviv (TLV)'). One origin per search, so it is on the response rather than repeated on every row.", + "type": "string" +} - added
Output schema / properties / result_count / descriptionAdded value: +"How many rows are in `results`; same as results_returned." - changed
Output schema / properties / results / descriptionPrevious value: -"The itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'."New value: +"The fares found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'.\n\nThis is the TOP results_returned of results_total rows by the sort you asked for -- cheapest first by default, shortest first on sort_by 'duration' -- with every destination that has fares still represented. Each row is in a compact shape: destination, the date or dates, trip length in nights on a round trip, airline (both legs on a round trip), stops, duration, the price as a string and a number, Google's price band with its verdict, and the booking link. The origin is on the response as from_airport rather than repeated on every row. Arrival descriptions, per-leg stop counts, raw stop details and the duration in seconds are dropped; `verbose: true` returns them, and every row that was selected, on that call." - added
Output schema / properties / results_returnedAdded value: +{ + "description": "How many of them are in `results` -- the best ones by the sort_by asked for, cheapest first by default, and never all of one destination at the expense of another. Lower than results_total only when `limit` was raised by the server to cover the fan-out rather than asked for; search_coverage.note says so when it happens, and `verbose: true` returns them all.", + "minimum": 0, + "type": "integer" +} - added
Output schema / properties / results_totalAdded value: +{ + "description": "How many fares the search selected across every searched combination, before any row bound. Equal to results_returned unless the server bounded a response it had widened itself.", + "minimum": 0, + "type": "integer" +}
2 tool updates
- Changed
search_oneway_flights1 field changed- changed
Input schema / properties / max_searches / descriptionPrevious value: -"The billed requests this call may make, up or down. Leave it out for the normal behaviour: the cap covers the request when the request is reasonable (a whole month at three trip lengths, 93 combinations, runs in full) and anything past it is sampled evenly across the range rather than cut short. Set it lower to spend less of the plan's quota on a wide search, or higher -- to a hard maximum of 200 -- for a grid wider than that."New value: +"The billed requests this call may make, up or down. Leave it out for the normal behaviour: the cap covers the request when the request is reasonable (a whole month at three trip lengths is 93 combinations and a whole month x 3 nights x 3 destinations is 279; both run in full) and anything past it is sampled evenly across the range rather than cut short. Set it lower to spend less of the plan's quota on a wide search, or higher -- to a hard maximum of 300 -- for a grid wider than that."
- Changed
search_roundtrip_flights1 field changed- changed
Input schema / properties / max_searches / descriptionPrevious value: -"The billed requests this call may make, up or down. Leave it out for the normal behaviour: the cap covers the request when the request is reasonable (a whole month at three trip lengths, 93 combinations, runs in full) and anything past it is sampled evenly across the range rather than cut short. Set it lower to spend less of the plan's quota on a wide search, or higher -- to a hard maximum of 200 -- for a grid wider than that."New value: +"The billed requests this call may make, up or down. Leave it out for the normal behaviour: the cap covers the request when the request is reasonable (a whole month at three trip lengths is 93 combinations and a whole month x 3 nights x 3 destinations is 279; both run in full) and anything past it is sampled evenly across the range rather than cut short. Set it lower to spend less of the plan's quota on a wide search, or higher -- to a hard maximum of 300 -- for a grid wider than that."
2 tool updates
- Changed
search_oneway_flights7 fields changed- changed
Input schema / properties / max_searches / descriptionPrevious value: -"Cap the billed requests this call may make. Lower it to spend less of the plan's quota on a wide search; the range is then sampled evenly rather than cut short."New value: +"The billed requests this call may make, up or down. Leave it out for the normal behaviour: the cap covers the request when the request is reasonable (a whole month at three trip lengths, 93 combinations, runs in full) and anything past it is sampled evenly across the range rather than cut short. Set it lower to spend less of the plan's quota on a wide search, or higher -- to a hard maximum of 200 -- for a grid wider than that." - added
Output schema / properties / api_usage / properties / hub_requests_billedAdded value: +{ + "description": "How many HTTP requests RapidAPI actually billed. Larger than requests_used_by_this_call when a search failed with a server error and was retried, because the retry is billed too. This is the figure the invoice will show.", + "minimum": 0, + "type": "integer" +} - added
Output schema / properties / api_usage / properties / requests_used_by_this_call / descriptionAdded value: +"How many date/destination combinations were searched -- what the answer COVERS." - added
Output schema / properties / search_coverage / properties / hub_requests_billedAdded value: +{ + "description": "HTTP requests billed by RapidAPI for this call, retries included; see api_usage.hub_requests_billed.", + "minimum": 0, + "type": "integer" +} - added
Output schema / properties / search_coverage / properties / stopped_earlyAdded value: +{ + "description": "Present when something other than the cap ended the fan-out. 'deadline': the call reached its time limit and the remaining combinations were never sent or billed, so the results are real but do not cover the whole range.", + "type": "string" +} - changed
Output schema / properties / search_status / descriptionPrevious value: -"Whether the underlying search actually completed, read from the backend's X-Search-Status header. 'ok': every combination searched returned results. 'empty': the search completed and Google genuinely has no itineraries for it -- a real answer, not a failure. 'partial': some combinations returned results and some failed, so the list is incomplete. 'degraded': every combination failed, so the search did not happen and an empty list means nothing; this case is also flagged with isError: true and is safe to retry. 'trial_exhausted': the free signed-in allowance on this server is spent for today, so nothing was searched and nothing was billed; it renews at 00:00 UTC and connecting your own RapidAPI key removes the cap. Retrying does not help."New value: +"Whether the underlying search actually completed, read from the backend's X-Search-Status header. 'ok': every combination searched returned results. 'empty': the search completed and Google genuinely has no itineraries for it -- a real answer, not a failure. 'partial': some combinations returned results and some failed, so the list is incomplete. 'degraded': every combination failed, so the search did not happen and an empty list means nothing; this case is also flagged with isError: true and is safe to retry. 'trial_exhausted': the free signed-in allowance on this server is spent for today, so nothing was searched and nothing was billed; it renews at 00:00 UTC and connecting your own RapidAPI key removes the cap. Retrying does not help. 'quota_exceeded': the search was refused because the caller's remaining allowance or plan quota cannot cover the number of combinations asked for; combos_requested and combos_allowed_now carry the two numbers. Nothing was searched beyond what it cost to read the quota. Retrying the same search does not help -- ask for fewer dates or nights, or move to a larger plan." - changed
Output schema / properties / search_status / enumPrevious value: -[ - "ok", - "empty", - "partial", - "degraded", - "trial_exhausted" -]New value: +[ + "ok", + "empty", + "partial", + "degraded", + "trial_exhausted", + "quota_exceeded" +]
- Changed
search_roundtrip_flights7 fields changed- changed
Input schema / properties / max_searches / descriptionPrevious value: -"Cap the billed requests this call may make. Lower it to spend less of the plan's quota on a wide search; the range is then sampled evenly rather than cut short."New value: +"The billed requests this call may make, up or down. Leave it out for the normal behaviour: the cap covers the request when the request is reasonable (a whole month at three trip lengths, 93 combinations, runs in full) and anything past it is sampled evenly across the range rather than cut short. Set it lower to spend less of the plan's quota on a wide search, or higher -- to a hard maximum of 200 -- for a grid wider than that." - added
Output schema / properties / api_usage / properties / hub_requests_billedAdded value: +{ + "description": "How many HTTP requests RapidAPI actually billed. Larger than requests_used_by_this_call when a search failed with a server error and was retried, because the retry is billed too. This is the figure the invoice will show.", + "minimum": 0, + "type": "integer" +} - added
Output schema / properties / api_usage / properties / requests_used_by_this_call / descriptionAdded value: +"How many date/destination combinations were searched -- what the answer COVERS." - added
Output schema / properties / search_coverage / properties / hub_requests_billedAdded value: +{ + "description": "HTTP requests billed by RapidAPI for this call, retries included; see api_usage.hub_requests_billed.", + "minimum": 0, + "type": "integer" +} - added
Output schema / properties / search_coverage / properties / stopped_earlyAdded value: +{ + "description": "Present when something other than the cap ended the fan-out. 'deadline': the call reached its time limit and the remaining combinations were never sent or billed, so the results are real but do not cover the whole range.", + "type": "string" +} - changed
Output schema / properties / search_status / descriptionPrevious value: -"Whether the underlying search actually completed, read from the backend's X-Search-Status header. 'ok': every combination searched returned results. 'empty': the search completed and Google genuinely has no itineraries for it -- a real answer, not a failure. 'partial': some combinations returned results and some failed, so the list is incomplete. 'degraded': every combination failed, so the search did not happen and an empty list means nothing; this case is also flagged with isError: true and is safe to retry. 'trial_exhausted': the free signed-in allowance on this server is spent for today, so nothing was searched and nothing was billed; it renews at 00:00 UTC and connecting your own RapidAPI key removes the cap. Retrying does not help."New value: +"Whether the underlying search actually completed, read from the backend's X-Search-Status header. 'ok': every combination searched returned results. 'empty': the search completed and Google genuinely has no itineraries for it -- a real answer, not a failure. 'partial': some combinations returned results and some failed, so the list is incomplete. 'degraded': every combination failed, so the search did not happen and an empty list means nothing; this case is also flagged with isError: true and is safe to retry. 'trial_exhausted': the free signed-in allowance on this server is spent for today, so nothing was searched and nothing was billed; it renews at 00:00 UTC and connecting your own RapidAPI key removes the cap. Retrying does not help. 'quota_exceeded': the search was refused because the caller's remaining allowance or plan quota cannot cover the number of combinations asked for; combos_requested and combos_allowed_now carry the two numbers. Nothing was searched beyond what it cost to read the quota. Retrying the same search does not help -- ask for fewer dates or nights, or move to a larger plan." - changed
Output schema / properties / search_status / enumPrevious value: -[ - "ok", - "empty", - "partial", - "degraded", - "trial_exhausted" -]New value: +[ + "ok", + "empty", + "partial", + "degraded", + "trial_exhausted", + "quota_exceeded" +]
2 tool updates
- Changed
search_oneway_flights2 fields changed- changed
Output schema / properties / search_status / descriptionPrevious value: -"Whether the underlying search actually completed, read from the backend's X-Search-Status header. 'ok': every combination searched returned results. 'empty': the search completed and Google genuinely has no itineraries for it -- a real answer, not a failure. 'partial': some combinations returned results and some failed, so the list is incomplete. 'degraded': every combination failed, so the search did not happen and an empty list means nothing; this case is also flagged with isError: true and is safe to retry."New value: +"Whether the underlying search actually completed, read from the backend's X-Search-Status header. 'ok': every combination searched returned results. 'empty': the search completed and Google genuinely has no itineraries for it -- a real answer, not a failure. 'partial': some combinations returned results and some failed, so the list is incomplete. 'degraded': every combination failed, so the search did not happen and an empty list means nothing; this case is also flagged with isError: true and is safe to retry. 'trial_exhausted': the free signed-in allowance on this server is spent for today, so nothing was searched and nothing was billed; it renews at 00:00 UTC and connecting your own RapidAPI key removes the cap. Retrying does not help." - changed
Output schema / properties / search_status / enumPrevious value: -[ - "ok", - "empty", - "partial", - "degraded" -]New value: +[ + "ok", + "empty", + "partial", + "degraded", + "trial_exhausted" +]
- Changed
search_roundtrip_flights2 fields changed- changed
Output schema / properties / search_status / descriptionPrevious value: -"Whether the underlying search actually completed, read from the backend's X-Search-Status header. 'ok': every combination searched returned results. 'empty': the search completed and Google genuinely has no itineraries for it -- a real answer, not a failure. 'partial': some combinations returned results and some failed, so the list is incomplete. 'degraded': every combination failed, so the search did not happen and an empty list means nothing; this case is also flagged with isError: true and is safe to retry."New value: +"Whether the underlying search actually completed, read from the backend's X-Search-Status header. 'ok': every combination searched returned results. 'empty': the search completed and Google genuinely has no itineraries for it -- a real answer, not a failure. 'partial': some combinations returned results and some failed, so the list is incomplete. 'degraded': every combination failed, so the search did not happen and an empty list means nothing; this case is also flagged with isError: true and is safe to retry. 'trial_exhausted': the free signed-in allowance on this server is spent for today, so nothing was searched and nothing was billed; it renews at 00:00 UTC and connecting your own RapidAPI key removes the cap. Retrying does not help." - changed
Output schema / properties / search_status / enumPrevious value: -[ - "ok", - "empty", - "partial", - "degraded" -]New value: +[ + "ok", + "empty", + "partial", + "degraded", + "trial_exhausted" +]
2 tool updates
- Changed
search_oneway_flights5 fields changed- removed
Output schema / properties / by_destination / additionalProperties / properties / cheapest / additionalPropertiesRemoved value: -true - added
Output schema / properties / by_destination / additionalProperties / properties / cheapest / anyOfAdded value: +[ + { + "additionalProperties": true, + "type": "object" + }, + { + "type": "null" + } +] - removed
Output schema / properties / by_destination / additionalProperties / properties / cheapest / typeRemoved value: -[ - "object", - "null" -] - added
Output schema / properties / by_destination / additionalProperties / properties / dates / additionalProperties / properties / cheapest_price / anyOfAdded value: +[ + { + "type": "number" + }, + { + "type": "null" + } +] - removed
Output schema / properties / by_destination / additionalProperties / properties / dates / additionalProperties / properties / cheapest_price / typeRemoved value: -[ - "number", - "null" -]
- Changed
search_roundtrip_flights5 fields changed- removed
Output schema / properties / by_destination / additionalProperties / properties / cheapest / additionalPropertiesRemoved value: -true - added
Output schema / properties / by_destination / additionalProperties / properties / cheapest / anyOfAdded value: +[ + { + "additionalProperties": true, + "type": "object" + }, + { + "type": "null" + } +] - removed
Output schema / properties / by_destination / additionalProperties / properties / cheapest / typeRemoved value: -[ - "object", - "null" -] - added
Output schema / properties / by_destination / additionalProperties / properties / dates / additionalProperties / properties / cheapest_price / anyOfAdded value: +[ + { + "type": "number" + }, + { + "type": "null" + } +] - removed
Output schema / properties / by_destination / additionalProperties / properties / dates / additionalProperties / properties / cheapest_price / typeRemoved value: -[ - "number", - "null" -]
2 tool updates
- Changed
search_oneway_flights1 field changed- added
Output schema / properties / by_destinationAdded value: +{ + "additionalProperties": { + "additionalProperties": true, + "properties": { + "cheapest": { + "additionalProperties": true, + "description": "The lowest-priced of this destination's rows in `results`, or null when it has none.", + "type": [ + "object", + "null" + ] + }, + "dates": { + "additionalProperties": { + "additionalProperties": true, + "properties": { + "cheapest_price": { + "type": [ + "number", + "null" + ] + }, + "reason": { + "enum": [ + "ok", + "no_flights", + "search_failed", + "not_in_limit", + "not_searched" + ], + "type": "string" + }, + "row_count": { + "minimum": 0, + "type": "integer" + }, + "searched": { + "type": "boolean" + } + }, + "type": "object" + }, + "description": "Present only on multi-date searches: one entry per departure date requested for this destination, so a date the fan-out cap sampled away is visible rather than absent. `cheapest_price` is null when that date has no row in `results`.", + "type": "object" + }, + "reason": { + "enum": [ + "ok", + "no_flights", + "search_failed", + "not_in_limit", + "not_searched" + ], + "type": "string" + }, + "rows": { + "items": { + "additionalProperties": true, + "type": "object" + }, + "type": "array" + }, + "searched": { + "description": "Whether at least one search actually ran for this destination. False means the fan-out cap dropped it.", + "type": "boolean" + } + }, + "required": [ + "rows", + "searched", + "reason" + ], + "type": "object" + }, + "description": "One entry per destination the REQUEST asked for, in request order, present whether or not that destination has any flights in `results`. A destination with an empty `rows` array is a hole in the answer, and `reason` says which kind of hole: 'no_flights' (searched, answered, Google has nothing), 'search_failed' (searched and the search errored, so nothing is known), 'not_in_limit' (searched, found flights, none fitted in `limit`) or 'not_searched' (never searched -- the per-call fan-out cap sampled it away). 'ok' means it has rows.\n\nRead this rather than inferring coverage from `results`: a destination missing from `results` looks identical to one that has no flights, and they are not the same answer. `rows` are the same row objects that are in `results`, in the same order -- nothing here is data the answer does not already contain.", + "type": "object" +}
- Changed
search_roundtrip_flights1 field changed- added
Output schema / properties / by_destinationAdded value: +{ + "additionalProperties": { + "additionalProperties": true, + "properties": { + "cheapest": { + "additionalProperties": true, + "description": "The lowest-priced of this destination's rows in `results`, or null when it has none.", + "type": [ + "object", + "null" + ] + }, + "dates": { + "additionalProperties": { + "additionalProperties": true, + "properties": { + "cheapest_price": { + "type": [ + "number", + "null" + ] + }, + "reason": { + "enum": [ + "ok", + "no_flights", + "search_failed", + "not_in_limit", + "not_searched" + ], + "type": "string" + }, + "row_count": { + "minimum": 0, + "type": "integer" + }, + "searched": { + "type": "boolean" + } + }, + "type": "object" + }, + "description": "Present only on multi-date searches: one entry per departure date requested for this destination, so a date the fan-out cap sampled away is visible rather than absent. `cheapest_price` is null when that date has no row in `results`.", + "type": "object" + }, + "reason": { + "enum": [ + "ok", + "no_flights", + "search_failed", + "not_in_limit", + "not_searched" + ], + "type": "string" + }, + "rows": { + "items": { + "additionalProperties": true, + "type": "object" + }, + "type": "array" + }, + "searched": { + "description": "Whether at least one search actually ran for this destination. False means the fan-out cap dropped it.", + "type": "boolean" + } + }, + "required": [ + "rows", + "searched", + "reason" + ], + "type": "object" + }, + "description": "One entry per destination the REQUEST asked for, in request order, present whether or not that destination has any flights in `results`. A destination with an empty `rows` array is a hole in the answer, and `reason` says which kind of hole: 'no_flights' (searched, answered, Google has nothing), 'search_failed' (searched and the search errored, so nothing is known), 'not_in_limit' (searched, found flights, none fitted in `limit`) or 'not_searched' (never searched -- the per-call fan-out cap sampled it away). 'ok' means it has rows.\n\nRead this rather than inferring coverage from `results`: a destination missing from `results` looks identical to one that has no flights, and they are not the same answer. `rows` are the same row objects that are in `results`, in the same order -- nothing here is data the answer does not already contain.", + "type": "object" +}
2 tool updates
- Changed
search_oneway_flights2 fields changed- changed
Input schema / properties / from_airport / descriptionPrevious value: -"Origin IATA code, e.g. \"TLV\"."New value: +"Origin IATA code, e.g. \"TLV\". One origin per search; a second one is refused rather than searched." - changed
Input schema / properties / to_airport / descriptionPrevious value: -"Destination IATA code, or a list of them to compare."New value: +"Destination airport. One IATA code (\"BCN\"), several separated by commas (\"BCN,LIS,ATH\"), or a list ([\"BCN\",\"LIS\",\"ATH\"]) -- every shape is accepted and the destinations are compared in the same search."
- Changed
search_roundtrip_flights2 fields changed- changed
Input schema / properties / from_airport / descriptionPrevious value: -"Origin IATA code, e.g. \"TLV\"."New value: +"Origin IATA code, e.g. \"TLV\". One origin per search; a second one is refused rather than searched." - changed
Input schema / properties / to_airport / descriptionPrevious value: -"Destination IATA code, or a list of them to compare."New value: +"Destination airport. One IATA code (\"BCN\"), several separated by commas (\"BCN,LIS,ATH\"), or a list ([\"BCN\",\"LIS\",\"ATH\"]) -- every shape is accepted and the destinations are compared in the same search."
2 tool updates
- Changed
search_oneway_flights4 fields changed- added
Output schema / descriptionAdded value: +"A completed flight search. Read search_status before reading results: an empty array means 'no flights' only when search_status is 'empty'." - added
Output schema / propertiesAdded value: +{ + "api_usage": { + "additionalProperties": true, + "description": "What this call cost the caller's own RapidAPI plan, and what remains on it. Present on every response that reached the upstream, including a degraded one -- a search that failed was still billed.", + "properties": { + "note": { + "description": "The same figures as a sentence, for the model to relay.", + "type": "string" + }, + "plan_requests_limit": { + "type": "integer" + }, + "plan_requests_remaining": { + "type": "integer" + }, + "requests_used_by_this_call": { + "minimum": 0, + "type": "integer" + } + }, + "type": "object" + }, + "message": { + "description": "Present when there is something the model must relay to the user rather than silently absorb -- no results, a degraded search, a missing key or a spent quota.", + "type": "string" + }, + "needs_api_key": { + "description": "True when no usable RapidAPI key arrived with the call, or the upstream rejected the one that did. No search was run and nothing was billed; signup_url and message say how to fix it.", + "type": "boolean" + }, + "partial": { + "description": "Present when some searches failed but others succeeded. Plain text saying how much of the request the results cover.", + "type": "string" + }, + "quota_exhausted": { + "description": "True when the caller's RapidAPI plan has no requests left for the current period.", + "type": "boolean" + }, + "result_count": { + "minimum": 0, + "type": "integer" + }, + "results": { + "description": "The itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'.", + "items": { + "additionalProperties": true, + "type": "object" + }, + "type": "array" + }, + "search_coverage": { + "additionalProperties": true, + "description": "What was actually searched. Present whether or not the request was truncated, so a model can state honestly what its answer rests on.", + "properties": { + "departure_dates_searched": { + "items": { + "type": "string" + }, + "type": "array" + }, + "destinations_searched": { + "items": { + "type": "string" + }, + "type": "array" + }, + "max_searches_per_request": { + "minimum": 1, + "type": "integer" + }, + "note": { + "type": "string" + }, + "requested_combinations": { + "minimum": 0, + "type": "integer" + }, + "searched_combinations": { + "minimum": 0, + "type": "integer" + }, + "truncated": { + "description": "True when the request expanded past this call's spend ceiling and was sampled. A date absent from departure_dates_searched was never searched, which is not the same as having no flights.", + "type": "boolean" + } + }, + "type": "object" + }, + "search_status": { + "description": "Whether the underlying search actually completed, read from the backend's X-Search-Status header. 'ok': every combination searched returned results. 'empty': the search completed and Google genuinely has no itineraries for it -- a real answer, not a failure. 'partial': some combinations returned results and some failed, so the list is incomplete. 'degraded': every combination failed, so the search did not happen and an empty list means nothing; this case is also flagged with isError: true and is safe to retry.", + "enum": [ + "ok", + "empty", + "partial", + "degraded" + ], + "type": "string" + }, + "signup_url": { + "description": "Where the caller subscribes or changes plan.", + "type": "string" + } +} - added
Output schema / requiredAdded value: +[ + "results" +] - added
Output schema / titleAdded value: +"Flight search result"
- Changed
search_roundtrip_flights4 fields changed- added
Output schema / descriptionAdded value: +"A completed flight search. Read search_status before reading results: an empty array means 'no flights' only when search_status is 'empty'." - added
Output schema / propertiesAdded value: +{ + "api_usage": { + "additionalProperties": true, + "description": "What this call cost the caller's own RapidAPI plan, and what remains on it. Present on every response that reached the upstream, including a degraded one -- a search that failed was still billed.", + "properties": { + "note": { + "description": "The same figures as a sentence, for the model to relay.", + "type": "string" + }, + "plan_requests_limit": { + "type": "integer" + }, + "plan_requests_remaining": { + "type": "integer" + }, + "requests_used_by_this_call": { + "minimum": 0, + "type": "integer" + } + }, + "type": "object" + }, + "message": { + "description": "Present when there is something the model must relay to the user rather than silently absorb -- no results, a degraded search, a missing key or a spent quota.", + "type": "string" + }, + "needs_api_key": { + "description": "True when no usable RapidAPI key arrived with the call, or the upstream rejected the one that did. No search was run and nothing was billed; signup_url and message say how to fix it.", + "type": "boolean" + }, + "partial": { + "description": "Present when some searches failed but others succeeded. Plain text saying how much of the request the results cover.", + "type": "string" + }, + "quota_exhausted": { + "description": "True when the caller's RapidAPI plan has no requests left for the current period.", + "type": "boolean" + }, + "result_count": { + "minimum": 0, + "type": "integer" + }, + "results": { + "description": "The itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'.", + "items": { + "additionalProperties": true, + "type": "object" + }, + "type": "array" + }, + "search_coverage": { + "additionalProperties": true, + "description": "What was actually searched. Present whether or not the request was truncated, so a model can state honestly what its answer rests on.", + "properties": { + "departure_dates_searched": { + "items": { + "type": "string" + }, + "type": "array" + }, + "destinations_searched": { + "items": { + "type": "string" + }, + "type": "array" + }, + "max_searches_per_request": { + "minimum": 1, + "type": "integer" + }, + "note": { + "type": "string" + }, + "requested_combinations": { + "minimum": 0, + "type": "integer" + }, + "searched_combinations": { + "minimum": 0, + "type": "integer" + }, + "truncated": { + "description": "True when the request expanded past this call's spend ceiling and was sampled. A date absent from departure_dates_searched was never searched, which is not the same as having no flights.", + "type": "boolean" + } + }, + "type": "object" + }, + "search_status": { + "description": "Whether the underlying search actually completed, read from the backend's X-Search-Status header. 'ok': every combination searched returned results. 'empty': the search completed and Google genuinely has no itineraries for it -- a real answer, not a failure. 'partial': some combinations returned results and some failed, so the list is incomplete. 'degraded': every combination failed, so the search did not happen and an empty list means nothing; this case is also flagged with isError: true and is safe to retry.", + "enum": [ + "ok", + "empty", + "partial", + "degraded" + ], + "type": "string" + }, + "signup_url": { + "description": "Where the caller subscribes or changes plan.", + "type": "string" + } +} - added
Output schema / requiredAdded value: +[ + "results" +] - added
Output schema / titleAdded value: +"Flight search result"
2 tool updates
- Changed
search_oneway_flights23 fields changed- added
Input schema / properties / airline_codes / descriptionAdded value: +"Restrict to these airline codes, e.g. [\"LY\"]." - added
Input schema / properties / arrival_time_max / descriptionAdded value: +"Latest arrival hour, 0-23." - added
Input schema / properties / arrival_time_min / descriptionAdded value: +"Earliest arrival hour, 0-23." - added
Input schema / properties / currency / descriptionAdded value: +"ISO currency code, default \"usd\"." - added
Input schema / properties / departure_date / descriptionAdded value: +"Single departure date, \"YYYY-MM-DD\"." - added
Input schema / properties / departure_date_from / descriptionAdded value: +"First date of a departure range." - added
Input schema / properties / departure_date_to / descriptionAdded value: +"Last date of a departure range." - added
Input schema / properties / departure_time_max / descriptionAdded value: +"Latest departure hour, 0-23." - added
Input schema / properties / departure_time_min / descriptionAdded value: +"Earliest departure hour, 0-23." - added
Input schema / properties / exclude_airline_codes / descriptionAdded value: +"Exclude these airline codes." - added
Input schema / properties / from_airport / descriptionAdded value: +"Origin IATA code, e.g. \"TLV\"." - added
Input schema / properties / limit / descriptionAdded value: +"Maximum flights to return, after merging and sorting." - added
Input schema / properties / max_price / descriptionAdded value: +"Only return flights at or below this price." - added
Input schema / properties / max_searches / descriptionAdded value: +"Cap the billed requests this call may make. Lower it to spend less of the plan's quota on a wide search; the range is then sampled evenly rather than cut short." - added
Input schema / properties / max_stops / descriptionAdded value: +"Maximum stops per flight. 0 means non-stop only." - added
Input schema / properties / passengers / descriptionAdded value: +"Passenger counts as [adults, children, infants]." - added
Input schema / properties / seat_type / descriptionAdded value: +"1 economy, 2 premium economy, 3 business, 4 first." - added
Input schema / properties / sort_by / descriptionAdded value: +"\"best\", \"price\", or \"duration\". Applied across all results." - added
Input schema / properties / to_airport / descriptionAdded value: +"Destination IATA code, or a list of them to compare." - added
Input schema / properties / use_fallback / anyOfAdded value: +[ + { + "type": "boolean" + }, + { + "type": "null" + } +] - changed
Input schema / properties / use_fallback / defaultPrevious value: -falseNew value: +null - added
Input schema / properties / use_fallback / descriptionAdded value: +"Leave unset. Switches the search to a second, independent flight data source instead of the usual Google Flights page read. Unset already escalates to that source once, automatically, after a search's retries have failed. true forces it inline on every attempt -- much slower, and it can time out. false disables it entirely, that automatic retry included." - removed
Input schema / properties / use_fallback / typeRemoved value: -"boolean"
- Changed
search_roundtrip_flights22 fields changed- added
Input schema / properties / currency / descriptionAdded value: +"ISO currency code, default \"usd\"." - added
Input schema / properties / departure_airline_codes / descriptionAdded value: +"Restrict the outbound leg to these airlines." - added
Input schema / properties / departure_date / descriptionAdded value: +"Single outbound date, \"YYYY-MM-DD\"." - added
Input schema / properties / departure_date_from / descriptionAdded value: +"First date of an outbound range." - added
Input schema / properties / departure_date_to / descriptionAdded value: +"Last date of an outbound range." - added
Input schema / properties / from_airport / descriptionAdded value: +"Origin IATA code, e.g. \"TLV\"." - added
Input schema / properties / limit / descriptionAdded value: +"Maximum trips to return, after merging and sorting." - added
Input schema / properties / max_departure_stops / descriptionAdded value: +"Maximum stops on the outbound leg." - added
Input schema / properties / max_price / descriptionAdded value: +"Only return trips at or below this total price." - added
Input schema / properties / max_return_stops / descriptionAdded value: +"Maximum stops on the return leg." - added
Input schema / properties / max_searches / descriptionAdded value: +"Cap the billed requests this call may make. Lower it to spend less of the plan's quota on a wide search; the range is then sampled evenly rather than cut short." - added
Input schema / properties / nights / descriptionAdded value: +"Trip length in nights; a number, or a list like [5, 6, 7]. The return date is derived from each departure date." - added
Input schema / properties / passengers / descriptionAdded value: +"Passenger counts as [adults, children, infants]." - added
Input schema / properties / return_airline_codes / descriptionAdded value: +"Restrict the return leg to these airlines." - added
Input schema / properties / return_date / descriptionAdded value: +"Fixed return date. Use this OR nights, not both." - added
Input schema / properties / seat_type / descriptionAdded value: +"1 economy, 2 premium economy, 3 business, 4 first." - added
Input schema / properties / sort_by / descriptionAdded value: +"\"best\", \"price\", or \"duration\". Applied across all results." - added
Input schema / properties / to_airport / descriptionAdded value: +"Destination IATA code, or a list of them to compare." - added
Input schema / properties / use_fallback / anyOfAdded value: +[ + { + "type": "boolean" + }, + { + "type": "null" + } +] - changed
Input schema / properties / use_fallback / defaultPrevious value: -falseNew value: +null - added
Input schema / properties / use_fallback / descriptionAdded value: +"Leave unset. Switches the search to a second, independent flight data source instead of the usual Google Flights page read. Unset already escalates to that source once, automatically, after a search's retries have failed. true forces it inline on every attempt -- much slower, and it can time out. false disables it entirely, that automatic retry included." - removed
Input schema / properties / use_fallback / typeRemoved value: -"boolean"
2 tool updates
- First observed
search_oneway_flights - First observed
search_roundtrip_flights
Related MCP Connectors
Real-time Booking.com rates for agents. Three things people do with this server. Scan for rate gaps: price_as_seen_from prices the same room from another market, so an agent can sample a property across countries and compare. Put live search in your app: search a destination or look a property up by name, no internal IDs, room-level rates as flat JSON. Run a 24/7 AI travel agent: add the server, sign in with Google, and schedule it. No ads, no sponsored content. You bring your own RapidAPI key, so every search is billed to your plan and never to anyone else's. Add https://hotels.flightpowers.com/mcp , click Sign in, sign in with Google, and paste your RapidAPI key once on the page that opens. Scripts and clients without a sign-in button send the key as x-rapidapi-key on the same URL.
Google Flights search data: fares, routes, stops, and price insights via a hosted MCP server.
Search and compare flight offers through a cache-aware Streamable HTTP MCP server for AI agents.
Google Flights for any route and date: price, airlines, flight numbers, times, stops, layovers, aircraft, legroom and CO2. One way or round trip, any cabin and currency. Runs on Apify, $0.20 per 1,000 flights.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides live flight prices, booking links, and airport lookup via a hosted MCP server. Enables search for flights and direct booking URL retrieval.1MIT
- AlicenseAqualityDmaintenanceMCP server that enables Google Flights search via SerpApi, supporting one-way, round-trip, and multi-city itineraries with defaults for Business class, Star Alliance, and EUR pricing. It provides flight search, booking options, and usage tracking.4116 npmMIT
- AlicenseNot gradedqualityBmaintenanceFlight search for AI agents: flexible-date cheapest round-trips with a good-price verdict from historical data. Hosted remote MCP, free, no key.3MIT
- FlicenseNot gradedqualityNot gradedmaintenanceA remote MCP server that searches Google Flights for flight information and airport codes. It enables users to find flights, locate airports, and generate travel dates through natural language interactions.-
Glama MCP Gateway
Add one secure layer between your agents and this server.