io.weathersight/weathersight

by weathersight.io · remote · no sign-in to list tools · v1.0.0 · published by io.weathersight

Historical weather and climate: 100+ years of station data, normals, extremes, and trends.

Changes · 5

Compare Registry entry

21 tools: 5 change things and 16 only read.

Scanned Oct 21, 2026

Deletes or cancels0Claude Code: deny
Can't be undone0Claude Code: ask
Changes things5Claude Code: ask: see these tools
Only reads16Claude Code: allow: see these tools

1 check matched something in the tool definitions. No finding is not a safety guarantee. How the checks work.

claude mcp add --transport http weathersight https://weathersight.io/api/mcp

Findings

Matches of fixed checks, with the text they matched.

1 info

Infofcastevalbygroup
The description is 2,274 characters long, over the 2,000 this check looks for.
Matched text
description ends: "...d, note, error, results, locid, location, evals, n, n_days, error_basis, winners."
What this check looks for

Tools

Open a tool for its reasons and full description. Descriptions are the publisher's own words, shown as they are.

21 tools

Changes things 5Creates or changes something that can be changed back.Claude Code: ask

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).No findings
Why it is in this group
- Nothing in its name or description says what it does, so it is counted as a write.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Description, as the server wrote it
Given 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.
Annotations the server declares
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
- readOnlyHint: true
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 ev…No findings
Why it is in this group
- Nothing in its name or description says what it does, so it is counted as a write.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Description, as the server wrote it
Given 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.
Annotations the server declares
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
- readOnlyHint: true
fcastevalbygroupScores how well each forecast model actually performed at each of many locations, by comparing what the models predicted against what was then observed.1 finding
Why it is in this group
- Nothing in its name or description says what it does, so it is counted as a write.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Findings
- Info
 The description is 2,274 characters long, over the 2,000 this check looks for.
 Matched text
 description ends: "...d, note, error, results, locid, location, evals, n, n_days, error_basis, winners."
 What this check looks for
