Skip to main content
Glama
mtnrabi

google-flights-mcp

FlightPowers: search one-way flights

search_oneway_flights
Read-only

Find one-way flight fares for any date range or multiple destinations, with live prices, airline, duration, stops, and booking links. Compare historical price insights to see if a fare is a good deal.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum flights to return, after merging and sorting.
sort_byNo"best", "price", or "duration". Applied across all results.best
currencyNoISO currency code, default "usd".usd
max_priceNoOnly return flights at or below this price.
max_stopsNoMaximum stops per flight. 0 means non-stop only.
seat_typeNo1 economy, 2 premium economy, 3 business, 4 first.
passengersNoPassenger counts as [adults, children, infants].
to_airportYesDestination 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_airportYesOrigin IATA code, e.g. "TLV". One origin per search; a second one is refused rather than searched.
max_searchesNoCap 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.
use_fallbackNoLeave 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_codesNoRestrict to these airline codes, e.g. ["LY"].
departure_dateNoSingle departure date, "YYYY-MM-DD".
arrival_time_maxNoLatest arrival hour, 0-23.
arrival_time_minNoEarliest arrival hour, 0-23.
departure_date_toNoLast date of a departure range.
departure_time_maxNoLatest departure hour, 0-23.
departure_time_minNoEarliest departure hour, 0-23.
departure_date_fromNoFirst date of a departure range.
exclude_airline_codesNoExclude these airline codes.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageNoPresent 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.
partialNoPresent when some searches failed but others succeeded. Plain text saying how much of the request the results cover.
resultsYesThe itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'.
api_usageNoWhat 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_urlNoWhere the caller subscribes or changes plan.
result_countNo
needs_api_keyNoTrue 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.
search_statusNoWhether 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.
by_destinationNoOne 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. `rows` are the same row objects that are in `results`, in the same order -- nothing here is data the answer does not already contain.
quota_exhaustedNoTrue when the caller's RapidAPI plan has no requests left for the current period.
search_coverageNoWhat was actually searched. Present whether or not the request was truncated, so a model can state honestly what its answer rests on.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses return fields (price, airline, duration, stops, buy_link, price_insights) and billing reporting via api_usage. It further explains fallback source behavior, max_searches sampling, and that usage counts against the caller's own RapidAPI plan, all beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although lengthy, each paragraph serves a distinct purpose—result contents, invocation advice, billing, and API-key setup—and includes concrete examples without redundant filler. The structure is logical and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers key operational concerns an external agent needs: API key requirements, quota reporting, multi-destination/date handling, and fallback behavior. Since an output schema is present, no additional return-value documentation is necessary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 20 parameters have schema descriptions, and the description adds practical semantics such as accepted shapes for to_airport, origin singularity, date-range versus single-date usage, and seat_type/passenger mappings. This goes well beyond the schema's basic property descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Title and first sentence explicitly state 'one-way fare search' and 'live prices read from Google Flights,' clearly distinguishing it from sibling roundtrip/hotel tools. The verb 'search' plus resource 'flights' makes the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit guidance: 'Use it for any one-way fare question' and 'do NOT call it once per date,' with a concrete example of a single flexible search. It also explains API-key requirements, billing consequences, and that a second origin is refused rather than searched.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.