BoostedTravel vs Weathersight

A side-by-side look at the BoostedTravel and Weathersight MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.

BoostedTravelTravel & Transportation · Local subprocess (stdio)Flight search & booking for AI agents. 400+ airlines, $20-50 cheaper than OTAs.72GreatAuth: api key required

WeathersightEnvironment & NatureHistorical weather and climate: 100+ years of station data, normals, extremes, and trends.51GoodAuth: oauth 2.0

Verdict: choose BoostedTravel for travel & transportation work as a local process; choose Weathersight for environment & nature. 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.

Explore BoostedTravel

Choose Weathersight when

You need dedicated capabilities in the Environment & Nature domain.
Its auth model fits you: OAuth 2.0.
You want tools like anom, anomalies, bestplace.

Explore Weathersight

Feature & specification comparison

Rows where the two servers differ are marked.

Spec	BoostedTravel	Weathersight
Category	Travel & Transportation	Environment & Nature
Quality signal	72/100 · Great	51/100 · Good
Install command	Confirmed	Not confirmed yet
Transport	Local subprocess (stdio)	—
Auth	API key required	OAuth 2.0
Pricing	Free	Freemium
Required env vars	`LETSFG_BEARER_TOKENLETSFG_API_KEY`	None listed
Verified owner	Community listing	Community listing
GitHub stars	2,186	0
Directory activity	9 views 1 installs 0 upvotes	0 views 0 installs 0 upvotes
Tools	14	25
Full listing	View BoostedTravel	View Weathersight

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

Weathersight tools 25

