Skip to main content
Glama

google_flights

Search and retrieve Google Flights results for one-way, round-trip, or multi-city itineraries. Supports sorting, filtering, layover preferences, and booking token retrieval.

Instructions

Retrieves Google Flights results for one-way, round-trip, and multi-city searches, with sorting/filtering and booking token support. Costs 5 API credits per request. [Credits: 5 API credits per request] Notes: Two-step flow for full itineraries: first request returns flights plus a departure_token per option; re-request with departure_token to get return/next-segment flights, then use a resulting booking_token to fetch booking options (which ignores dates/filters). return_date required only for type=1; return_times only usable for type=1. exclude_airlines/include_airlines are mutually exclusive, as are departure_token/booking_token. Returns: { best_flights: [{flights: [{departure_airport: {id, name, time}, arrival_airport: {id, name, time}, duration, airplane, travel_class, flight_number, airline, legroom}], total_duration, price, type}] }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bagsNoNumber of carry-on bags. (default: 0)
htmlNoReturn the full HTML of the Google page. (default: false)
typeNoFlight type. Allowed values: 1 (Round trip, default), 2 (One way), 3 (Multi-city). (default: 1)
stopsNoMaximum number of stops. Allowed values: 0 (Any, default), 1 (Nonstop only), 2 (Up to 1 stop), 3 (Up to 2 stops). (default: 0)
adultsNoNumber of adult passengers. (default: 1)
countryNoTwo-letter country code for the Google search (e.g. US, UK, FR). (default: us)
sort_byNoSort order. Allowed values: 1 (Top flights, default), 2 (Price), 3 (Departure time), 4 (Arrival time), 5 (Duration), 6 (Emissions). (default: 1)
childrenNoNumber of child passengers. (default: 0)
currencyNoCurrency for returned prices. (default: USD)
languageNoLanguage of the results, e.g. en, es, fr, de. (default: en)
emissionsNoFilter by emission level. Allowed value: 1 (show only flights with lower emissions).
max_priceNoMaximum ticket price allowed. No limit by default.
arrival_idYesArrival point: 3-letter uppercase airport code or a location kgmid beginning with '/m/'. Multiple points comma-separated.
return_dateNoReturn travel date, format YYYY-MM-DD, e.g. 2026-03-06. Required when type=1 (Round trip).
departure_idYesDeparture point: 3-letter uppercase airport code (e.g. JFK, LHR) or a location kgmid beginning with '/m/' (e.g. /m/02_286 for San Francisco). Multiple points comma-separated.
max_durationNoMaximum total flight duration in minutes, e.g. 960 = up to 16 hours.
return_timesNoPreferred time range for the return flight; each number represents the start of an hour. Only used when type=1 (Round trip).
travel_classNoTravel class. Allowed values: 1 (Economy, default), 2 (Premium economy), 3 (Business), 4 (First class). (default: 1)
booking_tokenNoRetrieves booking options for a selected flight. Cannot be used with departure_token. When used, date-based parameters and all Advanced Filters parameters are ignored.
exclude_connsNoExclude specific connecting airports, comma-separated for multiple.
outbound_dateNoOutbound travel date, format YYYY-MM-DD, e.g. 2026-03-05.
infants_on_lapNoNumber of infants traveling on an adult's lap. (default: 0)
outbound_timesNoPreferred time range for the outbound flight; each number represents the start of an hour.
departure_tokenNoSelects a departure flight to fetch the next set of results (return flights for round trip, or next segment for multi-city). Cannot be used with booking_token.
infants_in_seatNoNumber of infants traveling in their own seat. (default: 0)
multi_city_jsonNoJSON string containing an array of flight segment objects, used to provide details for multi-city trips.
exclude_airlinesNoExclude specific airlines, each a 2-character IATA code. Cannot be used together with include_airlines.
include_airlinesNoInclude only specific airlines, each a 2-character IATA code. Cannot be used together with exclude_airlines.
layover_durationNoPreferred layover duration range in minutes, e.g. '75,240' for 1h15m to 4h.
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the cost (5 API credits per request), the two-step flow (multi-step process), mutual exclusions, and parameter interactions (e.g., booking_token ignores dates/filters). It also describes the return format. This gives good insight into the tool's behavior, though it could mention error handling or rate limits beyond credits.

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 informative but somewhat verbose and contains redundancy (credits mentioned twice: 'Costs 5 API credits per request. [Credits: 5 API credits per request]'). The structure is front-loaded with purpose but then mixes parameter notes and return format. Could be more concise by removing repetition and organizing flow better.

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?

Given the tool's complexity (29 parameters, multi-step flow), the description covers the essential two-step process, mutual exclusions, and a sample return format. It lacks detailed explanation of multi-city JSON structure and full enumeration of type values (only mentions round trip constraints). Still, it provides substantial context, and no output schema is present, so the return format description helps.

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?

The input schema has 100% description coverage, so each parameter is already documented. The description adds value by explaining interactions (e.g., return_date required only for type=1, mutual exclusions) and the multi-step flow involving departure_token and booking_token. This context helps understand parameter usage beyond the schema.

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 clearly states the tool retrieves Google Flights results for one-way, round-trip, and multi-city searches, with sorting/filtering and booking token support. It specifies the resource (Google Flights) and action (retrieves), and distinguishes it from sibling tools like google_hotels or general google_search.

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 provides clear context on when to use the tool, including a two-step flow for full itineraries, parameter requirements (e.g., return_date required for type=1), mutual exclusions (exclude/include airlines, departure_token/booking_token), and the return format. However, it does not explicitly state when NOT to use the tool or alternatives, but the sibling list makes it obvious.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/alessandrobenigni/ScrapingDog-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server