Description, as the server wrote it
Scores how well each forecast model actually performed at each of many locations, by comparing what the models predicted against what was then observed. Returns one score matrix per location, models by evaluation metrics, for a single weather metric at a single lead time, plus the winning model per location. When to use: Answer 'which forecast model is most accurate here?' at scale — to map the best model by region, to check whether a specific model is worth using over the default blend, or to compare physical and AI models across the world. Date format: ymd_start and ymd_end are YYYYMMDD and inclusive. Inclusive day range as YYYYMMDD. Defaults to the 14 days ending yesterday; today is never included because it has not been verified yet. At most 180 days, which is also how much history the index retains. Performance: Filter by ctryid, latlon+radius_km or a small sample_pct to keep it fast; a global 5 percent sample over 14 days is a few hundred locations. Prerequisites: None. Supply locid, name, latlon+radius_km, ctryid, or nothing at all with a sample_pct for an unbiased global sample. Investigate: Use this to find where a model is strong or weak. Ask for one metric and one lead_time at a time; compare models by reading across each row of evals, and use winners for the answer at a glance. Augment: Back a claim about forecast reliability with the measured error of the named model at that place over the recent past. Notes: Forecasts come from Open-Meteo. Lead time is the number of days ahead the forecast was issued, so lead_time 1 is yesterday's forecast for today; only the indexed lead times are available. The WN2 model is an ensemble mean, which is smoother than the deterministic models and so tends to score slightly better on mae and rmse and slightly worse on extremes. A score is null, never zero, when its sample was too small to measure: fewer than 5 verified days for mae, rmse, mse, bias and ets, or fewer than 10 for acc. Returns: metric, unit, lead_time, ymd_start, ymd_end, days, models, eval_metrics, sample_pct, sample_pct_effective, seed, buckets, count, scanned, truncated, note, error, results, locid, location, evals, n, n_days, error_basis, winners.
Annotations the server declares
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
- readOnlyHint: true
fcastevalbylocationScores how well each forecast model performed at ONE location, across several forecast lead times and across a sliding time window.No findings
Why it is in this group
- Nothing in its name or description says what it does, so it is counted as a write.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Description, as the server wrote it
Scores how well each forecast model performed at ONE location, across several forecast lead times and across a sliding time window. Shows both how fast accuracy decays as the forecast reaches further ahead, and how accuracy at a given lead time has varied over recent weeks. When to use: Answer 'how far ahead can I trust the forecast here?' or 'has the forecast been unusually poor here lately?' Use fcastevalbygroup instead to compare many locations at one lead time. Date format: ymd_start and ymd_end are YYYYMMDD and inclusive. Inclusive day range as YYYYMMDD. Defaults to the 14 days ending yesterday; today is never included because it has not been verified yet. At most 180 days, which is also how much history the index retains. Performance: Fast: one location. The cost grows with the number of lead times and the length of the range. Prerequisites: A location: locid from /api/location, or name, or latlon. Investigate: Ask for several lead_times at once (e.g. 1,3,5,7) to get the skill-decay curve in one call. Set window to get a moving average and see the trend over time rather than one number. Augment: Quantify how reliable a forecast for this place actually is at the lead time being written about. Notes: Forecasts come from Open-Meteo. Lead time is the number of days ahead the forecast was issued; only the indexed lead times are available. A score is null, never zero, when its sample was too small to measure: fewer than 5 verified days for mae, rmse, mse, bias and ets, or fewer than 10 for acc. Returns: locid, location, metric, unit, ymd_start, ymd_end, days, window, num_windows, windows, lead_times, models, eval_metrics, scanned, count, truncated, error, evals, n, n_days, error_basis.
Annotations the server declares
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
- readOnlyHint: true
seasonalSeasonal (monthly) forecast anomalies for the next six months, with the local climatology they are measured against.No findings
Why it is in this group
- Nothing in its name or description says what it does, so it is counted as a write.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Description, as the server wrote it
Seasonal (monthly) forecast anomalies for the next six months, with the local climatology they are measured against. Each result gives, per metric: the ERA5 baseline mean (means), its interannual standard deviation (std), the predicted anomaly (anom, in degrees C / mm / km/h) and how unusual that is, both as standard deviations (norm) and as a percentile rank among the last 30 years (perc). When to use: Answer 'will next month be hotter/wetter than normal here?' or 'where is the coming season predicted to be most unusual?' Date format: ym_start and ym_end are YYYYMM, inclusive. For a single month set both to the same value. Defaults to next month through next month + 5. Performance: Filter by locid, ctryid or latlon+radius_km to keep fast; a whole-world month slice is about 4000 rows and fits in one page. Prerequisites: None; supply locid, name, latlon+radius_km, ctryid, or nothing at all for a global query. Investigate: Rank places by how abnormal the coming months look. Use sort=perc:obs.rain.sum for rainfall and sort=norm:max_t.mean for heat. Augment: Back claims about the coming season with the predicted anomaly and how it compares with the local 30-year normal. Notes: Monthly resolution only — for daily forecasts use typicalweather. The forecast is ECMWF SEAS5; its anomalies are relative to SEAS5's own 1991-2020 model climatology, so means + anom approximates rather than equals the predicted absolute. Returns: ym_start, ym_end, baseline, metrics, count, truncated, note, error, next_cursor, results, locid, location, ym, run_ymd, basis_type, means, std, anom, norm, perc, criteria_met, criteria_met_count.
Annotations the server declares
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
- readOnlyHint: true

Only reads 16Looks things up and changes nothing.Claude Code: allow

