Skip to main content
Glama
nanwer
by nanwer

search_flights

Search live flight offers for a specified route and date range. Returns ranked options with prices, airlines, and segment details, using Google Flights data.

Instructions

🎯 RENDERING DIRECTIVE — READ FIRST. When this tool returns 2+ flight offers, you MUST present them as an interactive HTML/React artifact (an Artifacts block, not flowing prose). Each offer is a visually distinct CARD with a prominent "Book on Google Flights" button styled as an HTML button or large rounded link, NOT an inline markdown hyperlink. Plain prose with [text](url) links is NOT acceptable for multi-result responses — the user can't click a paragraph. If this call is part of a larger trip-plan response, the trip plan ITSELF should be an artifact and contain the flight cards. Single-result responses may use prose.

Search live flight offers for a given route and date range using Google Flights data.

Returns a ranked list of flight options with prices, airlines, segment details, and total trip durations. Does not book flights, only searches.

Times in the response are local to the departure or arrival airport, with the airport's IATA code attached so the timezone can be derived. Do not perform timezone math on these times without first converting them.

Origin and destination accept 3-letter IATA airport codes (HEL, JFK, LHR) AND city codes (WAS, NYC, LON, PAR, TYO, LAX/QLA, BOS, …). City codes auto-expand to the metro's busiest 3 airports and search them in parallel; results merge under one ranked list (cheaper variant wins on dedup). Use the airport code when the traveler insists on a specific airport. The currency Google Flights returns is determined by the request region and is surfaced in each offer's currency field; do not assume USD.

Filter parameters:

  • max_stops: one of ANY (default), NON_STOP, ONE_STOP_OR_FEWER, TWO_OR_FEWER_STOPS. The names mean "this many stops or fewer".

  • departure_window: a "HH-HH" string in 24-hour local time, e.g. "8-20" to restrict to outbound departures between 8am and 8pm local. Hours are inclusive of the start and EXCLUSIVE of the end — "8-20" matches 08:00 through 19:59 local time; a 20:00 or 20:30 departure does NOT match. Applies to the outbound leg only. Google Flights' native filter does not control the return leg.

  • inbound_window: a separate "HH-HH" window for the return leg. Same format and same inclusive-start/exclusive-end semantics as departure_window. Has no effect on one-way searches. When set, offers whose return-leg first segment departs outside this window are filtered out post-hoc.

  • airlines: an optional list of IATA airline codes. Shows offers where AT LEAST ONE of the listed airlines operates ANY segment of the itinerary. For example, ["FI"] returns options operated entirely or partly by Icelandair; it does NOT restrict to Icelandair-only itineraries. Omit or pass null for no airline filter.

Results from identical searches are cached for up to 5 minutes. If the user is about to act on a specific offer, re-run the search before committing to a number.

Dates must be today or future in UTC. The tool rejects past dates with an invalid_input error — if a user gives a date that may already be past in their local timezone, advance to the next valid day before calling.

Several fields are commonly null with this data source: baggage_allowance, last_ticketing_date, and seats_available. A null baggage_allowance means "the carrier did not surface this information," not "no checked bag is included." Do not state that a fare excludes checked bags based on a null value.

PRE-CALL ELICITATION: Before calling this tool, ensure the user has expressed preferences on the following. If any are unspecified, ask the user before searching. Do not assume defaults; results vary materially based on these.

  • Baggage: carry-on only, or checked bag needed (affects fare class and final price)

  • Connections: non-stop preferred, or okay with stops (sets max_stops)

  • Time of day: red-eye okay, hard arrival deadlines, preferred outbound departure window (sets departure_window), preferred return departure window (sets inbound_window)

  • Airline preferences: any airlines to prefer (loyalty programs) or avoid (sets airlines)

RESULT PRESENTATION: When returning 2 or more results to the user, render them as an interactive artifact rather than a text list. Each offer is a card showing:

  • Total price, prominent

  • Airlines (IATA codes)

  • Total trip duration and stop count for each leg

  • Departure and arrival times for outbound and inbound, labeled with airport codes

  • A "Book on Google Flights" button linking to the offer's booking_url, opening in a new tab

Sort cards by price ascending. For a single result, prose is fine.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
adultsNo
originYes
infantsNo
airlinesNo
childrenNo
max_stopsNoANY
cabin_classNoECONOMY
destinationYes
max_resultsNo
return_dateNo
departure_dateYes
inbound_windowNo
departure_windowNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations provided, the description fully carries the behavioral transparency burden. It discloses caching behavior (5-minute cache), date validation (rejects past dates), meaning of null fields (baggage_allowance, etc.), timezone handling (local times with IATA codes), city code expansion, and detailed filter semantics. No contradictions with annotations since none exist.

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 well-structured with clear sections but is overly long, including a rendering directive and pre-call elicitation that could be separated. While every sentence adds value, the length reduces conciseness. It front-loads the most important info but could be more succinct.

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?

Given the tool's complexity (13 parameters, 3 required, output schema exists), the description covers all critical aspects: parameter semantics, behavioral nuances, error handling, caching, and result presentation. It is comprehensive and leaves no major gaps for an AI agent to misuse the tool.

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 description coverage is 0%, so the description must compensate. It explains critical parameters like origin/destination (IATA and city codes), max_stops (with exact meanings), departure_window and inbound_window (inclusive-start/exclusive-end semantics), and airlines filter behavior. However, it does not explain simpler parameters like adults, children, infants, cabin_class, and max_results, leaving some gaps.

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's purpose: 'Search live flight offers for a given route and date range using Google Flights data.' It uses a specific verb ('search') and resource ('flight offers'), and implicitly distinguishes from sibling tools like search_cheapest_dates and watch_flight_price by focusing on live searches for specific routes and dates.

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 extensive 'PRE-CALL ELICITATION' guidance on what user preferences to collect before calling, which indirectly informs when to use the tool. However, it does not explicitly contrast with sibling tools or state when not to use this tool, missing a direct exclusion statement.

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/nanwer/trip-search-mcp'

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