google-flights-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | 8000 | |
| RAPIDAPI_KEY | No |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_oneway_flightsA | FlightPowers one-way fare search: live prices read from Google Flights. Input: origin and destination IATA codes -- the destination may be several codes, as "BCN,LIS,ATH" or ["BCN","LIS","ATH"] -- plus either one departure date or a date range. Returns each flight's price, airline, duration, stops, a bookable buy_link, and Google's historical price range (price_insights_low / price_insights_high) so you can say whether a fare is actually a good deal. Use it for any one-way fare question, including open-ended ones. For a flexible search make ONE call with a date range and/or several destinations -- do NOT call it once per date. 'Cheapest flight to Sri Lanka anywhere in October' is one call, not thirty. Each date/destination combination is one billed request; the count and the plan's remaining quota come back in
Requires the caller's own RapidAPI key for the Google Flights Live API. Get one (free tier available) at https://rapidapi.com/mtnrabi/api/google-flights-live-api, then pass it as an |
| search_roundtrip_flightsA | FlightPowers round-trip fare search: live prices read from Google Flights, priced as paired legs rather than two separate one-ways. Input: origin and destination IATA codes -- the destination may be several codes, as "BCN,LIS,ATH" or ["BCN","LIS","ATH"] -- a departure date or range, and either a return date or a trip length in nights. Returns the total price for both legs, per-leg airline, stops and duration, and a single bookable buy_link for the trip. Use it for any return-trip fare question. For a flexible search make ONE call: pass departure_date_from / departure_date_to for the outbound range and Each date/destination combination is one billed request; the count and the plan's remaining quota come back in
Requires the caller's own RapidAPI key for the Google Flights Live API. Get one (free tier available) at https://rapidapi.com/mtnrabi/api/google-flights-live-api, then pass it as an |
| search_hotelsA | FlightPowers hotel search: live Booking.com availability and nightly prices for a destination and date range. Input: a free-text destination the way a person would say it ("Rome", "Tokyo Shibuya"), plus check-in and check-out dates. Returns each property's price, review score, room type, location and a booking link. Set price_as_seen_from to a two-letter country code to price the same stay the way a shopper resident in that country would see it, which no other travel tool here can do. Gaps are real but usually modest and property-dependent, and rates move between calls, so hold one named property fixed, call each country a few times, and never read one call per country as a gap. Rates go stale within minutes: never reuse an earlier result, search again. Requires the caller's own RapidAPI key for the Booking Live API. Get one (free tier available) at https://rapidapi.com/mtnrabi/api/booking-live-api, then pass it as an |
| find_hotel_by_nameA | FlightPowers single-property lookup: live Booking.com availability and pricing for one named property. Input: the hotel name a person would type (adding the city helps when a chain has many properties) plus check-in and check-out dates -- no internal property ID needed, the resolution is done for you. Returns the property's price, review score, room type and a booking link. Use it to check one specific hotel, or to track a single property's price over time. price_as_seen_from prices the stay as a shopper resident in that country would see it. Gaps are real but usually modest and property-dependent, and rates move between calls, so call each country a few times on this same property before reporting a gap. Rates go stale within minutes: never reuse an earlier result. Requires the caller's own RapidAPI key for the Booking Live API. Get one (free tier available) at https://rapidapi.com/mtnrabi/api/booking-live-api, then pass it as an |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| cheapest_dates | Scan a whole month (or any date range) for the lowest fare on a route and say whether the winner is actually a good price. |
| compare_destinations | Price several destinations from one origin over the same dates and rank them, to answer 'where can I go cheaply'. |
| plan_trip | Find round-trip options for a destination across flexible trip lengths, priced as paired legs, within a budget. |
| is_this_fare_good | Check a specific route and date against Google's historical price band and answer book-now or wait. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool targets a clearly distinct query type: one-way flights, round-trip flights, general hotel search, and specific hotel lookup. Even the two hotel tools are easy to differentiate because one is broad destination search and the other is single-property lookup.
Three tools follow the search_<subject> pattern: search_oneway_flights, search_roundtrip_flights, and search_hotels. find_hotel_by_name breaks the pattern by using find_ instead of search_, though it remains readable and predictable.
Four tools is a well-scoped set for a travel-search server. Each tool earns its place and the count avoids both bloat and thinness.
The core search workflows are covered: one-way flights, round-trip flights, hotel search, and named-hotel lookup. Obvious gaps include multi-city flight search and airport/place code resolution, but agents can work around these with external knowledge or by combining existing tools.