Skip to main content
Glama
marcopa84

Google Flights MCP

by marcopa84

search_flights

Read-only

Find and compare one-way or round-trip flight options between two airports by date, with filters for cabin, stops, passengers, and sorting by price, duration, or departure.

Instructions

Search flights between two airports on a given date (one-way or round-trip).

sort_by: 'price' (default), 'duration' or 'departure'.

Input Schema

NameRequiredDescriptionDefault
cabinNoeconomy
adultsNo
originYes3-letter IATA airport code, e.g. MXP
infantsNo
sort_byNoprice
childrenNo
currencyNoEUR
max_stopsNo0 = nonstop only; omit for any
destinationYes3-letter IATA airport code, e.g. MXP
max_resultsNo
return_dateNoYYYY-MM-DD; omit for one-way
departure_dateYesDate as YYYY-MM-DD

Output Schema

NameRequiredDescriptionDefault
noteNo
countYes
originYes
backendYes
currencyYes
destinationYes
itinerariesYes
return_dateNo
departure_dateYes
google_flights_urlYesOpen this link to see/book on Google Flights

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-data scope are covered. The description adds only the trip-shape and sort behavior, disclosing nothing about result limits (max_results defaults to 10, caps at 30), caching, or availability that would otherwise be invisible.

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

Conciseness4/5

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

The purpose statement is front-loaded in one clean sentence, and the second line is short. The sort_by line is slightly cryptic in form (bare key: values) but contains no wasted prose.

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

Completeness2/5

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

For a 12-parameter tool with just 42% schema coverage, the description should carry more weight, especially on passenger-composition semantics and result caps. It does not explain the max_stops/max_results tradeoffs beyond the schema text, nor how it relates to the three sibling search tools; the output schema does relieve it of explaining return values.

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

Parameters2/5

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

Schema description coverage is only 42% of 12 parameters. The description usefully enumerates the sort_by values ('price' default, 'duration', 'departure'), which the schema leaves as a bare string, but it says nothing about adults/children/infants, cabin, currency, or max_results, leaving most parameters unexplained.

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

Purpose4/5

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

States a specific verb and resource ('search flights between two airports on a given date') and clarifies the supported trip shapes (one-way/round-trip). It does not, however, distinguish itself from siblings like find_cheapest_dates or compare_airports, so an agent still has to infer which search entry point applies.

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

Usage Guidelines3/5

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

Usage is only implied: the agent learns this searches a single origin-destination pair on a date, and the sort_by hint suggests ranking behavior. No when-to-use, when-not-to-use, or sibling routing is given (e.g., use find_cheapest_dates to scan a window).

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