Google Flights Deals MCP Server
Provides a tool for searching Google Flights deals from a natural-language trip description, returning dated fares, typical route prices, airlines, stops, airports, and booking links as structured JSON.
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 Deals MCP Servercheapest dates for cherry blossoms in Japan flying from LAX"
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.
Google Flights Deals MCP Server
A hosted Model Context Protocol (MCP) server that gives Claude, Cursor, Windsurf and any other MCP client one Google Flights Deals tool. Describe a trip in plain language, such as "cherry blossom in Japan" or "beach escape", and get dated fares from one origin airport with the typical price beside them, the airline, the stops and a booking link, as structured JSON.
1,000 free credits every month, no card required, which is about 66 searches.
https://mcp.hasdata.com/mcp?apis=google_travel_flights_deals
Contents
Related MCP server: whentofly
What you need
An MCP client and a HasData API key from the dashboard, free to create with no card, and the free tier covers about 66 calls a month at the 15-credit rate. This is a remote server, so the simplest path is a URL and an x-api-key header, with no container to run and no Google account anywhere in the flow. A client that only speaks stdio reaches it through a thin launcher, published as @hasdata/google-flights-deals-mcp on npm and hasdata-google-flights-deals-mcp on PyPI, shown below.
Quick start
The server URL is the same for every client. We run it hands-on in Claude Code and Claude Desktop. The other blocks follow each client's own documented format for a remote server.
Field | Value |
URL |
|
Transport | HTTP, streamable |
Auth header |
|
Clients with OAuth support can add the same URL as a connector and sign in without putting a key in a config file.
claude mcp add --transport http google-flights-deals "https://mcp.hasdata.com/mcp?apis=google_travel_flights_deals" \
--header "x-api-key: HASDATA_API_KEY"{
"mcpServers": {
"google-flights-deals": {
"type": "http",
"url": "https://mcp.hasdata.com/mcp?apis=google_travel_flights_deals",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}{
"mcpServers": {
"google-flights-deals": {
"type": "streamable-http",
"url": "https://mcp.hasdata.com/mcp?apis=google_travel_flights_deals",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}{
"servers": {
"google-flights-deals": {
"type": "http",
"url": "https://mcp.hasdata.com/mcp?apis=google_travel_flights_deals",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}Example prompts
Prompts, not code. Paste one in and the agent picks the tool itself. Each is annotated with the calls it takes, because every successful call costs 15 credits.
I want to see cherry blossom in Japan, flying from LAX. What are the cheapest dates?
One call, 15 credits. Google picks the destinations and the date range from the description.
Beach escape from London in February, nothing over 600 pounds, direct only.
One call, 15 credits. The price ceiling and the stops filter both need a destination pinned with arrivalId, so the agent has to name one or drop the filters.
Same trip but to Tokyo specifically, ten days, business class.
One call, 15 credits. With arrivalId set, the trip length and the cabin become available.
Compare the cherry blossom idea from LAX and from JFK.
Two calls, 30 credits. One origin per call.
Tools
Tool | What it returns |
| Dated deals with the fare, the typical price for the route, flight duration, trip length, stops, the operating airline, the airports and a Google Flights booking link, plus the destinations and date range Google derived from the query. 15 credits a call |
One tool, 15 credits per successful call.
Find flight deals
hasdata_google_travel_flights_deals_getGoogleFlightsDeals
Parameter | Type | Required | Notes |
| string | yes | Free-text trip description, from a bare place name to a full sentence |
| string | yes | Origin as a three-letter uppercase IATA code, for example |
| string | Pins the destination instead of letting Google choose. Every filter below needs it | |
| string |
| |
| string |
| |
| string | An exact date, or a window as | |
| string | Same spelling as | |
| string | Preset length, | |
| string | Length in days, instead of | |
| string |
| |
| number | Ceiling per flight in minutes | |
| number | Ceiling in the currency of the request | |
| string | One or the other, never both |
The filters are the thing to get right. All of them require arrivalId. A prompt that asks for direct flights under a price cap while letting Google pick the destination is asking for two things that cannot be combined, and the honest move is to pin a destination or drop the filters rather than to send them and have them ignored.
searchInformation reports what Google made of the query: the departure airport in full with its city and coordinates, the dateRange it settled on, the priceRange it found and the airlines involved.
{
"searchInformation": {
"query": "cherry blossom in Japan",
"departure": { "airport": "LAX", "city": "Los Angeles", "country": "United States" },
"dateRange": { "from": "2027-03-01", "to": "2027-04-30" }
},
"flightDeals": [
{
"outboundDate": "2027-03-01",
"returnDate": "2027-03-08",
"price": { "value": 960, "currency": "USD" },
"typicalPrice": { "value": 1335, "currency": "USD" },
"discountPercent": 28,
"durationMinutes": 1320,
"tripLengthDays": 7,
"stops": 1,
"airlineCode": "CX",
"airline": "Cathay Pacific",
"multipleAirlines": false,
"departureAirport": "LAX",
"arrivalAirport": "HIJ",
"destination": { "city": "Hiroshima", "country": "Japan", "highlight": "Peace Park Memorial & Shukkei-en garden" },
"bookingLink": "https://www.google.com/travel/flights?tfs=…"
}
]
}Errors and failure paths
Your client almost never sees an HTTP error code from a tool call. The MCP layer answers 200 and puts the failure inside the result, with isError set to true and the reason as text.
discountPercent is the exception, not the rule. In a measured search returning five deals, only one carried it. typicalPrice was on all five, so a discount can be computed against it when the field is absent, but do not report "no discount" because the key is missing.
airline and airlineCode go missing together. Four of those five deals named an airline. The fifth set multipleAirlines to true instead, because the itinerary is flown by more than one carrier. Read multipleAirlines before reporting a carrier, and say "several airlines" rather than leaving the field blank.
A filter without arrivalId is not an error. It comes back as a successful, billed call that simply did not apply what was asked. Nothing in the payload marks the difference, so check the combination before sending rather than after.
Dates are what Google chose unless you pinned them. searchInformation.dateRange is the range it searched, which can be months away from today. Quote it when presenting prices, because a fare for next March is not a fare for next month.
Each successful call spends credits from the connected account. A call that fails validation is not billed.
Pricing, free tier and limits
The Google Flights Deals tool costs 15 credits per successful call, the same as the Google Flights API. The number of deals returned does not change the price.
The free tier is 1,000 credits every month with no card, which is about 66 searches.
Paid plans start at $59 a month for 200,000 credits, which is about 13,000 searches. The unit price falls on larger plans. Current numbers are on the plans page.
How it compares
Google Flights API | This server | |
Input | An origin, a destination and dates | A sentence, with the destination optional |
Who picks the destination | You | Google, from the description |
Who picks the dates | You | Google, unless you pin them |
Best for | A trip someone has already decided on | A trip someone is still imagining |
The two sit next to each other rather than competing. Use this one to find where and when, then the Google Flights API to price the itinerary once the trip is decided.
FAQ
Do I need a Google account?
No. The only credential involved is your HasData key.
Why were my filters ignored?
They almost certainly went out without arrivalId. Every filter on this tool needs a pinned destination, and a request that omits it still succeeds.
Can I search from several origins at once?
No. departureId takes one airport, so comparing origins means one call each.
How far ahead does it search?
As far as Google decides from the query. Read searchInformation.dateRange rather than assuming the next few weeks.
Is HasData affiliated with Google?
No. HasData is an independent web data provider and is not affiliated with, endorsed by or sponsored by Google. All trademarks belong to their owners.
Compliance and personal data
The server reads the public Google Flights deals interface. It carries no passenger data and books nothing.
HasData links
Product page and request builder | |
Endpoint documentation | |
Server documentation | |
Every tool in one server | |
Client walkthroughs | |
Plans and credit costs |
Development
npm install
npm testThe tests in test/ assert the tool contract, the part that can break without a commit here. They check that ?apis=google_travel_flights_deals returns the one expected tool, that its name and required parameters have not changed, that it carries a description, and that a real search still returns flightDeals with the documented fields.
Contributing
The parameter table and the sample above were read from the live schema and from a real call rather than from documentation. A correction is welcome when a field or a failure mode has changed. Open an issue with the response you saw.
License
MIT
Available Tools
1 toolhasdata_google_travel_flights_deals_getGoogleFlightsDealsgoogle_travel_flights_deals: GET /ARead-onlyInspect
Get Google Flights Deals Results
Turns a plain-language trip description ("I would like to see cherry blossom in Japan", "beach escape", "fireworks festival in Hong Kong") into flight deals from one origin airport, with Google's AI choosing the destinations and travel dates. Each deal carries outbound and return dates, price, flight duration, trip length in days, number of stops, operating airline, departure and arrival airports, and a direct Google Flights booking link; typical price with the discount against it, and a destination description with a photo, come back only for searches Google shaped itself. Also returns the destinations and date range Google derived from the query. Filters cover trip type, cabin class, stops, dates, trip length, price and duration ceilings, airlines and party size. Use for inspiration-driven travel search, seasonal and event-based fare discovery, deal alerting, and travel-content generation.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Free-text trip description, from a bare place name to a full sentence: - **Destination**: `Tokyo` - **Type of trip**: `beach escape`, `weekend getaway in Europe` - **Season or event**: `I would like to see cherry blossom in Japan` When the query implies a time of year, Google dates it itself and reports the range in `searchInformation.dateRange`. | |
| gl | No | The two-letter country code for the country you want to limit the search to. Provide one exact documented value (245 allowed), e.g. `ac`, `af`. | |
| hl | No | The two-letter language code for the language you want to use for the search. Provide one exact documented value (159 allowed), e.g. `af`, `ak`. | |
| type | No | Flight type. Requires `arrivalId`. - `1` / `roundTrip` — round trip (default) - `2` / `oneWay` — one way A one-way deal carries no `returnDate` and no `tripLengthDays`. | |
| stops | No | Maximum number of stops. Requires `arrivalId`. Omitted, any number is allowed. - `1` / `nonStop` — direct flights only - `2` / `oneStopOrFewer` — at most one connection - `3` / `twoStopsOrFewer` — at most two connections A route with nothing at that depth returns an empty `flightDeals` array, not an error — `nonStop` on a route without a direct flight is a valid, empty answer. | |
| adults | No | Number of adults. Prices cover the whole party, so raising this raises every deal price. Passenger counts reprice rather than narrow the search, so they need no `arrivalId`. The whole party must not exceed 9. | |
| children | No | Number of children, priced at their own fare. Counts towards the limit of 9 passengers. | |
| currency | No | Parameter defines the currency of the returned prices Provide one exact documented value (71 allowed), e.g. `ALL`, `DZD`. | |
| maxPrice | No | Maximum ticket price, inclusive. Requires `arrivalId`. Omitted, it is unbounded. Read in the currency of the request: `650` means 650 EUR when `currency` is `EUR`, and 650 USD by default. | |
| arrivalId | No | Pins the search to one destination instead of letting Google pick from the query. - **IATA code**: 3 uppercase letters, e.g. `NRT` for Tokyo Narita. - **Location kgmid**: starts with `/m/`, found in Wikidata under "Freebase ID", e.g. `/m/07dfk` for Tokyo. Required by every filter: `type`, `travelClass`, `stops`, `outboundDate`, `returnDate`, `travelDuration`, `tripLength`, `maxPrice`, `maxDuration`, `includeAirlines` and `excludeAirlines`. Without it Google drops them silently. | |
| returnDate | No | When to return, in the same exact-or-window spelling as `outboundDate`, which is required alongside it. Cannot be combined with `travelDuration` or `tripLength` — all three set the trip length. Ignored when `type` is `oneWay`. | |
| tripLength | No | Trip length in days. Requires `arrivalId`. Cannot be combined with `returnDate` or `travelDuration`. - **Exact**: `7` - **Range**: `5,10` — min first Pairs with `outboundDate` to limit the departure period. Ignored when `type` is `oneWay`. | |
| departureId | Yes | Departure airport as a 3-letter uppercase IATA code, e.g. `LAX` or `LHR`. Search on [IATA](https://www.iata.org/en/publications/directories/code-search). One airport per search; city names are not accepted. | |
| maxDuration | No | Maximum flight duration in minutes — `1500` for 25 hours. Requires `arrivalId`. Omitted, it is unbounded. Applies to each leg, not to the round trip. Google measures against a longer figure than the `durationMinutes` it returns, so set the ceiling above the flight you want: on a route whose shortest deal is 635 minutes, `635` comes back empty and `680` returns it. On an empty result, raise `maxDuration` by up to 200 before concluding the route has nothing. | |
| travelClass | No | Travel class. Requires `arrivalId`. - `1` / `economy` — economy (default) - `2` / `premiumEconomy` — premium economy - `3` / `business` — business - `4` / `first` — first Fares climb steeply: on LAX-NRT the same search ran $730 in economy against $2882 in business. | |
| infantsOnLap | No | Number of infants on an adult's lap. Counts towards the limit of 9 passengers. Google prices a lap infant above one in its own seat — the opposite of how airlines usually charge. | |
| outboundDate | No | When to depart. Requires `arrivalId`. - **Exact date**: `2026-12-10` - **Window**: `2026-12-01,2026-12-10` — any day within it Omitted, Google picks the dates from the query, or from whatever is cheapest. | |
| infantsInSeat | No | Number of infants in their own seat. Counts towards the limit of 9 passengers. | |
| travelDuration | No | Preset trip length. Requires `arrivalId`. Cannot be combined with `returnDate` or `tripLength`. - `1` / `week` — about a week (6-8 days) - `2` / `weekend` — a weekend (2-3 days) - `3` / `twoWeeks` — about two weeks (13-15 days) Pairs with `outboundDate` to limit the departure period. Ignored when `type` is `oneWay`. | |
| excludeAirlines | No | Drops these airlines from the deals. Requires `arrivalId`. Cannot be combined with `includeAirlines`. Takes the same values as `includeAirlines`. | |
| includeAirlines | No | Keeps only these airlines. Requires `arrivalId`. Cannot be combined with `excludeAirlines`. Comma-separated 2-character IATA codes (`AF`, `UA`, `B6`) and Google's alliances `STAR_ALLIANCE`, `SKYTEAM`, `ONEWORLD`. The two can be mixed. An airline that does not serve the route returns an empty `flightDeals` array, not an error. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: which fields always come back (dates, price, duration, stops, airline, booking link) versus which only appear for searches Google shaped itself (typical price, discount, destination photo), plus that the response includes derived destinations and date range. No permissions, rate limits, or pagination behavior are mentioned, keeping it short of 5 with annotations already carrying the safety story.
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 first sentence front-loads what the tool does, followed by the plain-language input examples, then the return payload, then filters, then use cases — a sensible order. It is dense and long-ish, but nearly every clause carries information (the conditional return fields and the derived destinations/date range are not stated anywhere else).
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?
With 21 parameters and no output schema, the description is the only place describing what comes back, and it covers the return shape, the conditional fields, and the derived search information. Combined with a 100%-covered schema, an agent has enough to call it correctly; only the behavior of party-size repricing and the empty-result semantics of stops/airlines live exclusively in the schema, leaving minor room for improvement.
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% and the per-parameter descriptions are unusually rich (the maxDuration measurement caveat, the arrivalId requirement for every filter, the date-window spellings), so the schema does the heavy lifting. The description only groups the filters at a high level (trip type, cabin class, stops, dates, trip length, price and duration ceilings, airlines, party size), which maps onto the schema rather than adding meaning. 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?
The description states a specific verb and resource — turning a plain-language trip description into flight deals with Google choosing destinations and dates — which is far more than a restatement of the name. It implicitly separates this from the route-pinned sibling (getGoogleFlights), which requires arrivalId, but never names that alternative explicitly, so sibling differentiation is inferable rather than stated.
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?
"Use for inspiration-driven travel search, seasonal and event-based fare discovery, deal alerting, and travel-content generation" gives concrete when-to-use scenarios with examples of the query style (cherry blossom, beach escape, festival). There is no explicit when-not-to-use or named alternative for a user who already knows their exact destination and dates, which is the main remaining gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.0.0- First observed
hasdata_google_travel_flights_deals_getGoogleFlightsDeals
TDQS
Scored across 1 tool
There is only one tool, so there is no possibility of an agent confusing it with another tool in the set. Its single purpose — fetching Google Flights deals from a natural-language trip description — is unambiguous.
With a single tool there is no cross-tool pattern to compare, but the name itself is a verbose auto-generated composite that embeds camelCase ('getGoogleFlightsDeals') inside a snake_case namespace prefix. It is readable but not a clean, predictable convention.
One tool is borderline thin even for a narrow API-wrapper server. The endpoint is rich (many filters), but a lone tool offers no room for adjacent operations such as airport/location lookup or deal detail retrieval.
The tool covers the core deals-search workflow with extensive filters, dates, pricing and booking links, which is good for the stated purpose. However, there are no supporting operations (e.g., resolving origins, retrieving deal details beyond the link, or alerting hooks), leaving some dead ends for agents.
Maintenance
Related MCP Connectors
Google Flights search data: fares, routes, stops, and price insights via a hosted MCP server.
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.
AI marketplace — flights, tours, activities, transport & more via MCP. No auth required.
Flight search, airfare analytics, flexible destinations
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables AI clients to explore cheapest destinations, optimize multi-leg flight itineraries, and reference airport/region data via MCP tools and resources.MIT
- AlicenseNot gradedqualityBmaintenanceFlight search for AI agents: flexible-date cheapest round-trips with a good-price verdict from historical data. Hosted remote MCP, free, no key.3MIT
- AlicenseAqualityAmaintenanceEnables MCP clients to search one-way, round-trip, and multi-city itineraries and retrieve fares, flight legs, carbon emissions and price history as structured JSON.1307 npm171 PyPI6MIT
- AlicenseAqualityBmaintenanceEnables real-time flight fare searches across date ranges and multiple destinations, with historical price insights and booking links. Provides one-way and round-trip search tools through MCP.41MIT