anomReturns observations with 1991–2020 baseline comparisons at daily, weekly, or monthly granularity for a location and period. When to use: Graph or tabulate recent anomalies at a location for a specific period — e.g. 'how did last month compare to normal?' Date format: YYYYMMDD for ymd; use groupby (day/week/month) to control granularity. For 'last week' use YYYYMMDD of 7 days ago. For 'last month' use YYYYMM of prior month. Performance: Computed on demand; moderate speed. Prerequisites: Use /location to obtain a locid first. Investigate: Use after /anomalies or /breaking. Identifies a city of interest; provides per-day/week detail for drill-down. Combine groupby=DAY/FULL_DAY with a recent date range for 'recent days with departure from normal' queries. Augment: Provides the per-period anomaly series for prose ('temperatures were above normal for 12 of the past 14 days'). Returns: loc, ts, vals, N, vals_ts, baseline.
anomaliesReturns precomputed anomalous observations for locations in a given time period and scope. When to use: Survey anomalous weather at regional or global scale quickly without specifying individual cities. Date format: YYYY[MM[DD]]: YYYY for annual anomalies (scope=year), YYYYMM for monthly (scope=month), YYYYMMDD for weekly or daily (scope=week/day). Performance: Fast — retrieves precomputed data. Prerequisites: None; global or country-filtered. Use /countries for country IDs. Investigate: Good early call to identify which locations experienced anomalies before drilling into specifics with /anom or /dailycomp. Augment: Use for a first-pass global scan to identify story-worthy anomalies before fetching per-location detail. Returns: anomalies, anomaly.locid, anomaly.lat, anomaly.long, anomaly.obs_start, anomaly.obs_end, anomaly.obs_dur, anomaly.base_start, anomaly.base_end, anomaly.base_dur, anomaly.obs_period, anomaly.base_period, anomaly.outliers, outlier.obs_metric, outlier.percentile, outlier.obs_N, outlier.obs_X, outlier.base_N, outlier.base_X, outlier.obs_val, outlier.base_val, outlier.base_mean, outlier.base_stddev, outlier.min, outlier.max, outlier.max_key, outlier.min_key, outlier.obs_min_key, outlier.obs_max_key.
bestplaceGiven a single week, month, or day, ranks locations whose weather best matches a set of criteria (most optional criteria met first; all MUST criteria satisfied by every result). Filter by lat/lon+radius or countries. When to use: Answer 'where has the best weather for week/month/day X?' Date format: scope=day + time=YYYYMMDD (forecast); scope=week + time=MMDD; scope=month + time=MM. Defaults: week of today+14, month today+1, day today+1. Performance: Filter by area/countries to keep fast. Prerequisites: None; supply lat/lon+radius_km or a country list. Investigate: Rank places for a given time window. scope=day uses forecasts. Augment: Find the best destinations for a target week/month. Notes: Every criterion metric name is literal and fully qualified: the 'avg:' prefix, then the metric base (observation metrics keep their 'obs.' segment), then the attribute — e.g. avg:max_t.p50, avg:obs.rain.sum, avg:obs.is_rain.count. Dropping 'avg:' or 'obs.' is an error; the criteria parameter below lists every valid name. scope=day queries forecasts; week/month query the 1996-2025 historical baseline. Returns: scope, time, baseline, results, locid, location, criteria_met, criteria_met_count, record.
besttimeGiven a location, ranks the weeks or months whose historical climatology best matches a set of weather criteria (most optional criteria met first; all MUST criteria satisfied by every result). When to use: Answer 'when is the best time to visit X for weather like Y?' Choose when_type=week or month over the 1996-2025 baseline. Date format: when_type: week|month|day. Historical basis only for week/month. Performance: Sub-second per location. Prerequisites: Use /location to obtain a locid first. Investigate: Rank a location's calendar by weather suitability. For a specific upcoming day's forecast, use /api/anom with period_type=FUTURE_DAY. Augment: Find the typical best window for an activity at a place. Notes: Every criterion metric name is literal and fully qualified: the 'avg:' prefix, then the metric base (observation metrics keep their 'obs.' segment), then the attribute — e.g. avg:max_t.p50, avg:obs.rain.sum, avg:obs.is_rain.count. Dropping 'avg:' or 'obs.' is an error; the criteria parameter below lists every valid name. For daily forecasts use /api/anom (period_type=FUTURE_DAY). Weekly/monthly forecasts are planned. Returns: location, baseline, when_type, results, time, criteria_met, criteria_met_count, record.
breakingReturns anomalous weather conditions (breaking news) across the world or specified countries in the very recent past (observations) or immediate future (forecast). When to use: First call when looking for current or upcoming notable weather events globally or by country. Date format: No date params — always returns the most recent ~3 days of observations (breaking_type=obs) or next 7 days of forecast (breaking_type=forecast). Performance: Fast — retrieves precomputed anomaly snapshots. Prerequisites: Use /countries to get country IDs for filtering. Investigate: Start here for any 'what's happening right now?' or 'what's forecast this week?' query; follow up with /anom or /dailycomp for per-location detail. Augment: Primary source for identifying breaking weather news stories globally; use ctryid to narrow scope by country. Returns: anomalies, anomaly.locid, anomaly.name, anomaly.city, anomaly.country, anomaly.lat, anomaly.lon, anomaly.geohash, anomaly.elevation, anomaly.obs_start, anomaly.obs_end, anomaly.obs_dur, anomaly.pt, anomaly.anomalies, outlier.obsm, outlier.comps, comp.obsm_f, comp.oq, comp.bq, comp.scope, comp.val, comp.bval, comp.min, comp.max, comp.med, comp.mean, comp.std, comp.min_dt, comp.max_dt, comp.intensity, comp.intensity_f, comp.rp, comp.summary, comp.period, comp.base_N, comp.N, comp.ut, comp.start, comp.end.
climatecompsReturns monthly distributions of selected metrics for locations compared against a baseline period. When to use: Compute normalized and absolute deviations from a baseline, inter-annual and intra-annual variations within months and seasons. Check base_N and obs_N to assess data completeness. Date format: obs_years as YYYY or YYYY-YYYY range; months as MM or MM-MM (e.g. '06', '06-08', 'All' for annual). Performance: Bulk query — can be slow for global or large-area queries. Filter with locids, lat_lon/radius_km, or countries. Prerequisites: Use /location to obtain locids first for point queries. Investigate: Use to compare a recent season or year against the long-term baseline across many locations simultaneously. Combine with /climatetrends for trend context. Augment: Identifies which locations had the most anomalous season compared to their historical distribution. Notes: Metric format: 'max_t' = distribution of daily Maximum Temperature over the period; 'max_t.means' = distribution of annual means of max_t (1 value per year); 'rain_sum' (accumulations) and 'obs.is_thunderstorm' (counts) follow the same pattern. Returns: results, comp.locid, comp.geohash, comp.lat, comp.lon, comp.elev, comp.area, comp.country, comp.src_type, comp.metric, comp.obs_years, comp.base_years, comp.month, comp.obs_N, comp.base_N, comp.obs, comp.base, comp.obs.{q} / comp.base.{q}.
climatetrendsReturns monthly timeseries of selected climate trend metrics for one or more locations, suitable for long-term trend analysis. When to use: Retrieve long-term monthly timeseries for statistical trend analysis across any number of locations including globally. Use num_years and avg_N to filter sparse records. Date format: years as YYYY- range (e.g. '1975-' for 1975 to present); months as MM or MM-MM range (e.g. '06' for June, '06-08' for June–August, 'All' for annual). Performance: Bulk query — can be slow for global or many-location queries. Filter with locids, lat_lon/radius_km, or countries to improve speed. Prerequisites: Use /location to obtain locids first for point queries. Investigate: Use for global or regional trend analysis. Metric name format: 'agg_func:metric_id.attribute' (e.g. 'avg:max_t.p50'). Check num_years to confirm data completeness before citing a trend. Augment: Backs trend claims with long-term data across many locations (e.g. 'temperatures rising across Southeast Asia'). Notes: Example metrics: avg:max_t.p50, avg:obs.temp.mean, sum:obs.is_rain.count. See /api/metrics for full list. Returns: results, trend.locid, trend.geohash, trend.lat, trend.lon, trend.elev, trend.area, trend.country, trend.src_type, trend.metric, trend.years, trend.month, trend.num_years, trend.avg_N, trend.mvals, trend.mvals.xvals, trend.mvals.yvals_by_metric.
compareCompares a location's observed weather period against the corresponding periods in a historical baseline distribution. When to use: Quantify how extreme a specific period was across all metrics at once — e.g. how anomalous was March 2025 at New York vs the 1991–2020 baseline. Date format: YYYY[MM[DD]]: YYYYMMDD for a specific day or short window (period_type DAY/WEEK), YYYYMM for a month (period_type MONTH), YYYY for an annual comparison (period_type YEAR). Performance: Computed on demand; fast for short periods. Prerequisites: Use /location to obtain a locid first. Investigate: Best for 'how unusual was [period] at [location]?' — returns percentile and z-score across all metrics simultaneously. Set baseline_offset=1 for the standard 1991–2020 baseline. Augment: Provides the precise statistical framing ('the hottest March in 30 years') before describing the anomaly in prose. Returns: comparisons, comparison.locid, comparison.lat, comparison.long, comparison.obs_start, comparison.obs_end, comparison.obs_dur, comparison.base_start, comparison.base_end, comparison.base_dur, comparison.obs_period, comparison.base_period, comparison.outliers, outlier.obs_metric, outlier.percentile, outlier.obs_N, outlier.obs_X, outlier.base_N, outlier.base_X, outlier.obs_val, outlier.base_val, outlier.base_mean, outlier.base_stddev, outlier.min, outlier.max, outlier.max_key, outlier.min_key, outlier.obs_min_key, outlier.obs_max_key.
countriesReturns countries with their canonical country IDs used in all other API calls. When to use: Resolve country names to canonical IDs, or obtain the full list of supported countries. This list rarely changes. Performance: Fast — static data; safe to cache across calls. Prerequisites: None. Investigate: Call once if country-level filtering is needed; cache the result for the session. Augment: Fetch country IDs before making country-filtered calls to /anomalies or /breaking. Returns: countries, country.ctryid, country.name, country.regions.
dailycompReturns per-day observed values with percentiles and z-scores vs a sliding N-day window over a historical baseline. When to use: Graph heatwaves, cold spells, and other streaks by showing daily departures from normal. Also compare two separate periods or locations using z-scores or percentiles for normalized severity. Date format: YYYYMMDD for ymd_start and ymd_end. Keep ranges ≤30 days for fast response; up to 90 days is feasible. Performance: Computed on demand; slower for long date ranges. Prerequisites: Use /location to obtain a locid first. Investigate: Best for detailed day-by-day anomaly investigation once approximate dates and location are known. Use separate calls for two periods to compare heatwave severity via z-score. Do NOT use for ranking top-N events across years — call /events with criteria for that and post-process the response. Augment: Provides the daily series needed to describe the arc of a heatwave or cold snap in a news narrative. Returns: locid, lat, lon, dates, num_years, avg_coverage, metrics, metrics.{key}.values, metrics.{key}.pcts, metrics.{key}.sigmas, metrics.{key}.p1 … p99, metrics.{key}.bmin / bmax, metrics.{key}.mean, metrics.{key}.stddev, metrics.{key}.coverage.
dailycountbylocHow often a compound daily weather condition happens, per location: for every location in an area, the average number of days per year that met all the criteria, with the count, the days that had data, and the percentage. When to use: Map where a condition is common or rare, e.g. 'where are summer days between 20 and 30 C most frequent' or 'where did heatwave nights occur in the last five summers'. Date format: Either ymd_start and ymd_end (YYYYMMDD, at most 31 days) or year_start, year_end with optional mm_dd_start and mm_dd_end for a season across years (at most 5 years). Defaults to the last 30 days. Performance: Full counts need a geo scope (ctryid, latlon, or a bbox of at most continent size) or a date range of at most 30 days. Anything wider is sampled automatically to about 200 locations (see sample), because an open-ended multi-year count takes over a minute; pass sample=0 to be refused instead. With a geo scope, year windows up to 5 years run fast. Prerequisites: None; without a geo scope, windows over 30 days are sampled. Investigate: Use min_count_pct to keep only locations where the condition is frequent, or min_count 0 with max_count to find where it is rare or never happens. Augment: Support statements about how common a condition is across a region with avg_count and count_pct. Notes: avg_count is matched days divided by years in the window; count_pct divides by the days that actually had data, so station gaps do not read as absence. Returns: criteria_desc, time, total_days_per_year, num_years, total_days_found, count, truncated, results, locid, lat, lon, city_name, country, avg_count, days_with_data, count_pct, sample, note, error.
dailycountbyyearFor one location, the number of days per year that met all the criteria within a month-day window, for every year with data, plus a trend line (days per decade) with R squared and p-value. When to use: Answer 'is this condition becoming more frequent here?', e.g. hot summer days or frost nights per year over decades. Date format: The window is mm_dd_start and mm_dd_end (MMDD), or the month-days of ymd_start and ymd_end; years are not a filter, every year with data is returned. A window crossing the year end (1201 to 0228) belongs to the year it starts in. Defaults to the month-days of the last 30 days. Performance: Fast: filtered to one location in the index. Prerequisites: locid from /api/location (ICAO and WMO ids also resolve). Investigate: Compare the trend across nearby locations, or across absolute and percentile criteria for the same condition. Augment: Back 'more frequent than it used to be' claims with slope_per_decade and its p_value. Notes: Years with under 80% of the window covered are listed (in_trend false) but excluded from the trend. Returns: locid, location, criteria_desc, mm_dd_start, mm_dd_end, total_days_per_year, years, counts, days_with_data, in_trend, trend, note, error.
+13 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 (Claude Desktop / Cursor)

