LetsFG: an MCP server and CLI that lets agents search and book flights and hotels

The problem LetsFG solves: agents that can search but cannot buy

Most travel APIs stop at search. An agent can pull a fare, compare it, and then has nothing to do with the answer, because the booking step sits behind a checkout page built for a browser and a human. LetsFG's pitch is that it closes that gap. The README states that search is free, while booking is real: the fare is held on the card, a LetsFG booking agent buys the ticket, and the caller receives the airline's PNR. That is a meaningful architectural choice. The project is not trying to be an OTA with a nicer front end. It is trying to be the layer an autonomous agent calls when it has already decided what to buy.

The audience follows from that. The repository ships an MCP server, a CLI, and Python and JS SDKs, plus files like AGENTS.md, CLAUDE.md, SKILL.md and a skills/ directory. Those are artefacts for people wiring agents together, not for someone planning a holiday. If you are writing a tool-use loop and you want flight and hotel inventory as a callable function, this is aimed at you. If you want a booking website, the homepage is the product, not the repository.

How the MCP endpoint, CLI and SDKs fit together

There are three access paths, and the README describes them as such. The agent path is an MCP server at https://letsfg.co/developers/api/mcp. Adding it as an MCP server triggers an approval step that opens letsfg.co/connect, where you add a card through what the README calls a 0.00 Revolut setup. Nothing is charged and no Revolut account is needed, but the resulting token is what lets the agent search for free and book. The script path reuses the same token as an Authorization: Bearer header against the PFS endpoints. The third path, the Developer API, the README describes as a separate paid product for high-volume commercial use, and it explicitly says most agents do not need it.

On the server side, the repository contains a Dockerfile for the MCP server that installs letsfg-mcp from npm and runs Chromium through Playwright, and a separate Dockerfile.python plus docker-compose.yml for CLI use. The compose file exposes LETSFG_MAX_BROWSERS, defaulting to 2, with a comment that you should increase it on hosts with more RAM. That tells you something the marketing copy does not: the search engine drives real browsers, and concurrency is bounded by memory. LETSFG_PROXY is there for bot-protected airlines, and LETSFG_NO_TELEMETRY disables search telemetry. A playwright_cache volume persists the Chromium download between runs.

The reliability-history feature mentioned in the project description is the part I would want to confirm before designing around it. The README leads with price comparisons, not with reliability data, so it is unclear from the repository root whether per-flight reliability is a field returned by the MCP tools or a website-only view.

Installing LetsFG and running a first search

The README points at pip install letsfg and at the npm package letsfg-mcp for the MCP server. The compose file gives the most concrete first run, because it pins the invocation style. From the repository root, this builds the Python image and runs a one-off search for London to Barcelona on 2026-06-01:

docker compose run --rm letsfg search LON BCN 2026-06-01

The same command accepts a --mode fast flag, and a round trip with two adults and JSON output looks like this:

docker compose run --rm letsfg search LHR JFK 2026-06-01 --return 2026-06-08 --adults 2 --json

Airport or city names are resolved with a separate subcommand, which is worth running first if you are unsure whether a code is recognised:

docker compose run --rm letsfg locations "New York"

Booking needs a key. The compose comments show creating a .env file with LETSFG_API_KEY=trav_..., then calling book with an offer id, a search id, a passenger payload and an email:

docker compose run --rm letsfg book off_xxx --search-id srch_xxx --passenger '{...}' --email [email protected]

The me subcommand checks the account behind that key. If you would rather not use Docker, the npm-based server image installs letsfg-mcp globally and runs it over stdio, which is the shape most MCP clients expect. Expect the first container build to be slow: it installs Chromium and a long list of GTK and NSS libraries.

Where LetsFG is the wrong tool

The booking path is the constraint. LetsFG does not hand your agent a ticket; it holds the fare on your card, has its own booking agent buy the ticket, and returns the PNR. That means a third party sits between you and the airline at the exact moment money moves, and your reconciliation, refund and chargeback flows have to account for it. If your compliance posture requires that you contract directly with the carrier, or that no external agent touches the payment instrument, this design disqualifies itself regardless of price.

The search path has its own limits. The compose file defaults LETSFG_MAX_BROWSERS to 2 and tells you to raise it on hosts with more RAM, so throughput on a small box is low by construction, and LETSFG_PROXY exists precisely because some airlines block automated access. A proxy is an operational dependency you will have to buy and rotate. The README's own framing also admits the ceiling: the comparison table covers five routes on one day, which is evidence that the approach can produce lower fares, not evidence about how it behaves across a full inventory or on a busy Monday.

Hotel coverage is new. The v2026.5.88 release notes describe hotels as arriving on 2026-08-04, so the hotel side of the API has a much shorter track record than flights. Treat hotel booking as the less proven half.

LetsFG compared with Google Flights and Skyscanner

Google Flights and Skyscanner are consumer search surfaces. You type a route, you get a list, you click through, and the transaction finishes on an airline or OTA site. There is no supported way for an agent to complete the purchase, which is exactly the gap LetsFG is selling into.

The difference in search approach is narrower than the README implies. LetsFG's stated method is to read airlines and major booking sites directly, and its comparison table names Skyscanner, Kiwi, Kayak and Momondo among the sources it queries. So on a given route you may be comparing LetsFG's aggregation of Skyscanner against Skyscanner itself. The claimed advantage is not a secret inventory; it is that repeat searches return the same price rather than an inflated one, because there is no cookie-based demand tracking. That is a testable claim and a reasonable one, but it is a claim about consistency, not about access.

Where the two genuinely diverge is the output. A Google Flights result is a page for a person. A LetsFG result is a structured object an agent can act on, with a booking call attached. If your agent is the user, that difference is the whole product. If a human is going to look at the results anyway, a browser and a search engine are still cheaper to operate.

Licence, maintenance and upgrade cost

The repository metadata reports the licence as NOASSERTION, which means GitHub could not map the LICENSE file to a known identifier. The README carries an MIT badge, and there is a LICENSE file at the repository root. Those two signals disagree, and the badge is not the licence. Read the file before you ship anything commercial, and if the terms matter to your legal team, treat the discrepancy as unresolved rather than assuming MIT. This is not legal advice; it is a description of what the repository shows.

On maintenance, the last push was on 2026-09-09, and the release cadence visible in the notes is brisk: v2026.5.76 in May 2026, v2026.5.83 in July, v2026.5.88 in August. The version scheme is date-based, so upgrades arrive often and the numbers do not tell you whether a release is breaking. The v2026.5.83 notes state that a payment-token auth mechanism replaced a Twitter/X challenge, which is the kind of change that would break an integration built against the earlier flow. Pin your dependency and read the release notes before bumping.

Operationally, budget for the browser layer. The image ships Chromium, the compose file sizes concurrency by RAM, and the proxy variable implies ongoing spend on residential proxies for the airlines that block automation. That is a running cost that a plain HTTP API client would not have.

Editorial conclusion

Adopt LetsFG if you are building an agent that needs live flight and hotel inventory and you are willing to route the final purchase through LetsFG's booking agents and a card token. Do not adopt it if you need a fully self-hosted booking stack with no third party in the payment path, or if you need a clearly identified open source licence, because the repository reports NOASSERTION while the README badge says MIT. Verify three things first: the actual terms in the LICENSE file, what the 0.00 Revolut setup token can and cannot charge, and whether the per-flight reliability history is exposed through the MCP tools or only on the website.

Frequently asked questions

Official sources

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