anomReturns observations with 1991–2020 baseline comparisons at daily, weekly, or monthly granularity for a location and period.No findings
Why it is in this group
- The description's first verb is "return": a word for reading.
Description, as the server wrote it
Returns 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.
Annotations the server declares
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
- readOnlyHint: true
anomaliesReturns precomputed anomalous observations for locations in a given time period and scope.No findings
Why it is in this group
- The description's first verb is "return": a word for reading.
Description, as the server wrote it
Returns 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.
Annotations the server declares
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
- readOnlyHint: true
breakingReturns anomalous weather conditions (breaking news) across the world or specified countries in the very recent past (observations) or immediate future (forecast).No findings
Why it is in this group
- The description's first verb is "return": a word for reading.
Description, as the server wrote it
Returns 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.
Annotations the server declares
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
- readOnlyHint: true
climatecompsReturns monthly distributions of selected metrics for locations compared against a baseline period.No findings
Why it is in this group
- The description's first verb is "return": a word for reading.
Description, as the server wrote it
Returns 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}.
Annotations the server declares
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
- readOnlyHint: true
climatetrendsReturns monthly timeseries of selected climate trend metrics for one or more locations, suitable for long-term trend analysis.No findings
Why it is in this group
- The description's first verb is "return": a word for reading.
Description, as the server wrote it
Returns 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.
Annotations the server declares
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
- readOnlyHint: true
compareCompares a location's observed weather period against the corresponding periods in a historical baseline distribution.No findings
Why it is in this group
- The name "compare" says "compare": a word for reading.
Description, as the server wrote it
Compares 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.
Annotations the server declares
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
- readOnlyHint: true
countriesReturns countries with their canonical country IDs used in all other API calls.No findings
Why it is in this group
- The description's first verb is "return": a word for reading.
Description, as the server wrote it
Returns 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.
Annotations the server declares
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
- readOnlyHint: true
dailycompReturns per-day observed values with percentiles and z-scores vs a sliding N-day window over a historical baseline.No findings
Why it is in this group
- The description's first verb is "return": a word for reading.
Description, as the server wrote it
Returns 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.
Annotations the server declares
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
- readOnlyHint: true
degreedaysReturns cumulative degree-day indicators (heating/cooling/growing) for a location and period using ERA5 reanalysis data.No findings
Why it is in this group
- The description's first verb is "return": a word for reading.
Description, as the server wrote it
Returns cumulative degree-day indicators (heating/cooling/growing) for a location and period using ERA5 reanalysis data. When to use: Estimate energy demand anomalies or agricultural stress in a recent or upcoming period. Date format: YYYYMMDD for ymd_start and ymd_end. Maximum interval is 14 days per call. Performance: Computed on demand using ERA5; moderate speed. Keep intervals to ≤14 days. Prerequisites: Requires lat/lon directly — no locid needed. Investigate: Use when the query involves power grid strain or energy demand. For forecast context, use future ymd dates. Augment: Adds quantitative energy-demand context to heatwave or cold snap stories. Returns: meta, indicators.
Annotations the server declares
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
- readOnlyHint: true
eventsFinds days matching one or more compound weather conditions (e.g.No findings
Why it is in this group
- The description's first verb is "find": a word for reading.
Description, as the server wrote it
Finds days matching one or more compound weather conditions (e.g. hot + humid, rainy + windy) for a location. Returns up to 5000 most-recent matching events plus the total count. When to use: Count occurrences of compound weather events across years, study extreme or unusual day combinations, or identify streaks of such events. Date format: year_start/year_end as YYYY; month_day_start/month_day_end as MMDD for seasonal filtering within each year. Performance: Computed on demand; returns up to 5000 most-recent matches. Prerequisites: Use /location to obtain a locid first. Investigate: Use when the query involves compound conditions — 'how many days had both extreme heat and thunderstorms?' Combine numeric and condition metrics with AND/OR logic. Augment: Provides event frequency counts for framing rarity in a story ('only 3 such days in the past 20 years'). Notes: Numeric metrics: cloudiness, dewp, dpd, gust, hail_size, hi, insolation, max_dewp, max_dpd, max_hi, max_t, max_wbgt, max_wbulb, max_wind, min_dewp, min_t, min_wchill, rain, rain_12hr, rain_1hr, rain_3hr, rain_6hr, snow, snow_12hr, snow_1hr, snow_3hr, snow_6hr, snow_depth, temp, visibility, wbgt, wbulb, wchill, wind, wind_dir. Condition metrics: is_drizzle, is_dust, is_duststorm, is_fog, is_frozen_rain, is_funnel_cloud, is_hail, is_haze, is_heavy_rain, is_heavy_snow, is_ice_pellets, is_mist, is_rain, is_smoke, is_snow, is_squall, is_thunderstorm. Do not specify lower or upper bound when dealing with absolutes unless it is required. Sensible defaults are populated automatically and if the values provided fall out of those, the request is deemed invalid. Returns: locid, name, total_events, events, datestamp, max_t, max_t_complete, min_t, min_t_complete, rain, rain_complete, snow, temp, dewp, wind, max_wind, gust, conditions, criteria_met.
Annotations the server declares
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
- readOnlyHint: true
extremesReturns extreme value analysis (return periods) for a specified location and metric.No findings
Why it is in this group
- The description's first verb is "return": a word for reading.
Description, as the server wrote it
Returns extreme value analysis (return periods) for a specified location and metric. When to use: Quantify the statistical rarity of a record or near-record value. Typically called after other APIs establish that an observation is anomalous. Performance: Computed on demand; moderate speed. Prerequisites: Use /location to obtain a locid first. Prefer level='area' over 'city' for better recall and longer period of record. Investigate: Use after /recentextremes or /anom establishes a high value; provides the return-period framing ('a once-in-50-year event'). Augment: Provides the statistical rarity framing needed for record-event stories. Try both src_types 'Obs' and 'ERA5' for non-US locations to account for discontinuous station records. Returns: locid, period, months_covered, window_size, N, coverage_pct, results, result.metric, result.value, result.return_period.
Annotations the server declares
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
- readOnlyHint: true
locationReturns meta information for a location given a name, locid, or lat/lon.No findings
Why it is in this group
- The description's first verb is "return": a word for reading.
Description, as the server wrote it
Returns meta information for a location given a name, locid, or lat/lon. When to use: Obtain the canonical locid needed by all location-specific API calls. Typically the first call in any workflow. Performance: Fast — precomputed lookup. Prerequisites: None — this is the entry point. Investigate: Call first whenever the user names a city or region; cache the locid for all subsequent calls in the session. Use 'City, State Country' format (e.g. 'Austin TX USA'). Augment: Resolve city names from the article to locids early; reuse them throughout augmentation to avoid repeated name lookups. Returns: name, locid, friendly, lat, long, country, icao, elevation, timezone, wmo.
Annotations the server declares
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
- readOnlyHint: true
metricsReturns the catalogue of all supported weather metric identifiers with units and categories.No findings
Why it is in this group
- The description's first verb is "return": a word for reading.
Description, as the server wrote it
Returns the catalogue of all supported weather metric identifiers with units and categories. When to use: Resolve metric IDs to human-friendly names, units, and categories. Call once and cache per session. Performance: Fast — static data; safe to cache for the lifetime of a session. Prerequisites: None. Investigate: Call once at session start; use metric.id as a lookup key throughout the conversation. Augment: Translate metric IDs into readable labels for article text and chart axes. Returns: metrics, metric.id, metric.name, metric.cat, metric.type, metric.dist.
Annotations the server declares
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
- readOnlyHint: true
recentextremesReturns recent weather records (all-time or period-of-record extremes) for the world or specified countries.No findings
Why it is in this group
- The description's first verb is "return": a word for reading.
Description, as the server wrote it
Returns recent weather records (all-time or period-of-record extremes) for the world or specified countries. When to use: Find which locations have broken or nearly broken records in a recent date window. Set history_years ≥ 15 to ensure a meaningful period of record. Date format: YYYYMMDD for ymd_start and ymd_end. Keep windows ≤ 3 months per call for reasonable performance. Performance: Computed on demand; slower for large date ranges. Start with scope='monthly' or 'yearly'; fall back to 'weekly' for near-records. Prerequisites: Use /countries for country IDs; use /location for locids. Investigate: Use after /breaking identifies a record-breaking event to get precise extreme-value context. For US locations use period_type='DAY'; for non-US use 'FULL_DAY'. Hourly-derived metrics (wet bulb, wind gusts) for non-US require period_type='DAY'. Augment: Provides the 'record' framing for a story — 'hottest day ever recorded at this station.' Note: FULL_DAY and DAY expose different metric sets. Returns: results, extreme.locid, extreme.name, extreme.country_code, extreme.lat, extreme.lon, extreme.elev, extreme.period_type, extreme.metric, extreme.ymd, extreme.anomaly_type, extreme.scope, extreme.value, extreme.history_years.
Annotations the server declares
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
- readOnlyHint: true
timeseriesReturns aggregated metric values as a yearly or monthly timeseries for a location.No findings
Why it is in this group
- The description's first verb is "return": a word for reading.
Description, as the server wrote it
Returns aggregated metric values as a yearly or monthly timeseries for a location. When to use: Detect long-term trends and compute statistical significance (r-squared, p-value). Best suited for multi-decade spans. Date format: mm_dd_start/mm_dd_end as MMDD (day-of-year window, not a calendar year); year_start/year_end as YYYY. Note: Use mm_dd_start/mm_dd_end as MM when months are specified and MMDD when week-level granularity is needed. When day-level info is needed use /events or /dailycomp. Performance: Computed on demand; slower for large date ranges or many metrics. Prerequisites: Use /location to obtain a locid first. Investigate: Use for trend analysis ('Is max temperature at location X increasing over decades?'). Combine with r-squared post-processing for significance. Augment: Provides decadal trend context alongside current anomalies ('temperatures have risen 1.5°C over 40 years'). Returns: locid, lat, lon, xvals, yvals.
Annotations the server declares
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
- readOnlyHint: true
typicalweatherReturns statistical distributions of weather attributes (temperature, precipitation, wind, etc.) for a location and time period.No findings
Why it is in this group
- The description's first verb is "return": a word for reading.
Description, as the server wrote it
Returns statistical distributions of weather attributes (temperature, precipitation, wind, etc.) for a location and time period. When to use: Establish the climatological baseline — what is 'normal' for this location and period. Use before discussing anomalies. Date format: YYYY[MM[DD]]: YYYYMMDD for a specific week, YYYYMM for a month, YYYY for a seasonal or annual overview. Note: YYYYMMDD does not give info about daily obs. If a date is specified it corresponds to the week. Use /events for daily history. Performance: Computed on demand; moderate speed. Avoid date spans wider than one year. Prerequisites: Use /location to obtain a locid first. Investigate: Good for grounding anomaly claims — e.g. 'Is 35°C in July unusual for Madrid?' Check distributions before asserting extremeness. Augment: Use to provide climatological context before describing observed anomalies in an article. Returns: duration, observations, conditions, probs, pcps, means, >>.
Annotations the server declares
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
- readOnlyHint: true

This is not a safety rating, and no finding is not a safety guarantee. The groups and findings come from fixed checks of the tool definitions the server returned on the date shown, not from its code or what it does when called. How the checks work.

Install

Pinned to version 1.0.0. Values in angle brackets are yours to fill in.

claude mcp add --transport http weathersight https://weathersight.io/api/mcp

Run in a terminal.

Claude Code permissions

Allow the reads, ask before a change, deny the deletes. Paste into .claude/settings.json.

.claude/settings.json

{
  "permissions": {
    "allow": [
      "mcp__weathersight__anom",
      "mcp__weathersight__anomalies",
      "mcp__weathersight__breaking",
      "mcp__weathersight__climatecomps",
      "mcp__weathersight__climatetrends",
      "mcp__weathersight__compare",
      "mcp__weathersight__countries",
      "mcp__weathersight__dailycomp",
      "mcp__weathersight__degreedays",
      "mcp__weathersight__events",
      "mcp__weathersight__extremes",
      "mcp__weathersight__location",
      "mcp__weathersight__metrics",
      "mcp__weathersight__recentextremes",
      "mcp__weathersight__timeseries",
      "mcp__weathersight__typicalweather"
    ],
    "ask": [
      "mcp__weathersight__bestplace",
      "mcp__weathersight__besttime",
      "mcp__weathersight__fcastevalbygroup",
      "mcp__weathersight__fcastevalbylocation",
      "mcp__weathersight__seasonal"
    ],
    "deny": []
  }
}

Tools that only read are allowed, tools that change things ask first, tools that delete or cancel are denied. It assumes the server is installed as weathersight. Review it before you use it.

Keep track

Get told when this server's tools change: a new tool, a new description, a new class.

https://anlyon.dev/servers/io.weathersight/weathersight/changes.xml

An Atom feed. Works in any feed reader or Slack's RSS app.

Anlyon alternative

5 of these tools change something. Run those as governed actions.

Declare what an action changes, and Anlyon puts it under a shared limit, binds every approval to the exact request, and grades the outcome. It works on any HTTPS API you can describe as an action.

Anlyon does not run, proxy or govern this MCP server. A tool your own code calls directly is not routed through Anlyon and is not governed by it.

Import an OpenAPI spec →

Compare with other servers for the same product.

Source: MCP Registry · repository. Synced Oct 21, 2026, 18:53 UTC.

For agents: Markdown · JSON · report this listing