A
licenseA
qualityF
maintenanceEnables searching and analyzing Google Flights data including prices, emissions, cabin classes, layovers, and price tracking, all without an API key.
12
105 npm
5
ISC
Google Flights Remote MCP Server
by com.hasdata
Server Details
Google Flights itineraries with fares, legs, carbon emissions and price history, as JSON.
Ownership verified
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- HasData/google-flights-mcp
- GitHub Stars
- 6
- Server Listing
- Google Flights MCP Server
TDQS
A4/5.0
Scored across 1 tool
Disambiguation5/5
Only one tool exists, so there is no ambiguity in purpose or selection.
Naming Consistency5/5
The single tool name follows a clear, descriptive pattern and is consistent with its function.
Tool Count3/5
With only one tool, the server feels thin for its broad scope, though the tool itself is comprehensive.
Completeness5/5
The tool fully covers its intended domain of flight searching, including many options and outputs, with no apparent gaps.
Available Tools
1 toolhasdata_google_travel_flights_getGoogleFlightsgoogle_travel_flights: GET /AInspect
Get Google Flights Results
Searches Google Flights for one-way, round-trip, or multi-city itineraries with passenger mix (adults, children, infants in-seat/on-lap), travel class, bags, max price, sort order (price, duration, emissions, departure/arrival time), stops, include/exclude airlines and connections, time windows, layover duration, and deep-search mode. Returns per-itinerary price, currency, total duration, stops, flight legs with airline, flight number, aircraft, departure/arrival airports and times, CO2 emissions, plus booking and departure tokens for round-trip returns or booking options. Use for travel-planning agents, fare monitoring, corporate travel dashboards, emission-aware trip optimization, and comparing routes and airlines across markets.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| gl | No | The two-letter country code for the country you want to limit the search to. Provide one exact documented value (245 allowed), e.g. `ac`, `af`. | |
| hl | No | The two-letter language code for the language you want to use for the search. Provide one exact documented value (159 allowed), e.g. `af`, `ak`. | |
| bags | No | Number of carry-on bags per passenger. | |
| type | No | Specifies the type of flight. Options: - `roundTrip` (default) - `oneWay` - `multiCity` (requires `multiCityJson` for flight details) For round trips, retrieve return flight details with a separate request using `departureToken`. | |
| stops | No | Restrict the number of stops (layovers) in the flight itinerary. | |
| adults | No | Number of adult passengers (>= 1 if specified). | |
| sortBy | No | Sort the flight results based on price, departure time, arrival time, etc. | |
| children | No | Number of child passengers. | |
| currency | No | Parameter defines the currency of the returned prices Provide one exact documented value (71 allowed), e.g. `ALL`, `DZD`. | |
| maxPrice | No | Maximum price limit for the flight search, in the selected currency. | |
| arrivalId | Yes | Specifies the arrival airport code (IATA) or location kgmid. - **IATA Code**: A 3-letter uppercase code (e.g., `SFO` for San Francisco, `LHR` for London Heathrow). Search on [IATA](https://www.iata.org/en/publications/directories/code-search). - **Location kgmid**: A string starting with `/m/`, found in Wikidata under "Freebase ID" (e.g., `/m/02_286` for New York, NY). Multiple values can be separated by commas (e.g., `JFK,LGA,/m/0hptm`). | |
| deepSearch | No | Enable deep search. Returns the same results as Google Flights in a browser, but takes longer to respond. Default is `false`. | |
| returnDate | No | The return travel date in 'yyyy-MM-dd' format. Required when **type** is `roundTrip`. | |
| showHidden | No | Indicates whether to include hidden options in the results. | |
| departureId | Yes | Specifies the departure airport code (IATA) or location kgmid. - **IATA Code**: A 3-letter uppercase code (e.g., SFO for San Francisco, LHR for London Heathrow). Search on [IATA](https://www.iata.org/en/publications/directories/code-search). - **Location kgmid**: A string starting with `/m/`, found in Wikidata under "Freebase ID" (e.g., `/m/02_286` for New York, NY). Multiple values can be separated by commas (e.g., `JFK,LGA,/m/0hptm`). | |
| maxDuration | No | The maximum total flight duration in minutes. | |
| returnTimes | No | Set up to 4 time boundaries (2 for departure, 2 for arrival) to filter return flights. Each number represents the start of an hour. Examples: - `6,20` → 6:00 AM - 9:00 PM departure - `1,15` → 1:00 AM - 4:00 PM departure - `7,18,2,21` → 7:00 AM - 9:00 PM departure, 2:00 AM - 10:00 PM arrival | |
| travelClass | No | The travel class for the flight (Economy, Premium Economy, Business, or First). | |
| bookingToken | No | Used to request booking options for selected flights. This token is found in the flight results and cannot be used with `departureToken`. | |
| infantsOnLap | No | Number of infants sitting on an adult's lap. | |
| outboundDate | Yes | The outbound travel date in 'yyyy-MM-dd' format. | |
| infantsInSeat | No | Number of infants occupying seats. | |
| lessEmissions | No | Prefer flight options with lower carbon emissions. | |
| multiCityJson | No | This parameter specifies flight details for multi-city trips. It is a JSON string containing multiple flight objects. Each object must include the following fields: - **departureId** – The departure airport code or location KGMID. Uses the same format as the main `departureId` parameter. - **arrivalId** – The arrival airport code or location KGMID. Uses the same format as the main `arrivalId` parameter. - **date** – The flight date. Uses the same format as the `outboundDate` parameter. - **times** *(optional)* – The time range for the flight. Uses the same format as the `outboundTimes` parameter. | |
| outboundTimes | No | Set up to 4 time boundaries (2 for departure, 2 for arrival) to filter flights. Each number represents the start of an hour. Examples: - `6,20` → 6:00 AM - 9:00 PM departure - `1,15` → 1:00 AM - 4:00 PM departure - `7,18,2,21` → 7:00 AM - 9:00 PM departure, 2:00 AM - 10:00 PM arrival | |
| departureToken | No | Used to select a flight and retrieve return flights for a round trip or the next leg of the itinerary for a multi-city trip. | |
| excludeAirlines | No | A comma separated list of airline codes to exclude from results. You can search for airline codes on [IATA](https://www.iata.org/en/publications/directories/code-search). For example, `UA` is United Airlines. | |
| includeAirlines | No | A comma separated list of airline codes to exclusively include in results. You can search for airline codes on [IATA](https://www.iata.org/en/publications/directories/code-search). For example, `UA` is United Airlines. `excludeAirlines` and `includeAirlines` parameters can't be used together. | |
| layoverDuration | No | Set the maximum layover duration in minutes to filter flights. For example, `120, 360` filters layovers between 2 hours and 6 hours, while `45, 180` allows layovers from 45 minutes to 3 hours. | |
| excludeConnections | No | A comma separated list of specific airports to exclude as connections. | |
| includeConnections | No | A comma separated list of specific airports to allow as connections. |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden; it does describe outputs and token usage, but it does not state side-effect/read-only status, error behavior, rate limits, or that deepSearch increases latency. The behavior is implied rather than fully disclosed.
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?
The description is front-loaded with a clear 'Get Google Flights Results' title and a direct 'Searches Google Flights' sentence, but the rest is a dense single-sentence list of features and use cases. The closing 'Use for...' list is somewhat generic and could be trimmed or bulleted.
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?
Although there is no output schema, the description specifies the returned data: price, currency, duration, stops, flight legs, CO2 emissions, and tokens. It also explains the round-trip/booking-token flow, which is enough context for a client to understand the tool's output at a high level.
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?
The input schema already provides 100% coverage with descriptions for all 31 parameters, including enum values and examples, so this matches the baseline. The main description only adds a high-level feature list and does not materially extend parameter semantics.
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?
The description opens by naming the exact resource ('Google Flights') and the primary verb ('Searches'), then enumerates the supported trip types (one-way, round-trip, multi-city) and the main feature set. There is no ambiguity about what this tool does.
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 description gives explicit use cases ('travel-planning agents, fare monitoring, corporate travel dashboards, emission-aware trip optimization') and explains the output flow involving booking and departure tokens. It does not mention alternatives, but no sibling tools are present, so the usage context is clear.
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
- First observed
hasdata_google_travel_flights_getGoogleFlights
Related MCP Connectors
Google Flights search data: fares, routes, stops, and price insights via a hosted MCP server.
Live Google Flights search: stopover itineraries, country sweeps, explore anywhere, booking links
Live flight prices and working booking links for AI agents and travel apps.
Flight search, airfare analytics, flexible destinations
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables flight search and fare calendar exploration by interacting with Google Flights' API, supporting detailed filters for origin, destination, dates, cabin class, airlines, and more.3,138MIT
- AlicenseAqualityDmaintenanceIntegrates Google Flights data into AI workflows for natural language flight searches, price comparisons, flexible date searches, and multi-city itinerary planning with support for various cabin classes and passenger types.94MIT
- FlicenseAqualityBmaintenanceSearches Google Flights, labels results as in-policy or out-of-policy based on a travel policy file, and ranks them by preferences like nonstop, alliance, or price.5-
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.