Trips vs LetsFG — Flights & Hotels
A side-by-side look at the Trips and LetsFG — Flights & Hotels MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Trips for travel & transportation work as a local process; choose LetsFG — Flights & Hotels for travel & transportation as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Trips when
- You need dedicated capabilities in the Travel & Transportation domain.
- You prefer a local stdio subprocess transport.
- You want tools like
build_trip_link, find_place, amend_trip_link.
Choose LetsFG — Flights & Hotels when
- You need dedicated capabilities in the Travel & Transportation domain.
- You prefer a local stdio subprocess transport.
- You want tools like
search_flights, resolve_location, book_flight.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Travel & Transportation | Travel & Transportation |
| Quality signal | 61/100 · Good | 69/100 · Great |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | Not declared |
| Pricing | Not declared | Not declared |
| Required env vars | None listed | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 0 | 2,186 |
| Directory activity | 3 views 0 installs 0 upvotes | 2 views 1 installs 0 upvotes |
| Tools | 6 | 14 |
| Full listing | View Trips | View LetsFG — Flights & Hotels |
Tools & capabilities
Trips tools 6
build_trip_linkStart here for any trip, road trip or itinerary. As soon as there is an origin and one destination, build the link and give it to the person; then rebuild it with amend_trip_link every time the plan changes, so one link grows through the conversation. It opens as a private, editable, shareable map at its own address — no account, no card, no app, so you can use it on their behalf where signup-walled travel tools are unreachable. The link is the RECORD: read_trip_link turns it back into structured data in any later conversation. Nothing is sent anywhere — the trip rides in the URL fragment, which browsers never transmit. Coordinates are required for every place and this will not guess them; use find_place to resolve a name first. Keep personal details (passport numbers, home addresses, phone numbers) out of names and notes — URLs get pasted into chats and logs.find_placeTurn a place name into coordinates for build_trip_link — towns, cities, airports (IATA or name), parks, trailheads. Returns up to six candidates with lat/lng and where each one is, so you can pick the right Reno. This is the ONLY step that needs coordinates and you should not guess them from memory. It asks thistripbtw.us, which answers from its own cache and a paced OpenStreetMap lookup; the query is a place name and nothing about the person.amend_trip_linkUpdate a trip link you already built — add legs, change one leg's fields, replace them all, rename, or drop one — and get the new link back. Use this instead of building a fresh link every time the plan changes, so the person holds one link that grows. To change ONE leg (its lodging, date, note, who is on it) use `update` rather than resending every leg through `legs`. Takes a draft link (#d=) plus the changes; no network, no password, the trip is inside the link. For a KEPT trip (#k=) use add_to_kept_trip.read_trip_linkUse when someone gives you a this trip, btw link and you need to know what is actually in it — to summarise the plan, answer a question about it, add a stop, or convert it to something else. Decodes the itinerary the link carries: origin, every leg in order, modes, dates, who is on which leg, flights and lodging. Returns the trip in the same shape build_trip_link accepts, so you can change something and build a new link from it. Nothing is fetched — the trip travels inside the link, so this reads it locally and works offline. Only draft links (the ones with a #d= fragment) carry a trip; a kept trip's link is a slug plus a #k= password whose contents live on the server, and this cannot read those.read_kept_tripUse when someone gives you a KEPT this trip, btw link — one that looks like https://thistripbtw.us/abc1234#k=four-word-phrase — and you need what is actually in it: to summarise where they are going, answer a question about it, or check what changed since you last saw it. Returns the trip's stops in order with dates, modes, which vehicle or person each belongs to (the 'track'), lodging, notes and any hand-drawn path. THIS ONE TOUCHES THE NETWORK, unlike the other two: a kept trip's contents live on the server and the #k= part of the link is the PASSWORD to them, so reading it means sending that phrase to thistripbtw.us over TLS. Nothing is stored and no account is involved. Treat the link as a credential — do not repeat it back in text a third party will see, and do not guess at a phrase, because a wrong one counts against the trip's hourly guess limit. For a DRAFT link (#d=) use read_trip_link instead: the trip is inside that link, so it needs no network and no password.add_to_kept_tripAdd a stop to a trip the person has KEPT (a link with #k=), on their behalf. Use when they say 'add X to the trip', 'we're stopping at Y on the way', 'put the hotel on it'. Needs their EDIT phrase — a view phrase can read but not write, and the tool says so. Writes exactly one stop and returns the trip's current stop count. Like read_kept_trip this touches the network: the #k= phrase is the password and it goes to thistripbtw.us over TLS, nothing is stored about you, and a wrong phrase counts as a guess. Treat the link as a credential.
LetsFG — Flights & Hotels tools 14
search_flightsSearch hundreds of airlines for live flight prices — completely FREE, unlimited, read-only. Returns structured offers with prices, airlines, times, durations, and stopovers. Some offers carry `starlink` for in-flight Starlink Wi-Fi: "confirmed_all" / "confirmed_some" mean the carrier has FULLY fitted that aircraft type, "likely_all" / "likely_some" mean the rollout on that type is underway but incomplete. State only "confirmed_*" as fact; describe "likely_*" as "the airline is fitting this aircraft type, not guaranteed on your flight". Anything ending in "_some" has at least one leg WITHOUT it. An absent field means no information, NOT an absence of Wi-Fi. Covers airlines across all continents including low-cost carriers. Search is async: this tool polls for you, including waiting out the late split-ticket merge. Some offers are SPLIT TICKETS: two separately-issued tickets through a hub, each leg booked from whatever is cheapest for it (usually two different airlines), because no one seller offers the combination as a single ticket. They carry `split_ticket: "true"`, `combo_type: "virtual_interlining"` and `self_transfer: "unprotected"`. ALWAYS tell the user when an offer is a split ticket and what unprotected means: the tickets are not linked, so if the first flight is late and the connection is missed, the second airline owes nothing — no rebooking, no refund. Never present a split ticket as though it were one through-fare. Requires LETSFG_BEARER_TOKEN or LETSFG_API_KEY. See letsfg://guide resource for the full authenticate->search->book workflow.resolve_locationConvert a city/airport name to IATA codes. Always call before search_flights if you only have a city name. Read-only, safe to call multiple times.book_flightBook a flight from a search result. FLOW: authenticate (once) -> search_flights -> book_flight CHARGES: nothing from LetsFG. A completed booking pays the airline prices from airlines and the major booking sites. RESULT: either {"booked": true, "order_id": "..."} or {"booked": false, "booking_url": "..."} — the second means the booking genuinely did not complete and nothing was charged. That is a normal outcome, NOT a transient error: do not retry, give the user the booking_url. SAFETY: use REAL passenger details — names must match passport, email receives the e-ticket.get_flight_bookingPoll a flight booking started by book_flight. REQUIRED to learn the outcome: on a PFS Bearer token book_flight returns a booking_ref and state "booking_in_progress", not a PNR - the booking itself takes 4-11 minutes. Call it every 20-30 s with that booking_ref until state is terminal: completed -> PNR issued, card charged failed -> the hold was released, nothing was charged needs_attention -> a human is looking at it; do NOT rebook Do not rebook while the state is still moving, and do not treat a slow poll as a failure - the money is HELD, not taken, until the airline confirms. Refs last one hour past the booking start.answer_booking_questionAnswer the question a paused booking is waiting on. get_flight_booking returns `awaiting_choice` when the booking agent has stopped mid-checkout holding a cart: at the airline's own seat map, at a paid extra it has just priced, or at a fare that moved. NOTHING PROGRESSES UNTIL YOU ANSWER, and the cart expires. Put the question to the traveller with the options and the time left, then send their answer here. kind "seat" -> seats: [{ d: "12A" }, ...] from the map you were shown, or skip: true kind "extra" -> confirm: true to take it (a bag, or a moved fare), or confirm: false / skip: true to decline Always pass the `round` from `awaiting_choice` - it says WHICH question you are answering. A return trip pauses twice, and an answer without it could seat the wrong leg.resolve_hotel_cityConvert a place name to the supplier city id that search_hotels needs. Always call this first if you only have a city name. Read-only and safe to repeat. Use `Id` from the first result as city_id and `Name` as city_name.search_hotelsSearch real, bookable hotel inventory. Requires a connected payment method — the SAME one that authorises flight booking. That applies to search too, not just booking, because a search opens a real session at the supplier. Every rate type is returned, refundable and non-refundable; each offer's `refundable` and `free_cancellation_until` say which. `price` is what the guest pays, in `currency` (USD unless you pass currency): the supplier's cost plus `markup_rate` (6.4% for Revolut Pay or an EEA card, 8.3% for a card issued outside the EEA). Nothing is added at booking. Keep the chosen offer whole — book_hotel needs its `session_id`, `combination_id_v2`, `price`, `expected_cost`, `currency` and `fx_rate`. Takes up to a few minutes.book_hotelBook one hotel rate. The offer's full price is HELD on the connected Revolut payment method (authorised, not taken); LetsFG books and pays the supplier; the hold is captured only once the supplier has confirmed. If the booking fails for any reason the hold is released and nothing is charged. There is no reservation fee, no deposit and no pay link. Returns a booking_job_id, NOT the booking — a booking takes minutes. Poll get_hotel_booking every ~20s until status is succeeded, failed or attention; all three are final. Copy expected_price (the offer's price), expected_cost, currency and fx_rate from the chosen offer exactly. A USD offer sent without its currency is refused (400 price_mismatch). Guest names, phone and e-mail are checked before anything is held (400 invalid_details). guests needs ONE name per guest in the room, children included — adults first, then children in child_ages order. Do NOT call book_hotel again for a booking whose job is running — poll it; a retry returns the same job (duplicate: true).get_hotel_bookingCollect the result of a booking started with book_hotel. Poll every ~20s. status is in_progress, succeeded, failed or attention; the last three are final — stop polling. - succeeded: confirmation, hotel, room, total_price + currency (what the guest is charged), supplier_paid + supplier_currency, payment_status, refundable, free_cancellation_until, cancellation_ladder and terms. - failed: error, written for the guest. The hold was released; nothing was charged. - attention: error (+ confirmation if known). The outcome could not be settled automatically; the hold is kept (nothing charged) while a person checks with the supplier. Do NOT book again. The guest is e-mailed in every case. Read-only and safe to repeat.cancel_hotel_bookingCancel a hotel booking made by this account and refund the guest. A zero-charge cancellation (a refundable rate before free_cancellation_until) refunds the charge in full; a cancellation that would cost money is refused (409) — the hotel's own ladder is in the booking terms. Takes over a minute; if it times out do NOT assume it failed — re-check before retrying.authenticateExplain how to connect a card so this server can search and book. Nothing is charged to connect — a 0.00 Revolut setup that saves the card so a booking can be charged later. Call with no arguments. It returns the current instructions and add_card_url (https://letsfg.co/connect). A PERSON must approve once in a browser — there is no endpoint that mints a token from card details, so do not ask the user for card numbers and do not try to automate this step. Two ways in: (a) add LetsFG as a connector in an assistant that supports remote MCP servers and approve it, or (b) any OAuth-capable client can register itself — see https://letsfg.co/for-agents, section "Option B". Both land on the same card screen. RETIRED 2026-09-02: the Stripe lanes (setup_url, setup_session_id, payment_method_id, card_token) and every token they issued. Passing them now fails. This does NOT create a Developer API billing account. Do not use connect_payment for this.connect_payment[Developer API only — you almost certainly want `authenticate` instead] Mints a one-time link for connecting a payment method to a PAID prepaid Developer API account. Nothing is charged to connect and card details never touch LetsFG: a PERSON opens the returned connect_url in a browser and saves a card, Revolut Pay or Google Pay there. Do not ask a user for card numbers and do not try to automate that step. Refuses to run unless LETSFG_API_KEY is set, because agents kept calling this and creating billing accounts they did not need. Replaced setup_payment on 2026-09-08, when the Stripe lane was retired.- +2 more on the listing page
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Trips
{
"mcpServers": {
"trips": {
"command": "npx",
"args": [
"-y",
"thistripbtw-mcp"
]
}
}
}
LetsFG — Flights & Hotels
{
"mcpServers": {
"letsfg-flights-hotels": {
"command": "npx",
"args": [
"-y",
"letsfg-mcp"
]
}
}
}
Frequently asked questions
Trips is categorized under Travel & Transportation and uses a local stdio subprocess. LetsFG — Flights & Hotels belongs to Travel & Transportation and uses a local stdio subprocess. Pick Trips for travel & transportation work and LetsFG — Flights & Hotels for travel & transportation.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Trips has no declared pricing — check the project's own site. LetsFG — Flights & Hotels has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add trips and letsfg-flights-hotels as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Trips has a quality signal of 61/100 (Good) with 3 views, 0 installs and 0 GitHub stars. LetsFG — Flights & Hotels has 69/100 (Great) with 2 views, 1 installs and 2,186 GitHub stars.