Access to live flight search results inside conversational agents or automated pipelines is valuable but uncommon: Fli fills that gap by exposing Google Flights search through a local MCP server and a Python/CLI library, letting tools query fares and date ranges in structured form.
What Sets It Apart
- Direct API interaction (reverse‑engineered) instead of page scraping — so queries return structured JSON that is faster and less brittle than HTML parsing for downstream consumption.
- Built-in MCP server that exposes two focused tools (search_flights, search_dates) — so LLM assistants can call flight searches as functions during a conversation.
- Rich filter model (departure windows, cabin class, max stops, airline lists, sort options) and retry/rate‑limit protections — so you can encode precise business rules and handle transient errors.
- CLI + Python library + example suite — so it fits both interactive use and programmatic integration without reimplementing the client stack.
Who It's For and Trade-offs
Great fit if you need conversational or automated flight lookups (price discovery, date flexibility checks, travel planning assistants) and want structured results consumable by LLMs or backend services.
Look elsewhere if you require an official, supported flights API or guaranteed long‑term stability: because Fli relies on reverse engineering of Google Flights, endpoints or response formats may break, and use could raise service‑terms concerns. It is a search and discovery layer, not a booking/payment engine — booking flows still require carrier/OTA APIs.
Where It Fits
Think of Fli as the glue between travel data and AI-driven interfaces: it transforms Google Flights search into machine‑friendly tools (MCP endpoints or Python objects) that conversational agents or automation scripts can call directly, speeding prototype development for travel assistants while requiring careful monitoring for breakages and compliance.
