Weathersight vs Firecrawl MCP Server
A side-by-side look at the Weathersight and Firecrawl MCP Server MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Weathersight for environment & nature work; choose Firecrawl MCP Server for search & data extraction as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
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.
Choose Firecrawl MCP Server when
- You need dedicated capabilities in the Search & Data Extraction domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: API key required.
- You have the keys it needs:
FIRECRAWL_API_KEY, HTTP_STREAMABLE_SERVER. - You want tools like
firecrawl_scrape, firecrawl_map, firecrawl_search.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Environment & Nature | Search & Data Extraction |
| Quality signal | 51/100 · Good | 90/100 · Excellent |
| Install command | Not confirmed yet | Confirmed |
| Transport | — | Local subprocess (stdio) |
| Auth | OAuth 2.0 | API key required |
| Pricing | Freemium | Freemium |
| Required env vars | None listed | FIRECRAWL_API_KEYHTTP_STREAMABLE_SERVER |
| Verified owner | Community listing | Verified |
| GitHub stars | 0 | 7,673 |
| Directory activity | 0 views 0 installs 0 upvotes | 14 views 0 installs 0 upvotes |
| Tools | 25 | 25 |
| Full listing | View Weathersight | View Firecrawl MCP Server |
Tools & capabilities
Weathersight tools 25
anomReturns observations with 1991–2020 baseline comparisons at daily, weekly, or monthly granularity for a location and period. <br><b>When to use:</b> Graph or tabulate recent anomalies at a location for a specific period — e.g. 'how did last month compare to normal?' <br><b>Date format:</b> 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. <br><b>Performance:</b> Computed on demand; moderate speed. <br><b>Prerequisites:</b> Use /location to obtain a locid first. <br><b>Investigate:</b> 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. <br><b>Augment:</b> 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. <br><b>When to use:</b> Survey anomalous weather at regional or global scale quickly without specifying individual cities. <br><b>Date format:</b> YYYY[MM[DD]]: YYYY for annual anomalies (scope=year), YYYYMM for monthly (scope=month), YYYYMMDD for weekly or daily (scope=week/day). <br><b>Performance:</b> Fast — retrieves precomputed data. <br><b>Prerequisites:</b> None; global or country-filtered. Use /countries for country IDs. <br><b>Investigate:</b> Good early call to identify which locations experienced anomalies before drilling into specifics with /anom or /dailycomp. <br><b>Augment:</b> 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. <br><b>When to use:</b> Answer 'where has the best weather for week/month/day X?' <br><b>Date format:</b> scope=day + time=YYYYMMDD (forecast); scope=week + time=MMDD; scope=month + time=MM. Defaults: week of today+14, month today+1, day today+1. <br><b>Performance:</b> Filter by area/countries to keep fast. <br><b>Prerequisites:</b> None; supply lat/lon+radius_km or a country list. <br><b>Investigate:</b> Rank places for a given time window. scope=day uses forecasts. <br><b>Augment:</b> Find the best destinations for a target week/month. <br><b>Notes:</b> 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). <br><b>When to use:</b> Answer 'when is the best time to visit X for weather like Y?' Choose when_type=week or month over the 1996-2025 baseline. <br><b>Date format:</b> when_type: week|month|day. Historical basis only for week/month. <br><b>Performance:</b> Sub-second per location. <br><b>Prerequisites:</b> Use /location to obtain a locid first. <br><b>Investigate:</b> Rank a location's calendar by weather suitability. For a specific upcoming day's forecast, use /api/anom with period_type=FUTURE_DAY. <br><b>Augment:</b> Find the typical best window for an activity at a place. <br><b>Notes:</b> 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). <br><b>When to use:</b> First call when looking for current or upcoming notable weather events globally or by country. <br><b>Date format:</b> No date params — always returns the most recent ~3 days of observations (breaking_type=obs) or next 7 days of forecast (breaking_type=forecast). <br><b>Performance:</b> Fast — retrieves precomputed anomaly snapshots. <br><b>Prerequisites:</b> Use /countries to get country IDs for filtering. <br><b>Investigate:</b> 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. <br><b>Augment:</b> 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. <br><b>When to use:</b> 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. <br><b>Date format:</b> obs_years as YYYY or YYYY-YYYY range; months as MM or MM-MM (e.g. '06', '06-08', 'All' for annual). <br><b>Performance:</b> Bulk query — can be slow for global or large-area queries. Filter with locids, lat_lon/radius_km, or countries. <br><b>Prerequisites:</b> Use /location to obtain locids first for point queries. <br><b>Investigate:</b> Use to compare a recent season or year against the long-term baseline across many locations simultaneously. Combine with /climatetrends for trend context. <br><b>Augment:</b> Identifies which locations had the most anomalous season compared to their historical distribution. <br><b>Notes:</b> 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. <br><b>When to use:</b> 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. <br><b>Date format:</b> 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). <br><b>Performance:</b> Bulk query — can be slow for global or many-location queries. Filter with locids, lat_lon/radius_km, or countries to improve speed. <br><b>Prerequisites:</b> Use /location to obtain locids first for point queries. <br><b>Investigate:</b> 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. <br><b>Augment:</b> Backs trend claims with long-term data across many locations (e.g. 'temperatures rising across Southeast Asia'). <br><b>Notes:</b> 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. <br><b>When to use:</b> 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. <br><b>Date format:</b> 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). <br><b>Performance:</b> Computed on demand; fast for short periods. <br><b>Prerequisites:</b> Use /location to obtain a locid first. <br><b>Investigate:</b> 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. <br><b>Augment:</b> 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. <br><b>When to use:</b> Resolve country names to canonical IDs, or obtain the full list of supported countries. This list rarely changes. <br><b>Performance:</b> Fast — static data; safe to cache across calls. <br><b>Prerequisites:</b> None. <br><b>Investigate:</b> Call once if country-level filtering is needed; cache the result for the session. <br><b>Augment:</b> 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. <br><b>When to use:</b> 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. <br><b>Date format:</b> YYYYMMDD for ymd_start and ymd_end. Keep ranges ≤30 days for fast response; up to 90 days is feasible. <br><b>Performance:</b> Computed on demand; slower for long date ranges. <br><b>Prerequisites:</b> Use /location to obtain a locid first. <br><b>Investigate:</b> 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. <br><b>Augment:</b> 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. <br><b>When to use:</b> 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'. <br><b>Date format:</b> 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. <br><b>Performance:</b> 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. <br><b>Prerequisites:</b> None; without a geo scope, windows over 30 days are sampled. <br><b>Investigate:</b> 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. <br><b>Augment:</b> Support statements about how common a condition is across a region with avg_count and count_pct. <br><b>Notes:</b> 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. <br><b>When to use:</b> Answer 'is this condition becoming more frequent here?', e.g. hot summer days or frost nights per year over decades. <br><b>Date format:</b> 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. <br><b>Performance:</b> Fast: filtered to one location in the index. <br><b>Prerequisites:</b> locid from /api/location (ICAO and WMO ids also resolve). <br><b>Investigate:</b> Compare the trend across nearby locations, or across absolute and percentile criteria for the same condition. <br><b>Augment:</b> Back 'more frequent than it used to be' claims with slope_per_decade and its p_value. <br><b>Notes:</b> 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
Firecrawl MCP Server tools 25
firecrawl_scrapeRetrieve and extract content from one supplied URL through Firecrawl. Use this when the request identifies a page and needs its content or defined fields. It can return markdown, HTML, links, screenshots, branding data, a targeted answer, or JSON matching a supplied schema; JSON is useful when the requested result has defined fields, while markdown preserves readable page content. This tool operates on a known page. For a set of pages use `firecrawl_crawl`, and to discover page URLs use `firecrawl_map` or `firecrawl_search`. Options include JavaScript render delay, cache age, main-content filtering, PII redaction, and lockdown cache-only retrieval. Browser actions may change the live page when interactive actions are enabled. Firecrawl may reuse recently indexed content instead of refetching the page, and the reuse window varies by domain. Set `maxAge: 0` to force a live fetch, or a smaller `maxAge` to bound how stale reused content may be. A successful response does not by itself confirm that the state it describes is still current. Returns the selected content formats and page metadata.firecrawl_mapEnumerate URLs indexed under one website through Firecrawl without fetching each page's content. Use this when the request asks for a site's URL inventory, when several relevant pages must be located, or when the desired page URL is unknown. An optional `search` term narrows the URL list, while sitemap, subdomain, query-parameter, and result-limit options control coverage. Returns matching URLs rather than page bodies. Retrieve one page with `firecrawl_scrape`; collect content across multiple pages with `firecrawl_crawl`.firecrawl_searchSearch web, news, or image sources and return ranked results. Operators include quoted phrases, `-term`, `site:host`, `inurl:term`, `intitle:term`, and `related:host`; the set is non-exhaustive. `includeDomains` and `excludeDomains` are mutually exclusive hostname filters; categories limit results to GitHub, research, PDF, or developer sources. For a programming question, add `categories: ["developer"]`. It searches an index of GitHub issues, merged pull requests, repository READMEs, and curated documentation sites, and returns the hits in `data.developer` beside the web results. `categories: ["research"]` restricts these web results to research-affiliated websites and returns page snippets. The `firecrawl_research_*` tools are a separate surface that searches paper abstracts and full text across biomedical (PubMed, bioRxiv, medRxiv) and arXiv literature. `scrapeOptions` can attach extracted page content; pages fetched this way use a fixed reuse window and ignore `maxAge`, so use `firecrawl_scrape` when a live fetch is required. Returns source-type result groups and usage metadata. Authenticated responses can include an `id` for optional search feedback.firecrawl_crawlStart a multi-page crawl at a website URL, poll it to a terminal state, and return the final status and collected data. Scope can be bounded with include/exclude paths, depth, page limit, subdomain/external-link controls, sitemap handling, delay, and scrape options. Crawl results can be large; use conservative limits when full-site coverage is unnecessary. Webhooks and interactive scrape actions are unavailable in safe mode. Returns the crawl ID, status, and page data.firecrawl_check_crawl_statusRetrieve the current status, progress, and available results for an existing crawl ID. This only reads Firecrawl job state and does not start or modify the crawl.firecrawl_extractDeprecated compatibility entry point. Use firecrawl_scrape once per known URL with formats: ["json"] and jsonOptions containing the prompt and schema. Use firecrawl_search or firecrawl_agent before Scrape when URLs are not known.firecrawl_agentStart an asynchronous web research job from a prompt, optional seed URLs, and an optional JSON schema. Use this for a requested synthesis across multiple sources when the task can wait for asynchronous completion. The agent can search, navigate, read pages, and assemble a structured result. This call returns only a job ID, not the research result. Read the job with `firecrawl_agent_status` until it reaches `completed` or `failed`; research commonly takes several minutes. If the job cannot finish within the task's available time, `firecrawl_search` and `firecrawl_scrape` can gather evidence synchronously.firecrawl_agent_statusRetrieve progress or final results for a `firecrawl_agent` job ID. A `processing` response is non-terminal and does not contain the final research result. Check again after 15–30 seconds until the status is `completed` or `failed`; complex jobs can take several minutes. If the job cannot finish within the task's available time, use `firecrawl_search` and `firecrawl_scrape` to complete the requested output. Returns job status, progress information, and result data when completed.firecrawl_interactOpen or reuse a live browser session to navigate a page, click controls, fill fields, or run browser code. Provide either `url` or `scrapeId`, and either a natural-language `prompt` or executable `code`; code can run as Bash, Python, or Node with a bounded timeout. This acts on the live site, so actions such as form submission can create persistent external side effects. Returns execution output, stdout/stderr, exit status, and session viewing URLs.firecrawl_interact_stopStop the live interact session associated with a `scrapeId` and release its resources. Returns a success confirmation.firecrawl_parseParse one supported document into markdown, HTML, links, summary, targeted answers, or JSON matching a schema. Supported inputs include common HTML, PDF, Word, RTF, OpenDocument, and spreadsheet files; PDF parsing can be bounded with `pdfOptions.maxPages`. Local MCP reads `filePath` from the server filesystem. Hosted MCP uses two calls: first provide `filePath` to receive upload instructions, upload locally, then call again with the returned `uploadRef`; do not send both fields together. Remote web URLs belong in `firecrawl_scrape`. Set `redactPII` to request redaction of personally identifiable information in the returned content. `zeroDataRetention` requires an eligible authenticated account; omit it for anonymous keyless use. Returns upload instructions for hosted phase one or parsed document content for the final call.firecrawl_monitor_createCreate a recurring scrape, crawl, or search monitor that compares each check with its retained predecessor. The simple form accepts `page`/`pages` or `queries` plus a plain-language `goal`; the advanced `body` form controls targets, schedule, change-tracking formats, judging, retention, webhook, and notifications. In the simple form, a `goal` is required. If `queries` contains one or more non-empty values and is supplied with `page`/`pages`, `queries` create the search target and page targets are ignored. A monitor schedules future network checks and can send configured email or webhook notifications. Returns the created monitor.- +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.
Weathersight
No confirmed install command for Weathersight yet — follow the setup steps linked from its listing page rather than a guessed package name.
Firecrawl MCP Server
{
"mcpServers": {
"firecrawl-firecrawl-mcp-server": {
"command": "npx",
"args": [
"-y",
"firecrawl-mcp"
],
"env": {
"FIRECRAWL_API_KEY": "YOUR_FIRECRAWL_API_KEY_HERE",
"HTTP_STREAMABLE_SERVER": "YOUR_HTTP_STREAMABLE_SERVER_HERE"
}
}
}
}
Frequently asked questions
Weathersight is categorized under Environment & Nature and uses an install path we have not confirmed yet. Firecrawl MCP Server belongs to Search & Data Extraction and uses a local stdio subprocess. Pick Weathersight for environment & nature work and Firecrawl MCP Server for search & data extraction.
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.
Weathersight is listed as freemium — a free tier with paid plans. Auth: oauth 2.0. Firecrawl MCP Server is listed as freemium — a free tier with paid plans. Auth: api key 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 weathersight and firecrawl-firecrawl-mcp-server as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Weathersight has a quality signal of 51/100 (Good) with 0 views, 0 installs and 0 GitHub stars. Firecrawl MCP Server has 90/100 (Excellent) with 14 views, 0 installs and 7,673 GitHub stars.