MCP server for searching Google Flights with real-time prices — from your AI assistant, no API key and no browser.
Installation · Tools · Examples · Limitations · 🇫🇷 Français
This MCP server searches Google Flights and returns live prices as 6 tools your assistant can call. No API key, no headless browser — it decodes Google's own query format directly. Ask in natural language:
You: Compare round-trip prices from Nice or Marseille to Tenerife, July 29 – August 12, for 2 adults and 2 kids.
Assistant: (calls
compare_destinations) Cheapest: Tenerife (TFS) €612 from NCE, 1 stop, 8 h 40 — Vueling. Marseille was €40 more. Full breakdown by date below.
Related MCP server: Google Flights MCP
Python ≥ 3.10
Any MCP client — Claude Code, Claude Desktop, Cursor…
git clone https://github.com/manganate006/google-flights-mcp
cd google-flights-mcp
python3 -m venv venv
./venv/bin/pip install "fast-flights>=3.0" "mcp[cli]>=1.0.0" "airportsdata>=20240101"claude mcp add google-flights -- \
/absolute/path/to/google-flights-mcp/venv/bin/python \
/absolute/path/to/google-flights-mcp/server.pyAdd to claude_desktop_config.json (or your client's MCP config):
{
"mcpServers": {
"google-flights": {
"command": "/absolute/path/to/google-flights-mcp/venv/bin/python",
"args": ["/absolute/path/to/google-flights-mcp/server.py"]
}
}
}No environment variables, no API key needed.
6 tools — full parameters in docs/TOOLS.md.
Tool | Purpose |
| Resolve a city/name to IATA code(s) — call this first (handles exonyms, fuzzy spelling), offline |
| Airports near a |
| One-way / round-trip; multiple departure and arrival airports; stop/airline/currency filters |
| Multi-leg itineraries |
| Cheapest departure day over a date range (throttled, ≤ 14 dates) |
| Rank several destinations by price from one origin (≤ 8) |
"Flights from Nice to Lisbon on August 1st for 2 adults and 2 children"
"Compare Nice vs Marseille to Tenerife, round-trip July 29 – August 12"
"Cheapest day to fly Nice → Barcelona between Aug 1 and Aug 15, direct only"
"Multi-city: Nice → Barcelona Aug 1, Barcelona → Lisbon Aug 8"
Sample search_flights result (trimmed):
{
"success": true,
"count": 7,
"flights": [
{ "price_total": 836, "currency": "EUR", "airlines": ["Vueling"],
"stops": 1, "total_duration_min": 215,
"legs": [{ "from": "NCE", "to": "LIS", "departure": "2026-08-01 22:30",
"duration_min": 215, "plane": "Airbus A320" }] }
]
}Google Flights is a JavaScript SPA, so scraping the HTML doesn't work. This server:
uses fast-flights v3 to encode queries as Protocol Buffers (the tfs= URL parameter);
fetches with primp (Rust HTTP client with TLS fingerprinting);
injects a SOCS consent cookie to bypass the EU GDPR "Before you continue" wall that otherwise blocks EU-based servers — the same acceptance your browser sends, without the click;
parses the flight data from the embedded <script class="ds:1"> payload.
Rate limiting — Google may throttle if called too often; space out searches
Prices are real-time but may differ slightly from booking sites (caching)
Currency defaults to EUR (per-search currency parameter)
Search-only — no booking; book on the airline's site
Compare the cheapest price to several destinations from the same departure airport(s).
Great for "where can we go cheaply" inspiration searches. One search per destination (throttled).
Args:
to_airports: Comma-separated IATA destination codes (e.g. "BCN,LIS,TFS")
departure_date: Departure date YYYY-MM-DD
return_date: Return date YYYY-MM-DD (empty for one-way)
from_airports: Comma-separated IATA departure codes (default: NCE,MRS)
adults: Number of adults
children: Number of children
seat: Seat class
max_stops: -1 = no limit (default), 0 = direct only
airlines: Comma-separated IATA airline codes to restrict to; empty = all
currency: ISO currency code (default EUR)
language: Language code (default fr)
| Name | Required | Description | Default |
|---|---|---|---|
| seat | No | economy | |
| adults | No | ||
| airlines | No | ||
| children | No | ||
| currency | No | EUR | |
| language | No | fr | |
| max_stops | No | ||
| return_date | No | ||
| to_airports | Yes | ||
| from_airports | No | ||
| departure_date | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions throttling ('one search per destination (throttled)'), which is a key behavioral trait. However, with no annotations provided, it does not disclose other behaviors such as data freshness, authentication needs, or rate limits beyond throttling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear one-sentence purpose, followed by a well-structured list of all parameters. No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, output schema present), the description covers the core purpose, parameter details, and a key behavioral note (throttling). It does not explain return value formatting or error handling, but the output schema may cover that. Overall, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides brief explanations for all 11 parameters, compensating for the 0% schema description coverage. Examples include 'Comma-separated IATA destination codes' for to_airports and 'Departure date YYYY-MM-DD' for departure_date. However, some parameters like 'seat' lack allowed values or further detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it compares cheapest price to several destinations from same departure airports, specifically mentioning 'where can we go cheaply inspiration searches'. This distinguishes it from siblings like search_flights which are for specific routes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use: for inspiration searches across multiple destinations. It notes 'one search per destination (throttled)', implying it's suitable when throttling is acceptable. However, it does not explicitly state when NOT to use compared to other tools like search_flights or search_flexible_dates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a city name or airport name into IATA airport codes.
Use this FIRST when you don't know the IATA code to pass to search_flights.
Args:
query: City, airport name, IATA code or country (e.g. "Barcelone", "Nice", "JFK")
limit: Max results (default 8)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the query types but does not disclose behavior like case sensitivity, partial match behavior, or what happens on no match. Adequate but could be more detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with two clear blocks: purpose/usage and Args. No fluff, but could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, description doesn't need to explain return values. It covers essential use and parameters. Lacks mention of error handling but otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates fully: explains 'query' (city, name, IATA, country with examples) and 'limit' (max results, default 8). Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Resolve a city name or airport name into IATA airport codes.' It also explicitly distinguishes it from a sibling by suggesting use before search_flights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use this FIRST when you don't know the IATA code to pass to search_flights.' This tells when to use and references an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find airports near a geographic coordinate, sorted by distance.
Useful for geolocated departure-airport selection.
Args:
lat: Latitude in decimal degrees
lon: Longitude in decimal degrees
radius_km: Search radius in kilometers (default 150)
limit: Max results (default 8)
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| limit | No | ||
| radius_km | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses sorting by distance, default radius, and limit. It could mention error handling or data freshness, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and includes an organized argument list. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations, the description provides sufficient information for a geolocation search tool with 4 parameters. The presence of an output schema (though not detailed here) reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description fully compensates by explaining each parameter: lat/lon as decimal degrees, radius_km as search radius with default 150, limit as max results with default 8.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and the resource 'airports near a geographic coordinate', and specifies sorting by distance. It distinguishes itself from sibling tools like find_airport by focusing on coordinate-based search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Useful for geolocated departure-airport selection', which indicates when to use it. It could be improved by explicitly stating when not to use it or comparing to alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the cheapest departure day over a date range. Ideal for flexible holiday planning.
Runs one search per candidate date (throttled) — keep ranges reasonable.
Args:
to_airport: IATA destination code
date_from: Earliest departure date YYYY-MM-DD
date_to: Latest departure date YYYY-MM-DD
from_airports: Comma-separated IATA departure codes (default: NCE,MRS)
trip_length_days: 0 = one-way (default); >0 = round-trip with return = departure + N days
weekends_only: If true, only consider Friday/Saturday departures
adults: Number of adults
children: Number of children
seat: Seat class
max_stops: -1 = no limit (default), 0 = direct only
airlines: Comma-separated IATA airline codes to restrict to; empty = all
currency: ISO currency code (default EUR)
language: Language code (default fr)
| Name | Required | Description | Default |
|---|---|---|---|
| seat | No | economy | |
| adults | No | ||
| date_to | Yes | ||
| airlines | No | ||
| children | No | ||
| currency | No | EUR | |
| language | No | fr | |
| date_from | Yes | ||
| max_stops | No | ||
| to_airport | Yes | ||
| from_airports | No | ||
| weekends_only | No | ||
| trip_length_days | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses that it runs one search per candidate date (throttled), a key behavioral trait. It also advises keeping ranges reasonable, implying rate limits. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a brief intro and structured parameter list. Every sentence adds value, and the purpose is front-loaded. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, output schema exists), the description covers all parameters and usage intent. It lacks details on error handling or empty results, but the output schema likely covers return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides detailed explanations for all 13 parameters in the 'Args' section, compensating for the 0% schema coverage. It clarifies defaults and special values (e.g., trip_length_days=0 for one-way).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds the cheapest departure day over a date range, with a specific use case for flexible holiday planning. It distinguishes from siblings like search_flights (fixed dates) and compare_destinations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises when to use ('ideal for flexible holiday planning') and warns about performance ('keep ranges reasonable'). It implies not to use for fixed dates, but does not explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Google Flights for the best prices.
Tries multiple departure airports (default: Nice NCE, Marseille MRS).
All airports must be IATA codes. If you only know a city name, call find_airport
(or find_airports_near) first to resolve it.
Args:
to_airport: IATA destination code(s), comma-separated for multi-airport cities (e.g. "BCN" or "LHR,LGW,STN")
departure_date: Departure date YYYY-MM-DD
return_date: Return date YYYY-MM-DD (empty for one-way)
from_airports: Comma-separated IATA departure codes (default: NCE,MRS)
adults: Number of adults (default 2)
children: Number of children (default 2)
infants_in_seat: Infants with seat (default 0)
infants_on_lap: Infants on lap (default 0)
seat: Seat class: economy, premium-economy, business, first
max_stops: Max stops: -1 = no limit (default), 0 = direct only, 1 = max one stop
airlines: Comma-separated IATA airline codes to restrict to (e.g. "AF,U2"); empty = all
currency: ISO currency code (default EUR)
language: Language code (default fr)
| Name | Required | Description | Default |
|---|---|---|---|
| seat | No | economy | |
| adults | No | ||
| airlines | No | ||
| children | No | ||
| currency | No | EUR | |
| language | No | fr | |
| max_stops | No | ||
| to_airport | Yes | ||
| return_date | No | ||
| from_airports | No | ||
| departure_date | Yes | ||
| infants_on_lap | No | ||
| infants_in_seat | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it tries multiple departure airports by default, accepts IATA codes, and details all parameters. No annotations exist, so description carries full burden. Could mention output structure or pricing limitations, but current coverage is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with summary, prerequisite note, and bullet-style Args list. Slightly verbose due to 13 parameters, but each line adds value. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers 13 parameters with defaults, 2 required ones marked, IATA code resolution guidance, and output schema exists to handle return values. Complete for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description defines every parameter with data types, defaults, and usage examples (e.g., 'YYYY-MM-DD', comma-separated IATA codes). Adds critical meaning beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States 'Search Google Flights for the best prices' with specific verb and resource. Clearly distinguishes from sibling tools (e.g., search_multi_city, search_flexible_dates) by focusing on simple round-trip/one-way search with multiple departure airports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call find_airport or find_airports_near if only city names are known. Provides default behavior and parameter format guidance. No mention of when not to use, but context about alternatives is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search multi-city flights on Google Flights.
Args:
legs: JSON array of legs, e.g. [{"from":"NCE","to":"BCN","date":"2026-08-01"},{"from":"BCN","to":"LIS","date":"2026-08-08"}]
adults: Number of adults
children: Number of children
seat: Seat class
max_stops: Max stops per leg: -1 = no limit (default), 0 = direct only
currency: ISO currency code (default EUR)
language: Language code (default fr)
| Name | Required | Description | Default |
|---|---|---|---|
| legs | Yes | ||
| seat | No | economy | |
| adults | No | ||
| children | No | ||
| currency | No | EUR | |
| language | No | fr | |
| max_stops | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure burden. It only lists parameters and lacks any mention of side effects, read-only nature, rate limits, or result size, which are critical for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and tightly organized with a single purpose line followed by a bullet-like parameter list. Every sentence contributes essential information, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, explaining return values is not required. However, the description omits behavioral context and usage guidance that would make the tool fully self-contained. Parameter details cover the basics but lack depth for parameters without enums.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds only minimal meaning for most parameters. The legs parameter includes an example, and max_stops explains its values, but others (e.g., seat, adults) just repeat the property names without adding allowed values or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Search multi-city flights on Google Flights,' which clearly states the tool's verb and resource. While it distinguishes from siblings like search_flights by name, it does not explicitly contrast with other sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as search_flights or compare_destinations. It does not mention prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: airport resolution by name, airport search by location, standard flight search, multi-city flight search, flexible date search, and destination comparison. There is no overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., find_airport, search_flights, compare_destinations), making them predictable and easy to understand.
Six tools cover the essential flight search functionalities (airport lookup, single trip, multi-city, flexible dates, destination comparison) without being excessive or too few. The scope is well-defined.
The tool set covers all common flight search scenarios: single trip, multi-city, flexible dates, and destination comparison, along with airport resolution from names or coordinates. No obvious gaps for a search-only service.
Flight Intelligence MCP — search, cheapest dates, multi-city, airline compare via Google Flights
Real-time Google Flights: one-way and round-trip fares over date ranges, with price verdicts.
Live Google Flights search: stopover itineraries, country sweeps, explore anywhere, booking links
Google Flights search data: fares, routes, stops, and price insights via a hosted MCP server.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/manganate006/google-flights-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server