{
  "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"
      }
    }
  }
}

Weathersight

No confirmed install command for Weathersight yet — follow the setup steps linked from its listing page rather than a guessed package name.

Frequently asked questions

BoostedTravel is categorized under Travel & Transportation and uses a local stdio subprocess. Weathersight belongs to Environment & Nature and uses an install path we have not confirmed yet. Pick BoostedTravel for travel & transportation work and Weathersight for environment & nature.

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. Weathersight has no confirmed install command yet — follow its own setup instructions.

BoostedTravel is listed as free. Auth: api key required. Weathersight is listed as freemium — a free tier with paid plans. Auth: oauth 2.0. 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 weathersight 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 9 views, 1 installs and 2,186 GitHub stars. Weathersight has 51/100 (Good) with 0 views, 0 installs and 0 GitHub stars.

Choose BoostedTravel when

Choose Weathersight when

BoostedTravel tools 14

Weathersight tools 25

BoostedTravel

Weathersight

Frequently asked questions

What is the main functional difference between BoostedTravel and Weathersight?

How do I install BoostedTravel or Weathersight in Claude Desktop, Cursor, or Windsurf?

Are BoostedTravel and Weathersight free to use, or do they require API keys?

Can I run both BoostedTravel and Weathersight at the same time in my AI client?

Which MCP server has higher directory engagement and quality ratings?

Popular comparisons with BoostedTravel

Popular comparisons with Weathersight