Skip to main content
Glama

Google Flights Remote MCP Server

google_travel_flights: GET /

hasdata_google_travel_flights_getGoogleFlights

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
glNoThe 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`.
hlNoThe 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`.
bagsNoNumber of carry-on bags per passenger.
typeNoSpecifies 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`.
stopsNoRestrict the number of stops (layovers) in the flight itinerary.
adultsNoNumber of adult passengers (>= 1 if specified).
sortByNoSort the flight results based on price, departure time, arrival time, etc.
childrenNoNumber of child passengers.
currencyNoParameter defines the currency of the returned prices Provide one exact documented value (71 allowed), e.g. `ALL`, `DZD`.
maxPriceNoMaximum price limit for the flight search, in the selected currency.
arrivalIdYesSpecifies 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`).
deepSearchNoEnable deep search. Returns the same results as Google Flights in a browser, but takes longer to respond. Default is `false`.
returnDateNoThe return travel date in 'yyyy-MM-dd' format. Required when **type** is `roundTrip`.
showHiddenNoIndicates whether to include hidden options in the results.
departureIdYesSpecifies 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`).
maxDurationNoThe maximum total flight duration in minutes.
returnTimesNoSet 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
travelClassNoThe travel class for the flight (Economy, Premium Economy, Business, or First).
bookingTokenNoUsed to request booking options for selected flights. This token is found in the flight results and cannot be used with `departureToken`.
infantsOnLapNoNumber of infants sitting on an adult's lap.
outboundDateYesThe outbound travel date in 'yyyy-MM-dd' format.
infantsInSeatNoNumber of infants occupying seats.
lessEmissionsNoPrefer flight options with lower carbon emissions.
multiCityJsonNoThis 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.
outboundTimesNoSet 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
departureTokenNoUsed to select a flight and retrieve return flights for a round trip or the next leg of the itinerary for a multi-city trip.
excludeAirlinesNoA 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.
includeAirlinesNoA 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.
layoverDurationNoSet 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.
excludeConnectionsNoA comma separated list of specific airports to exclude as connections.
includeConnectionsNoA comma separated list of specific airports to allow as connections.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.