A
licenseA
qualityD
maintenanceSearch Google Flights for one-way, round-trip and multi-city fares, with offline airport lookup and nearby-airport resolution.
6
1
MIT
Google Flights MCP
by ai.wondel
Server Details
Live Google Flights fares: search routes, discover cheap deals from an origin.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.2/5.0
Scored across 2 tools
Disambiguation5/5
The two tools have clearly distinct purposes: one explores cheap destinations with no arrival_id, while the other searches specific routes and returns itineraries with tokens. The detailed descriptions make it hard to confuse the exploratory deals search with a standard flight search.
Naming Consistency4/5
Both names use snake_case with the shared google_flights_ prefix and end in search, which creates a predictable pattern. The only minor deviation is that one includes the extra 'deals' segment, making the suffix pattern not perfectly uniform.
Tool Count3/5
With only two tools, the surface feels thin even though each tool is broad and feature-rich. The server covers the two main workflows, but the low count is borderline for a domain that could also benefit from smaller utility tools like airport resolution.
Completeness4/5
The tools cover core flight search, multi-city, return-leg and booking-option flows, plus destination deals discovery. Minor gaps remain around airport/city-code resolution and booking execution, but those are either workaroundable or likely outside the server's intended scope.
Available Tools
2 toolsgoogle_flights_deals_searchSearch Google Flights Deals (SerpAPI)AInspect
Discover cheap flight destinations from an origin via SerpAPI's Google Flights Deals engine (google_flights_deals). Unlike google_flights_search there is no arrival_id — the engine explores destinations for you — and there are no pagination or navigation tokens. Dates accept a single YYYY-MM-DD or a 'start,end' range (e.g. '2026-06-27,2026-07-03') to widen the window. Supports round trip (type=1, needs return_date) and one way (type=2). Prices are in currency (default USD). Result shape: { source, fetchedAt, query, search_metadata, search_parameters, departure_informations, deals: [...] } — the list key is deals (there are no best_flights/other_flights here). Each deal: { destination_id, name, country, price, average_price, discount_percentage, flight_link, serpapi_flight_link, thumbnail, outbound_date, return_date, departure_airport_code, arrival_airport_code, flight_duration, stops, airline, airline_code, description, highlights }. The dates are outbound_date / return_date (YYYY-MM-DD) — the live engine returns those, not the start_date/end_date of SerpAPI's docs — and a deal carries NO departure or return time.
| Name | Required | Description | Default |
|---|---|---|---|
| gl | No | Country code for the search, e.g. 'us', 'uk', 'de'. | |
| hl | No | Language code, e.g. 'en', 'es', 'fr'. | |
| type | No | Trip type: 1 = round trip (default, needs return_date), 2 = one way. | |
| stops | No | Max stops: 0 = any (default), 1 = nonstop only, 2 = 1 stop or fewer, 3 = 2 stops or fewer. | |
| adults | No | Number of adults. Default 1. | |
| children | No | Number of children. Default 0. | |
| currency | No | Currency of returned prices (ISO code, e.g. 'USD', 'EUR'). Default USD. | |
| no_cache | No | Force a fresh SerpAPI fetch and bypass this server's result cache. Default false. | |
| max_price | No | Maximum ticket price in the selected currency. | |
| zero_trace | No | Enterprise-only ZeroTrace mode: don't store search params/metadata on SerpAPI. Default false. | |
| return_date | No | Return date as a single YYYY-MM-DD, or a 'start,end' range. Required when type=1 (round trip). When outbound_date is a range it must be a 'start,end' range too (or drop it and use trip_length/travel_duration). | |
| trip_length | No | Trip length in days: a single number, or a 'min,max' day range (e.g. '3,5'). | |
| departure_id | No | Departure AIRPORT IATA code(s) (3-letter, uppercase, e.g. 'WAW' or 'WAW,WMI') or a Google location kgmid (/m/… or /g/…). Comma-separate multiple. NOT a city/metro code (NYC, LON, PAR return no results — list the airports). No arrival_id: the deals engine discovers destinations for you. | |
| max_duration | No | Maximum total trip duration in minutes (e.g. 1500 for 25h). | |
| travel_class | No | Travel class: 1 = economy (default), 2 = premium economy, 3 = business, 4 = first. | |
| outbound_date | No | Outbound date as a single YYYY-MM-DD, or a 'start,end' range (e.g. '2026-06-27,2026-07-03') to search a window. | |
| infants_on_lap | No | Number of infants on lap. Default 0. | |
| infants_in_seat | No | Number of infants in seat. Default 0. | |
| travel_duration | No | Travel duration preset: 1 = one week, 2 = weekend, 3 = two weeks. | |
| exclude_airlines | No | Exclude these airlines: comma-separated 2-letter IATA codes, or an alliance (STAR_ALLIANCE, SKYTEAM, ONEWORLD). Mutually exclusive with include_airlines. | |
| include_airlines | No | Only these airlines: comma-separated 2-letter IATA codes, or an alliance: STAR_ALLIANCE, SKYTEAM, ONEWORLD. Mutually exclusive with exclude_airlines. |
Output Schema
| Name | Required | Description |
|---|---|---|
| deals | No | |
| query | Yes | |
| source | Yes | |
| fetchedAt | Yes | |
| search_metadata | No | |
| search_parameters | No | |
| departure_informations | No |
TDQS
A4.3/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden and does so: it discloses that there are no pagination or navigation tokens, that prices are in `currency`, that the result key is `deals` (not best_flights/other_flights), and that deals carry no departure/return times. It even corrects a SerpAPI documentation mismatch by stating the live engine returns `outbound_date`/`return_date` instead of `start_date`/`end_date`.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and sibling differentiation are front-loaded, which is good, but the exhaustive enumeration of every field in the `deals` object is largely redundant given an output schema exists. It's dense and long, with the useful signal (the `deals` key, the date-field mismatch) buried in a wall of field names.
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?
For a 21-parameter, zero-annotation tool the description covers what an agent actually needs: which parameters interact (type/return_date, outbound range vs trip_length), what the result envelope looks like, and the absence of pagination. Nothing required to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every one of the 21 parameters is already documented in the schema; the description adds little beyond restating date-range syntax, the type=1/return_date dependency, and the USD default. Baseline 3 applies when the schema does the heavy lifting.
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?
States a specific verb and resource ('Discover cheap flight destinations from an origin') and immediately separates itself from the sibling: 'Unlike google_flights_search there is no arrival_id — the engine explores destinations for you.' An agent can pick between the two tools 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The sibling differentiation plus the note that the engine explores destinations implicitly tells the agent this is the discovery path, and the round-trip/one-way (type=1 needs return_date) and date-range widening guidance gives concrete invocation context. What's missing is an explicit statement of the user-intent condition (e.g. 'use when the traveler has no fixed destination') or any when-not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
google_flights_searchSearch Google Flights (SerpAPI)AInspect
Search Google Flights live via SerpAPI. Returns best_flights and other_flights (each with legs, airlines, times, duration, layovers, price and carbon emissions), plus price_insights and airport info. Supports round trip (type=1, needs return_date), one way (type=2) and multi-city (type=3 via multi_city_json). Two-step flows: pass a departure_token from a prior result to get the returning flights / next leg, or a booking_token to get booking options — re-send the original search params alongside either token. Prices are in currency (default USD). IDs are AIRPORT codes, never city/metro codes: TYO, NYC, LON, PAR, MIL, ROM, OSA, CHI, WAS return NO results (live-verified) — send the airports instead (TYO → 'HND,NRT'; NYC → 'JFK,EWR,LGA'; LON → 'LHR,LGW,STN,LTN'; PAR → 'CDG,ORY'; MIL → 'MXP,LIN,BGY'; ROM → 'FCO,CIA') or the city's Google kgmid (e.g. '/m/07dfk' for Tokyo). Result shape: { note?, source, fetchedAt, query, search_metadata: { google_flights_url }, search_parameters, best_flights: [...], other_flights: [...], price_insights, airports } — the two itinerary lists are best_flights and other_flights (there is no flights or deals key at the top level, and an itinerary is never a bare flight). Each itinerary: { flights: [{ departure_airport: { name, id, time }, arrival_airport: { name, id, time }, duration, airplane, airline, airline_logo, travel_class, flight_number, legroom, extensions }], layovers: [{ duration, name, id, overnight }], total_duration, carbon_emissions, price, type, airline_logo, departure_token, booking_token } — price is the whole-itinerary price in currency, duration/total_duration are minutes, and the per-leg times are local 'YYYY-MM-DD HH:MM' strings. Feed departure_token back for the return leg and booking_token for booking options. A top-level note appears only when stops=1 found no nonstop flight and the server retried without the stop filter: the itineraries are then connecting flights, and their tokens need the same params re-sent without stops — tell the user that no direct flights were found and connecting flights are shown.
| Name | Required | Description | Default |
|---|---|---|---|
| gl | No | Country code for the search, e.g. 'us', 'uk', 'de'. | |
| hl | No | Language code, e.g. 'en', 'es', 'fr'. | |
| bags | No | Number of carry-on bags. Default 0. | |
| type | No | Trip type: 1 = round trip (default), 2 = one way, 3 = multi-city. | |
| stops | No | Max stops: 0 = any (default), 1 = nonstop only, 2 = 1 stop or fewer, 3 = 2 stops or fewer. When stops=1 finds no nonstop flight, the server automatically retries without the filter and returns connecting flights with a `note`; send a departure_token/booking_token from those with the same params but no stops. | |
| adults | No | Number of adults. Default 1. | |
| sort_by | No | Sort order: 1 = top flights (default), 2 = price, 3 = departure time, 4 = arrival time, 5 = duration, 6 = emissions. | |
| children | No | Number of children. Default 0. | |
| currency | No | Currency of returned prices (ISO code, e.g. 'USD', 'EUR'). Default USD. | |
| no_cache | No | Force a fresh SerpAPI fetch and bypass this server's result cache. Default false. | |
| emissions | No | Emissions filter: 1 = less emissions only. Omit for no filter. | |
| max_price | No | Maximum ticket price in the selected currency. | |
| arrival_id | No | Arrival AIRPORT IATA code(s) (e.g. 'HND,NRT') or a Google location kgmid (e.g. '/m/07dfk' for Tokyo). Comma-separate multiple. NOT a city/metro code — TYO, LON, PAR, MIL, ROM, OSA return no results; list the airports instead. | |
| zero_trace | No | Enterprise-only ZeroTrace mode: don't store search params/metadata on SerpAPI. Default false. | |
| deep_search | No | Run a deeper search that matches the Google Flights browser results more closely (slower). Default false. | |
| return_date | No | Return date, YYYY-MM-DD. Required when type=1 (round trip). | |
| show_hidden | No | Include hidden flight results. Default false. | |
| departure_id | No | Departure AIRPORT IATA code(s) (3-letter, uppercase, e.g. 'WAW' or 'WAW,WMI') or a Google location kgmid (/m/… or /g/…). Comma-separate multiple. NOT a city/metro code — TYO, NYC, LON, PAR, MIL, ROM return no results; list the airports instead (NYC → 'JFK,EWR,LGA'). Used for type 1/2; for multi-city (type 3) use multi_city_json instead. | |
| max_duration | No | Maximum total trip duration in minutes (e.g. 1500 for 25h). | |
| return_times | No | Return time window, same format as outbound_times. Only valid when type=1. | |
| travel_class | No | Travel class: 1 = economy (default), 2 = premium economy, 3 = business, 4 = first. | |
| booking_token | No | Token from a prior result, used to fetch booking options for a selected itinerary. Re-send the same search params alongside it. Mutually exclusive with departure_token. | |
| exclude_basic | No | Exclude basic-economy fares. Only for domestic US flights with travel_class=1. Default false. | |
| exclude_conns | No | Connecting airports to exclude: comma-separated 3-letter IATA codes (e.g. 'CDG,LHR'). | |
| outbound_date | No | Outbound date, YYYY-MM-DD. | |
| infants_on_lap | No | Number of infants on lap. Default 0. | |
| outbound_times | No | Outbound time window as comma-separated hours (0-23). 2 values = departure range 'min,max' (e.g. '4,18'); 4 values add an arrival range (e.g. '4,18,3,19'). | |
| departure_token | No | Token from a prior result, used to select an outbound flight and fetch the returning flights (round trip) or the next leg (multi-city). Re-send the same search params alongside it. Mutually exclusive with booking_token. | |
| infants_in_seat | No | Number of infants in seat. Default 0. | |
| multi_city_json | No | Multi-city itinerary (required when type=3): a JSON-string array of legs, e.g. '[{"departure_id":"CDG","arrival_id":"NRT","date":"2026-06-27"},{"departure_id":"NRT","arrival_id":"LAX","date":"2026-07-03"}]'. Each leg may include an optional "times" field (same format as outbound_times). | |
| exclude_airlines | No | Exclude these airlines: comma-separated 2-letter IATA codes, or an alliance (STAR_ALLIANCE, SKYTEAM, ONEWORLD). Mutually exclusive with include_airlines. | |
| include_airlines | No | Only these airlines: comma-separated 2-letter IATA codes, or an alliance: STAR_ALLIANCE, SKYTEAM, ONEWORLD. Mutually exclusive with exclude_airlines. | |
| layover_duration | No | Layover duration range in minutes, 'min,max' (e.g. '90,330' for 1.5-5.5h). |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | No | Present only when stops=1 found no nonstop flight and best_flights/other_flights are connecting flights from a search without the stop filter. Tell the user that no direct flights were found, so connecting flights are shown. |
| query | Yes | |
| source | Yes | |
| airports | No | |
| fetchedAt | Yes | |
| best_flights | No | |
| other_flights | No | |
| price_insights | No | |
| search_metadata | No | |
| search_parameters | No |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses the auto-retry behavior behind a top-level `note` when stops=1 finds no nonstop, the meaning of departure_token vs booking_token, and the mutually-exclusive token usage. It omits auth/environment constraints and caching behavior beyond what the schema's no_cache parameter states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded and logically ordered, but bloated: a full result-shape and per-itinerary field listing is spelled out even though an output schema already exists, and the metro-code warning is repeated three times (top-level, departure_id, arrival_id). Several sentences re-state schema-documented defaults (currency USD).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 33-parameter search tool with no annotations, the description covers the operationally risky parts: token round-trips, the stops retry note, unit conventions (minutes, local times), and the metro-code trap. The only real gap is sibling differentiation against google_flights_deals_search; the extensive result-shape prose compensates for the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so baseline would be 3, but the description adds cross-parameter meaning the schema cannot: return_date is required only for type=1, multi-city legs go in multi_city_json rather than departure_id/arrival_id, and tokens must be accompanied by the original search params. The airport-vs-metro-code warning with concrete mappings is genuinely useful, though it largely duplicates the departure_id/arrival_id schema text.
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?
Opens with a specific verb+resource ('Search Google Flights live via SerpAPI') and immediately enumerates what comes back (best_flights, other_flights, price_insights, airports). It also preempts a likely confusion by naming the exact top-level keys that do NOT exist ('no `flights` or `deals` key'), which separates it in spirit from the deals sibling even though that sibling is not named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly maps the three trip types to their required inputs (type=1 needs return_date, type=3 uses multi_city_json) and describes the two-step token flows with the requirement to re-send original params. It does not mention the sibling google_flights_deals_search or say when a user should prefer it over this tool, so the alternative-routing half of the guidance is missing.
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.
2 tool updates
- First observed
google_flights_deals_search - First observed
google_flights_search
Related MCP Connectors
Live Google Flights search: stopover itineraries, country sweeps, explore anywhere, booking links
Google Flights prices for any route and date: round trips, cabins, stops, airlines, cheapest dates.
Flight search, airfare analytics, flexible destinations
Google Flights search data: fares, routes, stops, and price insights via a hosted MCP server.
Related MCP Servers
- FlicenseNot gradedqualityFmaintenanceEnables finding the cheapest flight destinations from an airport as structured JSON, with bargain detection via typical price comparisons and booking links.-
- AlicenseNot gradedqualityAmaintenanceEnables flight search and fare calendar exploration by interacting with Google Flights' API, supporting detailed filters for origin, destination, dates, cabin class, airlines, and more.6,108 PyPI3,468MIT
- AlicenseAqualityBmaintenanceEnables users to find the cheapest dates to fly a route via Google Flights, supporting one-way and round-trip searches through multiple backends. It provides a tool that can search date ranges, filter by nonstop, seat, currency, and force a particular backend.1MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.