Pifini MCP vs BoostedTravel — MCP Server Comparison | AllMCPs
Side-by-Side Model Context Protocol Comparison
Pifini MCP vs BoostedTravel
In-depth architectural comparison of the Pifini MCP and BoostedTravel MCP servers. Compare execution transports, security boundaries, tool capabilities, quality scores, and ready-to-paste client installation snippets for Claude, Cursor, Windsurf, and VS Code.
At a Glance & Executive Verdict
Pifini MCP
Travel & Transportation · Local stdio
Quality: 48/100 (Fair) | Auth: No auth required
BoostedTravel
Travel & Transportation · Local stdio
Quality: 71/100 (Great) | Auth: API Key required
Verdict Summary: Choose Pifini MCP if you need specialized Travel & Transportation tools running via a local process. Choose BoostedTravel if your workspace requires Travel & Transportation integration with local subprocess execution. Both servers can be configured concurrently in your client's mcpServers manifest.
Which MCP Server Should You Choose?
Choose Pifini MCP when:
You need dedicated capabilities in the Travel & Transportation domain.
You prefer local stdio subprocess transport architecture.
Your security boundary fits: No auth required (Free / Open Source).
Real events, reviewed places, and ticket checkout across the Caribbean & Latin America. Search festivals/carnivals and reviewed restaurants/venues/professionals, read verified reviews, and generate a Stripe-hosted checkout link — humans pay, agents never touch card details. Hosted Streamable HTTP endpoint; read tools need no auth. Listed in the official MCP Registry as net.pifini/pifini.
Flight search & booking for AI agents. 400+ airlines, $20-50 cheaper than OTAs.
Category & Scope
Tools & Capabilities Breakdown
Pifini MCP Tools (0)
No explicit tool names declared in metadata yet. Check project README on main listing page.
BoostedTravel Tools (14)
search_flights
Search 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_location
Ready-to-Paste Client Configurations
Paste either (or both) of these JSON server blocks into your client config file (e.g. claude_desktop_config.json or ~/.cursor/mcp.json).
Pifini MCP is categorized under Travel & Transportation and uses a local stdio subprocess. In contrast, BoostedTravel belongs to Travel & Transportation using local stdio subprocess. Select Pifini MCP when you need capabilities focused on travel & transportation and BoostedTravel when you require tools for travel & transportation.
Convert 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_flight
Book 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_booking
Poll 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_city
Convert 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_hotels
Search 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_hotel
Book 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_booking
Collect 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_booking
Release 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.
authenticate
Explain 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.