LetsFG — Flights & Hotels vs Chelaile MCP
A side-by-side look at the LetsFG — Flights & Hotels and Chelaile MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose LetsFG — Flights & Hotels for travel & transportation work as a local process; choose Chelaile MCP 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 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.
Choose Chelaile MCP when
- You need dedicated capabilities in the Travel & Transportation domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: No auth required.
- You want tools like
bus_list_cities, bus_get_city_config, bus_reverse_geocode.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Travel & Transportation | Travel & Transportation |
| Quality signal | 69/100 · Great | 64/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | No auth required |
| Pricing | Not declared | Free |
| Required env vars | None listed | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 2,175 | 23 |
| Directory activity | 2 views 1 installs 0 upvotes | 8 views 1 installs 0 upvotes |
| Tools | 14 | 15 |
| Full listing | View LetsFG — Flights & Hotels | View Chelaile MCP |
Tools & capabilities
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
Chelaile MCP tools 15
bus_list_citiesList cities supported by the realtime bus data service. Args: - hot_only (boolean, default true): return only the upstream's curated 'hot' set (~20 cities). Set false to dump the full ~480-city list (token-heavy, use sparingly). - response_format ('markdown' | 'json'): defaults to 'markdown' Returns (json): { "cities": [ { "cityId": "034", "cityName": "上海", "pinyin": "ShangHai", "supportSubway": true, "hot": true }, ... ] } Use when: the user mentions a city name and you don't have its ID. The hot set covers the top-tier cities the user almost certainly means.bus_get_city_configGet a city's runtime config: max poll interval and "arriving" time threshold. This is mostly relevant if you are deciding how aggressively to refresh — not for end-user questions about lines or stops. Args: - city_id (string, required): e.g. '034' (Shanghai), '027' (Beijing) - response_format ('markdown' | 'json') Returns (json): { "maxInterval": 30, "arrivingStationLimitSeconds": 180, "busDisplayConfig": { "lineDetail": "time#order#distance", "other": "time#order" } }bus_reverse_geocodeConvert WGS-84 lat/lng to a Chinese postal address (province, city, district, township, formatted address). Useful when you have raw GPS coordinates and need a human-readable place name, or the citycode/adcode to pass to other tools. Args: - lat (string, required): WGS-84 latitude, decimal, e.g. '31.230416' - lng (string, required): WGS-84 longitude, decimal, e.g. '121.473701' - response_format ('markdown' | 'json') Returns (json): { "formatted": "上海市黄浦区...", "province": "上海市", "city": "上海市", "district": "黄浦区", "township": "南京东路街道", "citycode": "021", "adcode": "310101" } For municipalities (Shanghai/Beijing/Tianjin/Chongqing) the upstream emits an empty 'city' value; this tool back-fills it with 'province' so the field is always a usable string.bus_get_my_locationResolve the caller's approximate location from their public IP — useful when the user asks something like "what's near me" without providing coordinates. **Precision is city-level (typically a few kilometres).** Good enough to identify the city and seed bus_get_nearby_stops with a starting guess. NOT precise enough to find the user's actual bus stop — for that, ask for a landmark/address and resolve it via bus_search. Caveats: - Resolves via ip-api.com (free tier; rate-limited but no auth). - VPN / corporate proxy → result reflects the proxy exit IP, not the user. - Cellular IPs often land on a provincial centroid. Args: - ip (string, optional): a specific IPv4/IPv6 to look up. Omit to use the mcp server process's own outbound IP (= the caller's machine when running locally). - response_format ('markdown' | 'json') Returns (json): { "lat": 31.2222, "lng": 121.4581, "gpsType": "wgs", "city": "上海", "region": "上海市", "country": "中国", "ip": "116.236.0.1", "isp": "China Telecom", "precision": "city-level (~10 km); not suitable for stop-level queries" } **Suggested workflow**: 1. Call this tool to identify the user's city (match 'city' field against bus_list_cities to get a cityId). 2. Pass lat/lng into bus_get_nearby_stops for a rough nearby list, OR ask the user to confirm a landmark and use bus_search.pois for sharper coordinates.bus_searchSearch inside a city by keyword. Returns matching lines, stations, and POIs in one call. Use this as the primary entry point when the user gives a line number, station name, or destination name without IDs. **Keyword tip**: plain "71", "71路", "地铁2号线", "陆家嘴" all work — the upstream is reasonably forgiving. If a short numeric returns empty, try appending "路". **Coordinate systems**: - 'pois' coords are GCJ-02 (use directly with bus_plan_transit) - 'stations' coords are WGS-84 (use with bus_get_nearby_stops / bus_get_line_realtime) Both are also marked with a 'gpsType' field. Args: - city_id (string, required): e.g. '034' - keyword (string, required) - response_format ('markdown' | 'json') Returns (json): { "highlightKey": "71路", "lines": [ { "name": "71", "lineNo": "r95817", "isSubway": false, "directions": [ { "direction": 0, "lineId": "21283603183", "startSn": "延安东路外滩", "endSn": "申昆路枢纽站" }, { "direction": 1, "lineId": "21283603182", "startSn": "申昆路枢纽站", "endSn": "延安东路外滩" } ], // Compat top-level fields mirror directions[0] (or first available). "lineId": "21283603183", "direction": 0, "startSn": "延安东路外滩", "endSn": "申昆路枢纽站" }, ... ], "stations": [{ "sId":"...", "sn":"西藏中路", "lat":31.231006, "lng":121.474316, "gpsType":"wgs", "physicalStId":"...", "namesakeStId":"...", "isSubway":false }, ...], "pois": [{ "name":"71路", "address":"...", "tag":"公交线路", "district":"黄浦区", "lat":31.233021, "lng":121.49073, "gpsType":"gcj" }, ...] } **Line folding**: each entry in 'lines' is one logical line (e.g. "71路"). The two travel directions live in 'directions[]'. Pick the lineId matching your desired direction. **Subway hint**: when 'isSubway' is true, the entry carries a 'hint' field — bus_get_line_detail will return empty for these lineIds. Use bus_get_stop_detail (metros field) or bus_plan_transit instead. **Follow-ups**: - directions[i].lineId → bus_get_line_detail (full stop list, first/last/price) — non-subway only - stations[*].physicalStId + namesakeStId → bus_get_stop_detail (NOTE: a few stations lack physicalStId — typically metro-only entries with subwayV2=1. For those, use bus_get_nearby_stops to resolve the bus platform IDs nearby.) - pois[*].lat/lng (GCJ) → bus_plan_transit as origin/destinationbus_search_morePaginated 'see more' for one category from bus_search. Args: - city_id (string, required) - keyword (string, required): same keyword used in bus_search - type ('1'|'2'|'3'): 1=more lines, 2=more stations, 3=more POIs (default '1') - response_format ('markdown' | 'json') Returns: same shape as bus_search but only the requested category is populated.bus_get_nearby_stopsList bus stops near a WGS-84 GPS coordinate, each annotated with the lines that pass through and the realtime buses approaching. **If you don't have coordinates**: call bus_get_my_location first (city-level precision via IP), or ask the user for a landmark and resolve it via bus_search.pois — the resulting lat/lng goes into this tool's lat/lng args. Args: - city_id (string, required): e.g. '034' - lat / lng (string, required): WGS-84 decimal coordinates - limit (number, default 5): how many of the closest stops to return (max 20) - response_format ('markdown' | 'json') Returns (json): { "stops": [ { "sId": "021-15232", "sn": "西藏中路", "distance": 87, "isSubway": false, "physicalStId": "...", "namesakeStId": "...", "firstLineId": "...", "lines": [ { "lineId": "...", "name": "71", "direction": 0, "endSn": "...", "status": "等待发车" | "不在运营时间" | "" (running), "preArrivalTime": "10:10" | undefined, "targetOrder": 2, "targetStationId": "021-15232", "buses": [ { "busId": "...", "order": 2, "arrivalTime": 1779070466055, "travelTime": 25, "distanceToDest": 90, "capacity": 0 } ] } ], "subwayLines": [ { "name": "地铁2号线", "shortName": "2号线", "color": "140,194,32", "directions": [{ "destName": "...", "firstTime": "05:31", "lastTime": "23:24" }] } ] } ] } Field notes: - buses[].arrivalTime is a ms timestamp; -1 = unknown - buses[].travelTime is seconds remaining; -1 = unknown - buses[].capacity: 0=light, 1=moderate, 2=crowded - If no realtime buses but the line is starting soon, 'preArrivalTime' will hold the next predicted dispatch ("10:12")bus_get_stop_detailFull detail for a stop: precise WGS-84 coordinates, every line that passes through (with first/last/price), realtime buses, and nearby metro lines. Args: - city_id (string, required) - physical_st_id (string, required): from bus_get_nearby_stops / bus_search - namesake_st_id (string, optional): recommended; from the same source - first_line_id (string, optional): a line to highlight - lat / lng (string, optional): caller's WGS-84 location, used to populate 'distance' - response_format ('markdown' | 'json') Returns (json): { "stations": [ { "sId": "...", "sn": "...", "lat": ..., "lng": ..., "distance": ..., "lines": [{ "lineId": "...", "name": "71", "direction": 0, "startSn": "...", "endSn": "...", "firstTime": "05:30", "lastTime": "23:30", "price": "2元", "targetOrder": 2, "buses": [...] }], "metros": [{ "name": "地铁14号线", "lineNo": "14号线", "color": "97,96,32" }] } ] } Multiple entries in stations[] mean the stop name maps to several physical platforms.bus_get_line_detailFull info for a line: rider-facing fields (name, first/last/price, stationsNum), the full ordered station list, the reverse-direction lineId, and every bus currently on the line. **Use this — not bus_get_timetable — to answer "is line X still running" or "first/last bus time" questions.** The timetable tool only has data for a small minority of lines. **Subway lines are NOT supported.** If bus_search returned a line with isSubway=true (e.g. lineId=1057 for 地铁2号线), this endpoint returns an empty payload — the response will carry `empty: true` and a `hint` field pointing at bus_get_nearby_stops / bus_plan_transit. Don't retry; route to those tools instead. Args: - city_id (string, required) - line_id (string, required): from bus_search.lines[*].lineId - lat / lng (string, optional): caller's WGS-84 coordinates - response_format ('markdown' | 'json') Returns (json): { "line": { "lineId":"...", "name":"71", "lineNo":"r95817", "direction":0, "startSn":"...", "endSn":"...", "firstTime":"05:30", "lastTime":"23:30", "price":"2元", "stationsNum":24 }, "stations": [{ "order":1, "sId":"...", "sn":"...", "wgsLat":..., "wgsLng":..., "physicalStId":"...", "namesakeStId":"...", "metros":[{"name":"地铁14号线","lineNo":"14号线","color":"97,96,32"}] }, ...], "buses": [{ "busId":"...", "order":2, "lat":..., "lng":..., "speed":5.7, "capacity":0, "distanceToWaitStn":...}], "reverseDirection": { "lineId":"...", "startSn":"...", "endSn":"...", "firstTime":"04:30", "lastTime":"22:30", "price":"2元" } | null, "depDesc": "...", "preArrivalTime": "...", "targetOrder": 24, "empty": true, "hint": "..." // present only when upstream returned no data (subway / retired line) } Each station carries: - 'order' → feed into bus_get_line_realtime / bus_list_line_buses as target_order - 'sId' → feed into bus_get_line_realtime as station_id (NOT into bus_get_stop_detail!) - 'physicalStId' + 'namesakeStId' → feed into bus_get_stop_detail to see every line through that stopbus_get_line_routePolyline coordinates for drawing a line on a map. Points with 'stopOrder' are actual stops; others are shape points between stops. Args: - city_id (string, required) - line_id (string, required) - include_shape (boolean, default false): false returns only stop markers (~25 points); true returns all shape points (~400-500). Skip unless you actually need to draw the line. - response_format ('markdown' | 'json') Returns (json): { "pointCount": 480, // total shape points upstream returned "stopCount": 23, // stop markers among them "points": [{ "lat":..., "lng":..., "stopOrder":1 }, ...] } 'points' is the filtered list — stops only by default, full polyline when include_shape=true. **Known caveat**: upstream sometimes omits the terminus stop from the polyline, so 'stopCount' may be one less than bus_get_line_detail's 'stationsNum' (e.g. 23 vs 24). Trust bus_get_line_detail for the authoritative station list; line_route is just for drawing. Markdown mode only summarises counts; request JSON to read coordinates.bus_get_line_realtimeCanonical "when will my bus arrive" tool. Returns every bus currently on the line, with the nearest one carrying an ETA to the waiting stop. **Important**: the upstream predicts an ETA for only the nearest bus heading to your stop. Buses farther up the route are returned (with position/speed/capacity) but their `eta` field is null. That's not a bug. **Args**: - city_id (string, required) - line_id (string, required): from bus_search - target_order (string, required): the waiting stop's order on the line. Source: bus_get_line_detail.stations[i].order, or bus_get_nearby_stops.stops[].lines[].targetOrder. - station_id (string, required): sId of the waiting stop - lat / lng (string, required): WGS-84 — the user's location is best; if unavailable, use the waiting stop's wgsLat/wgsLng (from line_detail.stations[i]). - response_format ('markdown' | 'json') Returns (json): { "line": { "lineId":"...", "name":"71", "direction":0, "endSn":"..." }, "targetOrder": 2, "realData": true, "buses": [ { "busId":"...", "licence":"...", "order":2, "lat":..., "lng":..., "speed":5.7, "capacity":0, "distanceToWaitStn":90, "eta":{"travelTime":25,"arrivalTime":1779070466055,"displayTime":"10:14"} }, { "busId":"...", "order":3, "lat":..., "lng":..., "speed":3, "capacity":0, "eta":null }, ... ], "note": "..." } Field notes: - The 'line' sub-object intentionally omits startSn — upstream does not return it on this endpoint. Read it from bus_get_line_detail if needed. - eta.travelTime is seconds remaining - eta.arrivalTime is a ms timestamp - eta.displayTime is a "HH:MM" hint from upstream - capacity: 0=light, 1=moderate, 2=crowdedbus_list_line_busesReturns the nearest bus heading to the anchor stop, with ETA and the bus's next stop name. **This is narrower than the name suggests.** Despite the upstream endpoint being called "busList", in practice it returns at most 1-2 buses (the imminent ones). For the FULL roster of every bus currently on the line, call **bus_get_line_detail** — its 'buses' array lists all live vehicles with positions. Use this tool when you want a quick "what's about to arrive" answer for a specific stop. Args: - city_id (string, required) - line_id (string, required) - target_order (string, required): the waiting stop's order on the line - station_name (string, required): display name of that anchor stop - response_format ('markdown' | 'json') Returns (json): { "targetOrder": 2, "buses": [ { "busId":"...", "licence":"...", "order":2, "lat":..., "lng":..., "speed":8.2, "capacity":0, "nextStop":"西藏中路", "eta":{"travelTime":214,"arrivalTime":..., "displayTime":"10:14"} } ] }- +3 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.
LetsFG — Flights & Hotels
{
"mcpServers": {
"letsfg-flights-hotels": {
"command": "npx",
"args": [
"-y",
"letsfg-mcp"
]
}
}
}
Chelaile MCP
{
"mcpServers": {
"peanutsplash-chelaile-mcp": {
"command": "npx",
"args": [
"-y",
"chelaile-mcp-server"
]
}
}
}
Frequently asked questions
LetsFG — Flights & Hotels is categorized under Travel & Transportation and uses a local stdio subprocess. Chelaile MCP belongs to Travel & Transportation and uses a local stdio subprocess. Pick LetsFG — Flights & Hotels for travel & transportation work and Chelaile MCP 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.
LetsFG — Flights & Hotels has no declared pricing — check the project's own site. Chelaile MCP is listed as free. Auth: no auth required. 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 letsfg-flights-hotels and peanutsplash-chelaile-mcp as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, LetsFG — Flights & Hotels has a quality signal of 69/100 (Great) with 2 views, 1 installs and 2,175 GitHub stars. Chelaile MCP has 64/100 (Good) with 8 views, 1 installs and 23 GitHub stars.