Provides flight search capabilities via Google Flights, including one-way, round-trip, and multi-city itineraries with support for travel class, airline alliances, and currency preferences.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@google-flights-mcp Search one-way flights from ZRH to NRT on April 5"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Google Flights search via SerpApi. Optimized for Business/First class, Star Alliance, multi-city itineraries with EUR pricing.
search_flights — One-way or round-trip search
search_multi_city — Multi-leg itineraries (2-5 legs)
get_booking_options — Direct airline booking links
get_usage — Monthly API usage tracker
All defaults are configurable via environment variables in your MCP config:
Env var | Default | Description |
| (required) | Your SerpApi API key |
|
| 1=Economy, 2=Premium Economy, 3=Business, 4=First |
|
| Airline/alliance filter |
|
| Price currency |
|
| Google locale (affects pricing region) |
|
| Language |
|
| Number of passengers |
|
| Preferred connection airports |
|
| Home airports |
|
| Max flight results per search |
|
| Monthly search budget |
|
| Cache duration in ms (1hr) |
|
| Cache directory path |
Example with custom settings:
{
"mcpServers": {
"google-flights": {
"command": "node",
"args": ["/path/to/google-flights-mcp/dist/index.js"],
"env": {
"SERPAPI_KEY": "your-key",
"DEFAULT_TRAVEL_CLASS": "1",
"DEFAULT_AIRLINES": "",
"DEFAULT_CURRENCY": "USD",
"DEFAULT_GL": "us"
}
}
}
}Related MCP server: Google Flights MCP
Sign up at serpapi.com — free tier gives 100 searches/month.
npm install
npm run buildAdd to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or equivalent:
{
"mcpServers": {
"google-flights": {
"command": "node",
"args": ["/absolute/path/to/google-flights-mcp/dist/index.js"],
"env": {
"SERPAPI_KEY": "your-key-here"
}
}
}
}Add to ~/.claude/mcp.json:
{
"mcpServers": {
"google-flights": {
"command": "node",
"args": ["/absolute/path/to/google-flights-mcp/dist/index.js"],
"env": {
"SERPAPI_KEY": "your-key-here"
}
}
}
}"Find Business class flights from VIE to NRT, departing March 15 returning March 25"
"Search multi-city: VIE→NRT March 15, NRT→BKK March 20, BKK→VIE March 25"
"Get booking options for this flight" (uses booking_token from search results)
Responses are cached locally for 1 hour (matching SerpApi's server-side cache). Cached searches don't count against the 100/month limit. Cache files stored in .cache/ directory.
Every tool response includes a usage footer showing current consumption:
📊 API Usage: 43/100 searches used (57 remaining) · Resets March 1, 2026Multi-city searches cost 1 API call per leg (a 3-leg trip = 3 searches).
npm run dev # Watch mode
npm run build # Build once
npm start # Run serverOne real API call per endpoint to capture fixtures, then mock everything:
# Capture fixtures (one-time, needs SERPAPI_KEY)
SERPAPI_KEY=xxx npx ts-node test/capture-fixtures.ts
# Run tests (no API key needed)
npm testGet direct airline booking links and prices for selected flights. Requires a booking_token from a previous search result. Returns airline-direct and third-party booking URLs with prices.
| Name | Required | Description | Default |
|---|---|---|---|
| booking_token | Yes | Booking token from a flight search result. Found in the flight's booking_token field. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It adds that booking_token is required and what the return type is (airline-direct and third-party URLs with prices). However, it does not disclose whether this is a read-only operation, if it fetches live prices, or any rate limits.
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?
Three sentences, front-loaded with purpose and prerequisites, no waste. Each sentence earns its place.
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?
For a tool with one parameter and no output schema, the description is nearly complete: it states the purpose, prerequisite, and return content. It could mention whether the links expire or if prices are current, but overall adequate.
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 100%, so the schema already fully documents the booking_token parameter. The description adds no new syntactic or format details beyond what the schema provides; baseline 3 is appropriate.
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 a specific verb ('Get'), resource ('booking links and prices'), and scope ('for selected flights'). Clearly distinguishes from siblings like search_flights and search_multi_city.
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?
Implies usage context by requiring a booking_token from a previous search, which implicitly tells when to use it (after a flight search). However, it does not explicitly name alternatives or provide when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check current monthly SerpApi usage against the free tier limit (100 searches/month). Cached searches are free and not counted.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the important behavioral detail that cached searches are free and not counted, which helps interpret the returned usage number. However, it doesn't state what the response looks like, whether it's a safe read, or any rate limits on calling this tool.
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?
Two concise sentences, front-loaded with the main action and immediately followed by a crucial caveat about cached searches. No filler.
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?
For a simple no-param read tool with no output schema and no annotations, the description provides the essential context: what it checks and what counts against the limit. It's fairly complete, though a note on return format could help.
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?
Zero parameters, so the baseline is 4. There are no parameters to describe, and the description correctly doesn't invent any.
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 a specific verb and resource ('Check current monthly SerpApi usage') and adds the free tier limit context. It's clear what the tool does, though sibling tools are in a different domain (flights/booking) so no direct differentiation is needed.
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?
Implied usage is checking quota before making many search calls, but the description doesn't explicitly say when to use this versus not, or mention alternatives. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for one-way or round-trip flights. Returns Business class, Star Alliance results by default with EUR pricing. Use for simple A→B or A→B→A searches.
| Name | Required | Description | Default |
|---|---|---|---|
| stops | No | Max stops. 0=nonstop only, 1=up to 1 stop, etc. | |
| airlines | No | Comma-separated airline/alliance codes to include (e.g. STAR_ALLIANCE, LH, OS). Defaults to STAR_ALLIANCE. | |
| arrival_id | Yes | Arrival airport IATA code (e.g. NRT, MIA, BCN) | |
| return_date | No | Return date in YYYY-MM-DD format. Omit for one-way. | |
| departure_id | Yes | Departure airport IATA code (e.g. VIE, FRA, MBA) | |
| travel_class | No | 1=Economy, 2=Premium Economy, 3=Business (default), 4=First | |
| outbound_date | Yes | Departure date in YYYY-MM-DD format | |
| exclude_airlines | No | Comma-separated airline codes to exclude |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it usefully discloses defaults (Business class, Star Alliance, EUR pricing) that an agent could not infer. However it omits result volume, pagination, rate limits, or whether results are cached/live — meaningful gaps for a search tool.
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?
Three short sentences, front-loaded with the core capability before defaults and routing guidance. Efficient, though the sentence fragments read slightly clipped rather than polished.
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?
For an 8-parameter search tool with no output schema, the description covers purpose and defaults but says nothing about the shape, ordering, or volume of results returned. Adequate to invoke correctly, but incomplete about what comes back.
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 100%, so every parameter is already documented with IATA formats, date formats, cabin mapping and stop semantics. The description only restates the default cabin/alliance, adding no syntax or constraint meaning beyond the schema; baseline 3 applies.
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 a specific verb and resource ('Search for one-way or round-trip flights') and adds scope detail (default cabin, alliance, currency). The 'simple A→B or A→B→A' clause hints at the distinction from search_multi_city without naming it, so sibling differentiation is implicit rather than explicit.
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?
Gives clear usage context ('Use for simple A→B or A→B→A searches'), which implies the multi-city sibling should be used otherwise. It stops short of naming search_multi_city or stating exclusions explicitly, so it is strong but not fully routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for multi-city/multi-leg flights (2-5 legs). Primary tool for complex itineraries. Returns Leg 1 options first — use departure_token from results to fetch subsequent legs. Each leg costs 1 API search. Defaults: Business class, Star Alliance, EUR.
| Name | Required | Description | Default |
|---|---|---|---|
| legs | Yes | Array of flight legs in order | |
| airlines | No | Comma-separated airline/alliance codes to include | |
| travel_class | No | 1=Economy, 2=Premium Economy, 3=Business (default), 4=First | |
| departure_token | No | Token from a previous multi-city search to get the next leg. When provided, legs parameter is still required but only used for context. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses valuable traits: leg-by-leg sequencing, the departure_token handoff, and a per-leg API cost. However, it says nothing about the read-only/non-destructive nature, rate limits, or error behavior for a tool that consumes API quota — meaningful gaps for a no-annotation tool.
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?
Four tight sentences: purpose, workflow, cost, and defaults — all front-loaded with zero filler. Every sentence earns its place.
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?
Complete enough for the core workflow: it explains the multi-step leg fetching and token reuse, which an agent cannot infer from the schema alone. Minor gaps remain (safety profile, rate limits) but no output schema exists to require return-value explanation.
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 100%, so the schema fully documents legs (IATA codes, YYYY-MM-DD dates, 2-5 items), airlines, travel_class, and departure_token. The description only restates defaults (Business class, Star Alliance, EUR), adding little beyond the schema. Baseline 3 is appropriate.
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 a specific verb and resource ('Search for multi-city/multi-leg flights') with a scope constraint (2-5 legs) and explicitly positions itself as 'Primary tool for complex itineraries,' distinguishing it from the simpler search_flights sibling.
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?
Clearly explains the workflow ('Returns Leg 1 options first — use departure_token from results to fetch subsequent legs') and the cost model ('Each leg costs 1 API search'), giving strong context for when and how to use it. It doesn't name search_flights as the alternative for simple one-way/round-trip itineraries, so it stops short of full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_booking_optionsget_usagesearch_flightssearch_multi_cityScored across 4 tools
search_flights and search_multi_city are distinct in scope (simple vs. multi-leg), and get_booking_options and get_usage serve clearly different purposes. Minor potential confusion between search_flights and search_multi_city for 2-leg itineraries, but descriptions provide clear guidance.
All tools follow a consistent snake_case verb_noun pattern (get_booking_options, search_flights, search_multi_city, get_usage). No deviations in convention.
Four tools cover the essential workflow: searching flights (simple and multi-city), booking, and usage monitoring. Each tool is necessary and well-scoped for the purpose.
Covers flight search, booking options, and usage tracking, which are core to the domain. Missing operations like cancellation or booking completion, but booking links are provided for external completion.
Flight search MCP server providing search, pagination, and itinerary details for AI assistants.
Google Flights search data: fares, routes, stops, and price insights via a hosted MCP server.
Search and compare flight offers through a cache-aware Streamable HTTP MCP server for AI agents.
Real-time Google Flights fares for agents. Three things people do with this server. Scan for deals: one call takes a date range and a list of destination airports, expands every combination server side, and returns each fare with Google's own low, typical or high verdict. Put live search in your app: flat JSON with a bookable link on every result, and round trips priced as paired legs. Run a 24/7 AI travel agent: add the server, sign in with Google, and schedule it. No ads, no sponsored content. You bring your own RapidAPI key, so every search is billed to your plan and never to anyone else's. Add https://flights.flightpowers.com/mcp , click Sign in, sign in with Google, and paste your RapidAPI key once on the page that opens. Scripts and clients without a sign-in button send the key as x-rapidapi-key on the same URL.
