LetsFG enables AI agents to search and book flights across hundreds of airlines and compare hotel rates across booking sites. Find fares using flexible dates and multi-airline combinations, compare total trip costs, check hotel availability, and complete bookings with confirmed reservations.
Encrypted at rest, isolated from the model
Resolved from an AES-256-GCM vault at the moment of the call and attached to the request — the model never sees the secrets.
Try asking
Read-only search for flights (plane tickets, airfare) between two cities or airports: one-way or round trip, adults, children and infants, economy to first class. Searches every airline in the world, low-cost carriers included, and the major travel sites in one go, checks every airport serving each city, tests split tickets and prices bags. Use when the traveller names an origin, a destination and dates; a one-way trip that can leave on any of several days is one call with date_from and date_to; search_flights_flexible_dates covers a round trip with open dates. Returns a `search_id` and an offer count, no offers; get_flight_results reads them and present_flight_options shows them to the traveller. Nothing is reserved, held or paid for, and nothing changes on the account.
Read-only flight search for a multi-city trip (several cities, open-jaw: New York to London, London to Paris, Paris to San Francisco) as one search: 2 to 6 flights in flying order, each with its own date. Every flight is searched like search_flights - every airline and the major travel sites, every airport of each city - and LetsFG puts the results together into whole trips: each flight on its own date, leaving from the city the one before it landed in, with time to change airports, priced as one total for the whole trip. Returns a `search_id` and an offer count, no offers; get_flight_results reads the trips, present_flight_options shows them, and book_flight books a trip as one booking with a ticket per flight. Nothing is reserved, held or paid for, and nothing changes on the account.
Read-only flight search for a round trip with open or flexible dates ('sometime in January', 'the cheapest week in spring', 'a long weekend'): a travel window (earliest departure, latest return) and a stay length in nights. An airline price calendar ranks every round trip of that length inside the window, and the most promising few date pairs - the best, a close second, and a stay a night or two shorter or longer - are then searched like search_flights. Returns a `search_id` whose get_flight_results holds the offers for the pair that is cheapest on real fares, names the pairs compared, and says when the other stay length really comes out cheaper. With a Developer API key it returns the calendar's dates only. Economy only. Nothing is reserved, held or paid for.
Read-only: returns the flight offers a search has found - prices, airlines, times, stops, bags and refundability - ranked as letsfg.co ranks them, with offer ids. Without wait_for_all it reports what has landed so far while the search card keeps updating; with wait_for_all=true it waits up to about twenty seconds and returns either the complete, settled set (every source, the split-ticket probe and the Google Flights enrichment) or a progress update, and can be called again with the same search_id. It never starts a new search and costs nothing. The result opens with its next step. The list itself is not shown to the traveller - present_flight_options draws the card with the chosen offers. Every offer carries `link`, letsfg.co's own page for that offer.
Read-only: shows the traveller a card with up to three offers from a flight search - A (recommended) best of both, B convenience, C price - each with a short title and a one-line reason, plus a 'something else' row. It displays offers the search already found; nothing is booked, reserved, held or paid for. The answer lists each option with its `link`, letsfg.co's page for that offer.
Read-only: the full trip page for one flight offer from a search. The itinerary leg by leg with flight numbers and aircraft, the on-time record of those flights over their last 14 departures (delays and cancellations), bag prices, the price and whether it is typical for the route, airport transfers and ground transport into the city, the contingency plan, compensation rights and back-up flights. It is the closer look at one option: times, the layover, reliability, bags, getting from the airport to the city. It reads from the finished search; nothing is booked or charged.
Read-only hotel search: real, bookable rooms and rates for hotels, aparthotels and other stays in a city or near a landmark, for given dates and guests. Every rate type, refundable and non-refundable alike. Nothing is reserved, held or paid for. `price` is the guest's all-in total in `currency` (USD unless another is asked for), charged in full at booking; nothing is added at checkout. Each offer says `refundable` and, when it is, `free_cancellation_until`, and carries a `booking_handle` object - the exact input book_hotel takes for that rate, with its identifiers and agreed price, used unchanged. Filters such as 'spa and parking, under 400, near the Eiffel Tower, with breakfast' map to `amenities`, `max_total_price`, `max_distance_km`+`near`, and adults/children/child_ages; the search applies them itself. `room_flexible=true` also tries the party split across several rooms when there are children. `dietary_hint` (e.g. 'vegan') is best-effort text matching only, not verified - the response's `caveats` say so.
Read-only: reads a hotel link (Booking.com, Expedia, Hotels.com, Agoda, Google) or a flight link (Google Flights, Kayak, Momondo, Skyscanner) - the hotel or route, the dates and the guests come from the link itself - and searches the same hotel's rooms, or the same trip, with LetsFG. Returns a search_id, as search_hotels and search_flights do; a hotel's results say whether that hotel has rooms and put it first. Dates, guests or children's ages the link does not carry can be given alongside it and take the place of the link's. When the hotel cannot be identified with certainty, the answer names the closest matches and nothing is searched. Holiday-rental links (Airbnb, Vrbo) are recognised and answered as such. Nothing is reserved, held or paid for.
Watches a price: a hotel from a LetsFG hotel search (its search_id and hotel_code) for the same dates and guests, or a flight trip (origin, destination, date_from, return_from, passengers, cabin). LetsFG re-checks it about once a day until the stay or the departure (at most 60 days) and e-mails the address given when it drops to a new low - at least 3% under the price when watched (a flight: its first reading by LetsFG), or at or under target_price - with a link that opens it in Claude. Watching the same thing twice keeps one watch; one person can watch up to 10. action='stop' with a watch_id ends a watch; every e-mail also carries a stop link. Nothing is reserved, held or paid for.
Read-only: best-value travel, refreshed every few hours. Flights: the best-value places to fly to from one airport, from Google Flights' explore listings - each with the day it is best on and an estimated total for the party - optionally narrowed to one month or a limit for the whole party; the return day is not part of the listings. Hotels (kind='hotels'): a city's well-rated hotels (Google 4.2+ or 4+ stars) with the lowest totals for the next weekend, 2 adults. Nothing is reserved, held or paid for.
Read-only: the latest LetsFG reading of each stay this person watches (or of one watch_id) - the total when watched, the latest total and when it was read, and the change. Answered from LetsFG's own readings, which are refreshed about once a day per stay; nothing is searched by this call, so calling it more often returns the same readings. A reading is not itself bookable: booking runs a fresh hotel search for that hotel and dates.
Read-only: a trip plan someone shared from LetsFG (a letsfg.co/t/... link or its plan id) - the flights, hotels or destinations they were looking at, for which dates and how many people, with the figures as they were when it was shared. Plans are kept for 30 days. Nothing is searched, reserved or paid for by this call; current availability comes from a fresh search.
Read-only: collects the hotels a search_hotels call found - name, stars, guest rating, rooms, board, cancellation terms and total price. A hotel search takes about half a minute, so search_hotels returns a search_id immediately and this returns the hotels once they land. While it answers status=running, a call with the same search_id about 15 seconds later continues that search; it never starts a new one. The list itself is not shown to the traveller - present_hotel_options draws the card with the chosen hotels. The account's saved preferences come back with the result.
App-only: the calls the one-time booking setup card (shown by book_flight and book_hotel) makes to read, save and refresh the traveller's details. It books and charges nothing.
Read-only, app-only: the progress of a flight search, which the search card polls to redraw itself. The offers themselves come from get_flight_results.
Read-only, app-only: the progress of a hotel search, which the search card polls to redraw itself. The hotels themselves come from get_hotel_results.
Read-only: shows the traveller a card with up to three hotels from a finished hotel search (the set get_hotel_results returned), best first - each with a short title and a one-line reason - plus a 'something else' row. It displays rates the search already found; nothing is booked, reserved, held or paid for.
Read-only: the full page for one hotel from a search_hotels result - photos, description, every room and rate with its board and cancellation terms, location and what is nearby, amenities, check-in/out times and the guest ratings by category - drawn for the traveller. Each room option returns its own `booking_handle`, the input book_hotel takes for that rate, used unchanged. A search's session lives 15 minutes; after that a new search_hotels is needed.
Read-only: resolves a place name to the hotel-search city ids search_hotels understands - for an ambiguous name (more than one 'Warsaw' or 'Springfield'), where the choices can be shown to the guest before searching. search_hotels resolves an unambiguous name on its own.
Prepares a booking of one hotel room from a search_hotels result for the signed-in LetsFG account and e-mails the guest an Approve button. This tool does not book, hold or charge anything: it answers `confirmation_required` with a `booking_job_id`, and the booking starts on LetsFG's side only when the guest presses Approve in that e-mail (and then the button on the page it opens) - outside the chat; it cannot be started or approved from the chat. The button works for 30 minutes. get_hotel_booking follows the `booking_job_id`: `awaiting_approval` until the button is pressed, then the booking, which takes several minutes (the rate is re-blocked, the room committed at the supplier, the supplier paid) until `status` is 'succeeded', 'failed' or 'attention' (a person at LetsFG is checking it and the hold is kept). A repeated call for the same room sends another e-mail; within minutes of an approval it answers `booking_started` instead. Money, once approved: the full `price` is held on the payment method saved on the account (not taken); LetsFG pays the supplier and captures the hold only once the hotel has confirmed the reservation. If the booking fails for any reason the hold is released and the guest pays nothing. A non-refundable rate cannot be refunded once it is confirmed. An account with no payment method connected yet is answered `payment_method_required` with an `add_card_url` (adding one charges nothing); the same call afterwards sends the Approve e-mail. On clients that show LetsFG's cards (claude.ai) `guests`, `email` and `phone` may be left out: the answer is then `setup_required`, and a one-time setup card beside it takes a name for every guest, the e-mail, the phone and the payment method, and remembers them for later bookings; `setup_complete` follows once it is filled in. Nothing is held or paid at either.
Read-only status of a hotel booking, by the `booking_job_id` book_hotel returned: it never books, approves or pays for anything. `awaiting_approval` = the guest has not pressed Approve in the e-mail yet (nothing booked or held); `approval_expired` / `not_started` = nothing was booked. Once approved it usually settles within 5 minutes, at `status` 'succeeded', 'failed' or 'attention' (a person at LetsFG is checking it; the hold is kept, and a new booking would be a second one). About every 20 seconds is often enough. On success the result includes `confirmation`, `total_price` + `currency` (the amount charged), `refundable`, `free_cancellation_until`, and the cancellation `terms`.
Asks the guest, by e-mail, to approve cancelling a confirmed hotel reservation. This tool does not cancel or refund anything itself: the room is released and the refund starts on LetsFG's side only when the guest presses Approve in that e-mail (and then the button on the page it opens) - outside the chat; it cannot be approved from the chat. The button works for 30 minutes. A second call with the same `confirmation` reports where it is (`awaiting_approval`, `cancelling`, `cancelled` with the refund, `not_cancelled` with the reason) and sends no second e-mail while one is waiting. Only a `refundable` booking can be cancelled, and only until its `free_cancellation_until` - the guest then gets 98% of what they paid back to the payment method (a 2% cancellation fee covers payment costs that are not refundable; the result's refund.amount and refund.cancellation_fee say exactly). If nothing had been taken yet, the hold is released whole. After that date, or on a non-refundable rate, the hotel's own cancellation ladder applies (`terms.ladder` in the booking result) and this tool refuses rather than forfeit money on the guest's behalf. Once approved it can take a couple of minutes.
Read-only: converts a city, airport or place name to the IATA airport and city codes a flight search needs (e.g. 'London' to LON, which covers every London airport).
Prepares a booking of a flight offer for the signed-in LetsFG account and e-mails the traveller an Approve button. This tool does not book, hold or charge anything: the booking starts on LetsFG's side only when the traveller presses Approve in that e-mail (and then the button on the page it opens) - outside the chat; it cannot be started or approved from the chat. Once approved it is the same booking letsfg.co's checkout makes: the price shown is held on the card saved on the account (not taken), a LetsFG booking agent buys the ticket from the seller, and the hold is captured only once the airline has issued a booking reference (PNR). If the booking fails, the hold is released and nothing is charged. Each call answers with one state, and each answer says what it needs next: - `setup_required`: the traveller's one-time setup (the details the airline needs, and a payment method) is incomplete; `still_needed` lists what is missing. On clients that show LetsFG's cards (claude.ai, ChatGPT) a setup card beside the reply collects all of it, so the call needs no details beyond names already given; elsewhere the details go in `passengers`. Nothing is booked or paid. - `setup_complete`: the setup was just finished and saved. Nothing is booked yet. - `missing_fields` / `invalid_fields`: a detail is missing, or present but wrong (each with a `reason`). Nothing is charged. - `payment_method_required`: everything is in hand except a card; `add_card_url` adds one on letsfg.co. Card details are never taken in the chat. - `payment_declined`: the connected card was refused (`decline_message` says why, in the traveller's words). With `pay_url`, the same payment is waiting on a secure payment page; paying it starts the booking by itself, and get_flight_booking follows it under the same booking_ref. `next_step` says what the traveller does there: pay another way (any card, Apple Pay, Google Pay, Revolut Pay) after an empty or refused card, or approve it with their bank (3-D Secure) after a bank security block. - `confirmation_required`: everything is ready and LetsFG has e-mailed the traveller an Approve button; nothing is booked or held. The answer's `booking_ref` follows it with get_flight_booking: `awaiting_approval` until the button is pressed (it works for 30 minutes), then the booking itself, which takes 4-11 minutes; stop_flight_booking cancels it before approval and stops it after. A repeated call for the same trip sends another e-mail. - `booking_started`: the same trip was approved in the e-mail minutes ago and is under way; it is not started again. Travellers are remembered on the account: a saved traveller can be booked by name alone, and anything new is saved for next time. A traveller not on file needs what an airline checkout asks for - full name, date of birth, gender, nationality, e-mail, phone with its country, home address, and a passport (number, issuing country, issue date, expiry) - REQUIRED for every traveller, because some sellers will not issue a ticket without one. The e-ticket goes to that e-mail. search_id and offer_id come from the same search; offers expire after about 15 minutes.
Passes on the traveller's answer to the question get_flight_booking reported in `awaiting_choice`. The booking is paused waiting for it, and the pause expires - without an answer the booking continues without the seat or the bag. It does not buy anything, accept a price or place a hold. A decline (`skip: true`) and seats that cost nothing are recorded at once. Anything that adds or raises a charge - a paid extra or a new price (`confirm: true`), another seller or another flight (`switch_to`), seats with a price - is only prepared: LetsFG e-mails the traveller an approval, and it takes effect when they press the button in that e-mail, on letsfg.co. The result says `approval_sent` and which inbox. Every answer is the traveller's own decision.
Stops a flight booking - for when the traveller says stop, wait, cancel, don't book, or changes their mind. Before they have pressed Approve in the e-mail it cancels the approval: nothing was booked, and the button no longer does anything. It needs no confirmation step and no status check first, and it is safe to call at once. Once it runs, nothing is paid unless the booking agent had already pressed pay at the seller: before that it stops at its next step (usually within a minute) and the hold on their card is released; after it, it is too late - the seller has been paid and the booking goes ahead. The answer's `message` says which, in words for the traveller.
Read-only status of a flight booking, by the `booking_ref` book_flight returned: it never books, approves, changes or pays for anything. States: `awaiting_approval` (the traveller has not pressed Approve in the e-mail yet - nothing booked or held), `approval_expired` / `not_started` (nothing was booked), `booking_in_progress` (the agent is at the seller's checkout), `completed` (booked - the PNR and the final total are in the answer), `failed` (not booked - the reason is in the answer), `needs_attention` (a person at LetsFG is checking it; the traveller will be e-mailed, and a new booking would be a second one). A booking takes 4-11 minutes; `updated_at_ms` says when it last moved, and a check every 20-30 seconds is often enough. stop_flight_booking stops a booking that is still running.
Read-only view of this account: payment status, usage, and the travellers on file (name, date of birth, contact, address, passport on file) from earlier LetsFG bookings - the details a booking reuses, so a saved traveller is booked by name. edit_my_details changes them.
Shows or changes the details LetsFG books with for this account: each saved traveller's name, date of birth, gender, nationality and passport, and the account holder's phone and home address. With no `details` it shows what is on file (the passport number masked) and the payment method. With `traveller` (the name as listed; omitted for the account holder) and `details` holding only the fields to change, in book_flight's passenger field names (e.g. {"phone_number": "+48 600 100 200"} or {"passport_number": "EA1234567", "passport_issue": "2024-02-28", "passport_expiry": "2034-02-28", "passport_country": "PL"}), it requests the change. A value that does not check out comes back in `invalid_fields` with the reason, and nothing is saved. Every change is approved from the account's e-mail: the first call answers `confirmation_required` and changes nothing; the same call after the Approve button is pressed saves it, and every later booking uses it. The account's e-mail address cannot be changed here; change_payment_method manages the payment method.
Replaces or removes the payment method saved on this LetsFG account. The account itself stays the same - its travellers, preferences and bookings. Both go through the account's own e-mail, never the chat: - `replace`: e-mails the person a link to add their new card. The current card stays until they add the new one, then it is removed. - `remove`: e-mails an Approve button and removes nothing; the same call after it is pressed removes the card, and the next booking asks for a card again. Refused while a booking on the card is still in progress. Card details are never taken in the chat.
Saves one lasting travel preference to this traveller's LetsFG account, so every future search - in this conversation and in later ones - can apply it: a standing rule such as 'I always take hotels with breakfast', 'no red-eyes', 'aisle seat', 'never more than one stop', 'I like being near the old town'. A one-off wish about the trip being planned now is not a lasting preference. Saved preferences come back automatically with search results.
Removes a saved preference from this traveller's LetsFG account, by its id or a few words of its text - for a standing preference that no longer holds ('I don't need breakfast any more').
Read-only: lists the travel preferences saved on this traveller's LetsFG account. The same preferences are also attached to every search result automatically.
Read-only: where to fly from one origin when the destination is open ('somewhere warm in January', 'a cheap city break', 'anywhere in Europe', 'the Balkans'). Returns the destinations inside a country, region or continent that can be flown to on given dates, each with its airport code, city, country, distance and flying time, and a places_id that present_destinations draws them from. Nothing is reserved, held or paid for, and nothing changes on the account.
Read-only: shows the traveller the destinations chosen from an explore_destinations result, as cards with a photo of each, in the order given. Nothing is reserved, held or paid for, and nothing changes on the account.
One endpoint, the same key, whichever client you use.
~/Library/Application Support/Claude/claude_desktop_config.json (Mac) · %APPDATA%\Claude\claude_desktop_config.json (Windows)
Replace API_KEY with your own key.
Already have an "mcpServers" section in your config? Just add the server entry inside it.
Discovery, routing, credentials, tool scoping and execution logs all happen at the gateway→connections stay ACTIVE with no work from you
LetsFG MCP runs through a gateway that holds the credentials, scopes the access and records every call.
Managed auth, hosted MCP servers, and every LetsFG MCP tool your agent needs.
Free to start.