LetsFG: an MCP server that books flights and hotels for AI agents

The 47-tabs problem LetsFG is aimed at

The README opens with a complaint rather than a specification: finding a flight or hotel should not mean checking 47 tabs or three hours of searching. That is the problem statement, and the target user is not a human traveller. It is an AI agent that has been asked to book a trip and has no tool for it. LetsFG positions itself as that tool: an MCP server at https://letsfg.co/developers/api/mcp plus a CLI and Python and JS SDKs, so an agent can search hundreds of airlines and the major booking sites and then complete a booking. The repository description also mentions per-flight reliability history, though the README excerpt does not explain how that history is computed or where it comes from. If you are building a travel agent, the pitch is that search is free and booking is real, meaning a fare is held on your card and a LetsFG booking agent buys the ticket, returning the airline's PNR. If you are building anything else, this is probably not your dependency.

What happens between the search call and the PNR

The architecture described is server-side. Your agent does not scrape airlines itself; it calls LetsFG's engine, which the README says scans airlines and major booking sites directly. The named sources include Skyscanner, Kiwi, Kayak and Momondo, plus direct airline sites such as Ryanair, United, Southwest, EasyJet, Spirit, Norwegian and AirAsia. The booking path is the unusual part. Search is free. Booking is not a direct API call to an airline: the fare is held on your card, a LetsFG booking agent (a person, or at least a human-in-the-loop process) buys the ticket, and your agent receives the airline's PNR. That is a deliberate design choice, and it tells you what LetsFG actually is. It is not an airline distribution pipe. It is an intermediary that fronts many sources and closes the transaction manually. The hotel side mirrors this with a hold-and-pay-later model: free-cancellation rates can be secured with a small upfront charge, with the balance paid later by link up to the hotel's own cancellation deadline. Release v2026.5.88 is titled "Hotels: agents can search, book and cancel real rooms", so cancellation is exposed too.

Getting an agent connected: the token, not an API key

The README gives three access paths. For agents, you add https://letsfg.co/developers/api/mcp as an MCP server. Approving that connection opens letsfg.co/connect, where you add a card in what the README calls a "0.00 Revolut setup" (nothing is charged and no Revolut account is needed). That token then searches for free and books. For scripts, you send the same token as an Authorization: Bearer header to the PFS endpoints. Python users can pip install letsfg; the npm package for the MCP side is letsfg-mcp. Release v2026.5.83 notes that payment-token auth replaced an earlier Twitter/X challenge, which is worth knowing if you find older setup instructions elsewhere. The developer API is described as a separate paid product for high-volume commercial use, and the README explicitly says most agents do not need it. That is a clear enough division, though it means the free path is tied to a card-on-file token rather than a conventional API key you can rotate on your own schedule.

The price comparison is the weakest evidence in the README

The README publishes two comparison tables, both dated 2026-08-05. The flight table checks five routes departing 2026-09-16 and reports LetsFG cheaper on every one, by $15 to $56, for a claimed $133 total. The hotel table compares two properties on a two-night stay with the same free-cancellation policy and reports savings of $37 and an unspecified amount for the second row, since the excerpt cuts off mid-table. The explanation offered is that Google Flights searches a limited set of airline partners while LetsFG searches everywhere, and that LetsFG does not apply demand-based inflation or cookie tracking. The mechanism claim is plausible and specific. The measurement is not. Five routes on one day, chosen by the vendor, with no stated method for matching fare classes, baggage rules or refundability, is a demonstration rather than a benchmark. The stronger and more checkable claim is the reproducibility one: the same search returns the same prices however often you run it. That is a property you can test yourself in an afternoon, and it is the one worth testing.

The licence field says NOASSERTION while the badge says MIT

GitHub reports the licence as NOASSERTION, which usually means the LICENSE file does not match a standard template the platform recognises. The README carries an MIT License badge linking to LICENSE. These two facts are in tension, and the repository material does not resolve it. For a Python package you pip install and an npm package you pull into an agent runtime, the licence determines whether you can vendor it, modify it, or ship it inside a closed product. Do not take the badge as the answer. Open the LICENSE file and read it, and check the PyPI and npm metadata separately, because the published artefacts may carry their own terms. Nothing here is legal advice, but a NOASSERTION label on a package that touches payments is a reason to read before you depend.

Where LetsFG is the wrong tool

The booking model is the limitation. If your agent needs deterministic, fully automated ticketing with no human step, LetsFG's flow does not give you that: a LetsFG booking agent buys the ticket after the fare is held. That introduces a queue, a business-hours question the README does not answer, and a failure mode where the hold expires before the purchase completes. Price volatility on held fares is not discussed either. The second constraint is dependency shape. Your agent's search and booking both route through letsfg.co, so availability is LetsFG's availability, and the token is a card-linked credential rather than a scoped key. Third, the reliability-history feature is advertised in the repository description but not explained in the README excerpt, so you cannot evaluate how it is sourced or whether it covers the carriers you care about. If you need to self-host the search layer, or you need contractual SLAs, this is not the project for you.

How this differs from calling an airline or a metasearch API directly

The obvious alternative is Amadeus Self-Service APIs, which expose flight offers, pricing and order management as a documented REST surface with a self-service tier. The difference in approach is structural rather than a matter of price. Amadeus is a distribution channel: you get GDS-sourced inventory, you authenticate with client credentials you control, and the booking call is yours to make and retry. LetsFG is an aggregator plus a buying service: it reads many consumer-facing sources, then a person completes the purchase. Amadeus gives you fewer sources and a narrower inventory slice, but a fully programmatic transaction and a key you can rotate. LetsFG gives you broader consumer-side coverage and a hold-and-pay-later hotel model that Amadeus does not offer, in exchange for a manual step and a card-linked token. If your agent must close bookings unattended, the Amadeus shape fits better. If your agent is assembling options and a human confirms, LetsFG's model is closer to how travel is actually bought.

Maintenance cost and what to check before you commit

The release cadence is fast and versioned by date: v2026.5.76 in May 2026, v2026.5.83 in July, v2026.5.88 in August, with the last push to main in September 2026. Two of those three releases changed the auth or booking path, including the replacement of the Twitter/X challenge with payment-token auth. Expect to track releases rather than pin and forget, because the token flow has already moved once. There is no stated deprecation policy in the material, and no migration guide is mentioned. The Python package is letsfg on PyPI; the MCP package is letsfg-mcp on npm. Before adopting, verify the LICENSE file against the MIT badge, confirm what the PFS endpoints accept beyond the Bearer token, and test the reproducibility claim by running the same search twice and comparing results. That last check costs one afternoon and tells you more about the product than either comparison table.

Editorial conclusion

Adopt LetsFG if you are building an agent that needs to search and actually book travel, and you are comfortable with a third-party booking agent holding a fare on a card. Do not adopt it if you need a permissively licensed, self-hostable search layer, or if you cannot tolerate a booking step that leaves the API surface. Before wiring it into anything, verify three things: the actual licence text in the LICENSE file, since GitHub reports NOASSERTION while the README badge says MIT; whether the MCP token survives a card change; and whether the PNR your agent receives is issued in your name or the booking agent's.

Official sources

1. Issues
2. LetsFG/LetsFG on GitHub
3. Project website
4. README
5. Releases