Allows searching Google Flights for one-way and round-trip flights with filters for dates, passengers, cabin class, stops, airlines, price, baggage, and more, returning flight details and a booking URL.
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., "@flights-mcp @flights-mcp Find me flights from London to Paris tomorrow"
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.
:airplane: An MCP server that lets LLMs search Google Flights, built on FastMCP and fast-flights.
search_flightsSearches one-way and round-trip flights. Omit return_date for a one-way search.
Key parameters:
Parameter | Description |
| Three-letter IATA codes, e.g. |
|
|
| Passengers (max 9 total) |
|
|
|
|
| Airline codes ( |
| Price and bag-fee filters |
| Fare-quality filters |
| Empty lets Google choose |
|
|
Each result includes price, airlines, stops, timezone-correct total duration,
per-segment details, CO2 estimates, and a google_flights_url reproducing the
search so a user can book.
Related MCP server: fli
The name flights-mcp on PyPI belongs to an unrelated project, so this server
is not published to PyPI. Install it straight from GitHub instead:
uvx --from git+https://github.com/FredrikBakken/flights-mcp flights-mcpTo pin a specific release, append the tag:
uvx --from git+https://github.com/FredrikBakken/flights-mcp@v0.1.0 flights-mcpBuilt wheels and sdists are also attached to each
GitHub release,
alongside a SHA256SUMS file, if you would rather install from an artifact:
uv tool install ./flights_mcp-0.1.0-py3-none-any.whlThe server speaks MCP over stdio, so it is normally launched by an MCP client
rather than by hand. Register it in Zed's settings.json:
{
"context_servers": {
"flights": {
"command": {
"path": "uvx",
"args": [
"--from",
"git+https://github.com/FredrikBakken/flights-mcp",
"flights-mcp"
]
}
}
}
}Or, when working on a local checkout:
{
"context_servers": {
"flights": {
"command": {
"path": "uv",
"args": ["run", "--directory", "/path/to/flights-mcp", "flights-mcp"]
}
}
}
}Environment variable | Description |
| Optional proxy URL used for outbound requests to Google. |
uv sync # install dependencies
uv run pytest # run the test suite
prek run --all-files # lint, format, type check
mise run update # upgrade tools and dependencies, refresh hooksCI runs the hooks, tests, and a build on every push and pull request.
To cut a release, bump the version and push a matching v* tag:
uv version --bump patch # or minor / major
git commit -am "Release v0.1.1"
git tag v0.1.1
git push origin main --tagsThe release workflow verifies that the tag matches the project version, runs the
tests, then builds and attaches the wheel, sdist, and SHA256SUMS to a GitHub
release.
This scrapes Google Flights. There is no official API, so results reflect
what Google currently serves and may change or be rate-limited. Treat prices
as indicative and confirm via google_flights_url.
Consent redirect. Requests from the EU/EEA get redirected to
consent.google.com. The server sends Google's SOCS consent cookie to avoid
this; if you still hit it, set FLIGHTS_MCP_PROXY.
Multi-city is not supported. Google returns an empty result payload for multi-city queries through this scraping approach, so no such tool is exposed.
Airport codes only. City names are not resolved; the calling model should map them to IATA codes.
Not on PyPI. The flights-mcp name there is an unrelated Duffel-API
project. Install from git or a GitHub release instead.
Search Google Flights for one-way or round-trip flights.
Omit return_date for a one-way search. Prices are totals for all
passengers in the requested currency. Results are live scrapes of Google
Flights and may change between calls, so treat them as indicative and share
the returned google_flights_url for booking.
| Name | Required | Description | Default |
|---|---|---|---|
| seat | No | Cabin class. | economy |
| adults | No | Adult passengers. | |
| sort_by | No | How to order the returned itineraries. | price |
| airlines | No | Restrict to these airline IATA codes (e.g. ['SK', 'LH']) or alliances ('ONEWORLD', 'SKYTEAM', 'STAR_ALLIANCE'). | |
| children | No | Children aged 2-11. | |
| currency | No | Currency for prices. Empty lets Google decide. | |
| language | No | Language for names. Empty lets Google decide. | |
| max_price | No | Maximum total price, in the requested currency. | |
| max_stops | No | Maximum stops per leg. Use 0 for non-stop only. | |
| to_airport | Yes | Destination IATA airport code, e.g. 'JFK'. | |
| max_results | No | Maximum itineraries to return. | |
| return_date | No | Return date in 'YYYY-MM-DD' format. Omit for a one-way search; providing it makes the search a round-trip. | |
| checked_bags | No | Checked bags to include in the price estimate. | |
| from_airport | Yes | Origin IATA airport code, e.g. 'OSL'. | |
| carry_on_bags | No | Carry-on bags to include in the price estimate. | |
| departure_date | Yes | Outbound date in 'YYYY-MM-DD' format. | |
| infants_on_lap | No | Infants on a lap. Requires one adult each. | |
| infants_in_seat | No | Infants occupying their own seat. | |
| exclude_basic_economy | No | Exclude basic economy fares. | |
| hide_separate_and_self_transfer | No | Hide separate-ticket and self-transfer itineraries. |
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of itineraries in this response. |
| currency | No | |
| truncated | No | True when more itineraries were available than were returned. |
| itineraries | No | |
| cheapest_price | No | Lowest price among the returned itineraries. |
| google_flights_url | Yes | Google Flights URL reproducing this exact search. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses that results are 'live scrapes of Google Flights' that 'may change between calls,' advises treating them as indicative, and directs users to the returned google_flights_url for booking. This adds meaningful behavioral context not available from annotations or schema alone.
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 four concise sentences with no filler. The purpose is front-loaded, and operational caveats about return_date, pricing, and result volatility are packed into a compact, readable structure.
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 having 20 parameters, the schema covers all parameter semantics, an output schema exists, and annotations declare read-only/open-world behavior. The description adds the critical operational caveats—live data, indicative results, and booking via the returned URL—making the complete picture sufficient for safe invocation.
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 baseline is 3. The description adds useful semantic context beyond the schema by clarifying that 'Prices are totals for all passengers in the requested currency,' which affects interpretation of currency, max_price, and passenger-count parameters. It also restates the return_date one-way/round-trip behavior.
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 uses a specific verb and resource: 'Search Google Flights for one-way or round-trip flights.' It clearly defines the tool's function and scope, and there are no sibling tools that could create ambiguity.
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 gives clear usage context for the main variant: 'Omit return_date for a one-way search.' It also explains that prices are totals for all passengers and that results are indicative. Since there are no sibling tools, exclusions or alternatives aren't applicable; this is clear context without 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.
v0.1.1search_flightsScored across 1 tool
Only one tool exists, so there is no chance of confusing it with another. Its purpose is clearly described as searching Google Flights.
The sole tool uses a clear verb_noun name (search_flights). With no other tools to conflict, naming consistency is trivially high.
A single tool is workable for a narrowly scoped search-only server, but it feels thin for a server named 'flights-mcp' which could reasonably include related operations.
The search tool covers one-way and round-trip searches, pricing, and a booking URL, so the core search workflow is complete. Minor gaps exist, such as no airport lookup or flight-status tools, but these are not core to the stated purpose.
whentofly: flexible-date economy/business flight search + price-level context for AI agents
Google Flights search data: fares, routes, stops, and price insights via a hosted MCP server.
Search award flights and cash fares, optimize points, and predict fares inside ChatGPT and Claude.
Flight search & booking for AI agents. 400+ airlines, $20-50 cheaper than OTAs.
