BoostedTravel vs Kiaaccess MCP
A side-by-side look at the BoostedTravel and Kiaaccess MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose BoostedTravel for travel & transportation work as a local process; choose Kiaaccess 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 BoostedTravel when
- You need dedicated capabilities in the Travel & Transportation domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: API key required.
- You have the keys it needs:
LETSFG_BEARER_TOKEN, LETSFG_API_KEY. - You want tools like
search_flights, resolve_location, unlock_flight_offer.
Choose Kiaaccess MCP when
- You need dedicated capabilities in the Travel & Transportation domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: other.
- You have the keys it needs:
KIA_USERNAME, KIA_PASSWORD. - You want tools like
kia_healthcheck, kia_session_status, kia_start_login.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Travel & Transportation | Travel & Transportation |
| Quality signal | 72/100 · Great | 63/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | API key required | other |
| Pricing | Free | Free |
| Required env vars | LETSFG_BEARER_TOKENLETSFG_API_KEY | KIA_USERNAMEKIA_PASSWORD |
| Verified owner | Community listing | Community listing |
| GitHub stars | 2,175 | 0 |
| Directory activity | 8 views 1 installs 0 upvotes | 1 views 0 installs 0 upvotes |
| Tools | 14 | 16 |
| Full listing | View BoostedTravel | View Kiaaccess MCP |
Tools & capabilities
BoostedTravel 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.unlock_flight_offer[Developer API only] Confirm live price with the airline and reserve the offer for 30 minutes. NOT part of the agent flow and NOT needed before book_flight. It requires LETSFG_API_KEY (the paid, prepaid Developer API) and refuses to run on a Bearer token, because the PFS unlock endpoint does not exist — calling it that way used to 404. If you authenticated with `letsfg auth`, go straight from search_flights to book_flight. Requires a Developer API key. Legacy path — not idempotent.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.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 payment method on file — the SAME card that authorises flight booking. That applies to search too, not just booking, because a search opens a real session at the supplier. Only free-cancellation, pay-later rates are returned, so everything you see can actually be booked on these terms. The result set is smaller than a metasearch and that is deliberate. `price` is what the guest pays. Keep `session_id` and the chosen offer's `combination_id_v2` — together they identify that exact rate, and book_hotel needs both. Takes up to a few minutes.book_hotelBook one hotel rate. Charges 5% of the price to the card on file immediately as a NON-REFUNDABLE reservation fee; the balance is paid directly to the supplier through the pay link we return, by balance_due_by (the supplier's own auto-cancellation date). Returns a booking_job_id, NOT the booking — a booking takes minutes. Poll get_hotel_booking until status is succeeded or failed. The fee is charged BEFORE the room is committed, so a declined card costs nothing: no reservation exists and nothing is charged. Send expected_price and expected_balance back exactly as search returned them. NOT idempotent — calling twice for the same rate books the room twice and charges two fees.get_hotel_bookingCollect the result of a booking started with book_hotel. Poll every ~20s. status is in_progress, succeeded or failed. On success you get confirmation, reservation_fee_charged, pay_link, balance_due, balance_due_by and the full cancellation ladder. Read-only and safe to repeat.cancel_hotel_bookingRelease a hotel reservation. Free until balance_due_by; after that the hotel's own ladder applies and can reach 100%. The ladder is in the booking terms, so check the cost first. The 5% reservation fee is NOT refunded. 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 setup_payment for this.setup_payment[Developer API only — you almost certainly want `authenticate` instead] Attaches a card to a PAID prepaid Developer API account. Refuses to run unless LETSFG_API_KEY is set, because agents kept calling this and creating billing accounts they did not need.- +2 more on the listing page
Kiaaccess MCP tools 16
kia_healthcheckResolves the credential the way real tools do, then makes one authenticated request to Kia Connect. Reports which source supplied the credential, whether Kia Connect accepted it, the round-trip time, and a plain-English hint distinguishing 'no credential' from 'credential rejected' from 'a Kia Connect-side problem'. Read-only; never returns the credential itself. Call this when a real tool fails and you want to know which hop broke.kia_session_statusWhether this server is configured and logged in to Kia: are credentials present, has the one-time MFA bootstrap been completed on this device, and which vehicle commands are registered (KIA_WRITE_MODE). Makes NO network call and returns no secret — the account email is masked, the device id is truncated, and neither the session id nor the remember-me token is ever included. Start here when a Kia tool reports it is not configured.kia_start_loginStep 1 of the ONE-TIME Kia MFA bootstrap (prof/authUser): send the configured credentials and get back the `otpKey` and `xid` the next two steps need. Only needed when kia_session_status reports hasSession:false — once the bootstrap is done the stored remember-me token refreshes sessions silently forever. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call makes NO network call and returns a preview plus a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). The gate is real: Kia counts failed logins and eventually enforces reCAPTCHA, which breaks server-side login for this account PERMANENTLY — so a rejection is never retried, and a wrong password must be fixed in the environment rather than guessed at.kia_send_otpStep 2 of the Kia MFA bootstrap (cmm/sendOTP): deliver a one-time passcode to the account by SMS or email. Takes the `otpKey` and `xid` from kia_start_login — it cannot run without them, which is why it has no separate confirmation gate. Ask the user which channel they want (kia_start_login reports the masked destinations Kia has on file). The passcode expires in about two minutes; `expiresAt` reports when.kia_verify_otpStep 3 of the Kia MFA bootstrap (cmm/verifyOTP): exchange the passcode for a session. The resulting remember-me token is stored locally and is NOT returned — from here on every Kia tool refreshes its own session silently and MFA is never needed again on this device. Takes the `otpKey` and `xid` from kia_start_login plus the code the user received.kia_forget_sessionDiscard the locally stored Kia session (the remember-me token), so the next Kia call needs the one-time MFA bootstrap again. This is the recovery path when the stored token no longer works — Kia revoked it, the password changed, or the account moved to another device — and the only alternative is deleting the session file by hand. It makes NO network call: Kia is not told anything, only this machine forgets. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call makes NO network call and returns a preview plus a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). Nothing is deleted until it is confirmed.kia_list_vehiclesList the vehicles enrolled on this Kia Owners account (ownr/gvl). Returns each vehicleKey — the id every other Kia tool takes — plus nickname, model year/name/trim, mileage, fuel type and telematics unit. VINs are masked to their last 6 characters.kia_vehicle_statusRead the vehicle's CACHED status (cmm/gvi): door lock, ignition, and the remote-climate block. Fast, but it reports whatever the telematics unit last uploaded — use kia_refresh_status first when freshness matters. Requested with airTempRange/seatHeatCoolOption = "1" so the nested `climate` object is present; when it is still absent the result says so rather than reporting climate as off. Note `ign3` (not `engine`) is the ignition on an EV, and `syncDate` advances on every read, so it never proves anything changed. Per-seat heat/vent state is reported under `climate.seats` as the RAW numbers Kia sends: the `heatVentType`/`heatVentLevel` encoding is UNVERIFIED, so do not tell the user a seat is heating, ventilating or off based on them. An absent seat block means this read carried no seat data — it does NOT mean the car lacks heated seats, which this server cannot currently determine. Pass include_raw for the untrimmed status block (battery/EV detail, doors, tyres, …).kia_refresh_statusAsk the car for a fresh reading (rems/rvs, requestType 0). This WAKES THE TELEMATICS UNIT, so it is much slower than kia_vehicle_status and draws a little power — prefer the cached read unless staleness matters. Kia only acknowledges the request; it does not return the new data and gives no completion signal, so read kia_vehicle_status afterwards to see the refreshed values.kia_vehicle_locationThe vehicle's last known location, from the `location` block of the cached cmm/gvi read. This is where the telematics unit last reported being, not a live GPS fix — run kia_refresh_status first for a recent one. Latitude/longitude and a map link are derived when the block carries `coord.lat`/`coord.lon`; otherwise the raw block is returned as-is (its exact field names are not verified).kia_start_climateStart remote climate control / preconditioning (Kia `rems/start`, live-verified). Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call makes NO network call and returns a preview plus a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). Once confirmed it sends the command and re-reads cmm/gvi until the NESTED `climate.airCtrl` reads true (there is no flat `airCtrlOn` field). On an EV `engine` stays false while climate runs — `ign3` is the ignition proxy and is reported alongside. `commandAccepted` (Kia took the request) and `stateConfirmed` (the car actually reads running) are separate; state changes were observed to take 30–60s. TEMPERATURE IS BEST-EFFORT AND UNCONFIRMED: per docs/KIA-API.md a start requesting 70°F still read back 72°F, so the car may report its own last-set target rather than the requested one — do not promise the user a specific cabin temperature. Seat and steering-wheel/rear-window heating are not sent at all: the request body deliberately omits `heatVentSeat` (Kia validates seat capability per car) and leaves every `heatingAccessory` field at 0.kia_stop_climateStop remote climate control (Kia `rems/stop`, live-verified). Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call makes NO network call and returns a preview plus a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). Once confirmed it sends the command and re-reads cmm/gvi until the NESTED `climate.airCtrl` reads false (there is no flat `airCtrlOn` field); `ign3` — the EV ignition proxy — is reported alongside. `commandAccepted` (Kia took the request) and `stateConfirmed` (the car actually reads stopped) are separate. State changes were observed to take 30–60s.- +4 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.
BoostedTravel
{
"mcpServers": {
"boostedtravel": {
"command": "npx",
"args": [
"-y",
"letsfg-mcp"
],
"env": {
"LETSFG_BEARER_TOKEN": "YOUR_LETSFG_BEARER_TOKEN_HERE",
"LETSFG_API_KEY": "YOUR_LETSFG_API_KEY_HERE"
}
}
}
}
Kiaaccess MCP
{
"mcpServers": {
"kiaaccess-mcp": {
"command": "npx",
"args": [
"-y",
"kiaaccess-mcp"
],
"env": {
"KIA_USERNAME": "YOUR_KIA_USERNAME_HERE",
"KIA_PASSWORD": "YOUR_KIA_PASSWORD_HERE"
}
}
}
}
Frequently asked questions
BoostedTravel is categorized under Travel & Transportation and uses a local stdio subprocess. Kiaaccess MCP belongs to Travel & Transportation and uses a local stdio subprocess. Pick BoostedTravel for travel & transportation work and Kiaaccess 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.
BoostedTravel is listed as free. Auth: api key required. Kiaaccess MCP is listed as free. Auth: other. 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 boostedtravel and kiaaccess-mcp as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, BoostedTravel has a quality signal of 72/100 (Great) with 8 views, 1 installs and 2,175 GitHub stars. Kiaaccess MCP has 63/100 (Good) with 1 views, 0 installs and 0 GitHub stars.