# Smarter Weather (remote · mcp.smarterweather.com)

Smarter Weather MCP: forecasts, alerts, outlooks, observations, AQI, grids, and map imagery.

- Trust score: 84/100 (high trust)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-21

## Components

- remote · `mcp.smarterweather.com`: 84/100 (this document), [markdown](https://verifymcp.io/servers/smarterweather-weather/mcp-2.md), [page](https://verifymcp.io/servers/smarterweather-weather/mcp-2)
- npm · `@smarterweather/mcp-weather`: 49/100, [markdown](https://verifymcp.io/servers/smarterweather-weather/smarterweather-mcp-weather.md), [page](https://verifymcp.io/servers/smarterweather-weather/smarterweather-mcp-weather)

## Channel facts

- Endpoint: `https://mcp.smarterweather.com`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.0.1`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-21.

- **Endpoint Security**: 74/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one.
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 76/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 11708 tokens (~325/item across 36 items; 33 tools + 3 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 93/100
  - Stability observed for 28 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 99% of tool parameters carry a description.
  - Structured output schemas are declared (88% of tools); any adoption earns full credit.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 33 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 34 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.
  - Supports UI / widget rendering.

## Install

### How do I install the Smarter Weather MCP server?

Smarter Weather is a hosted endpoint at https://mcp.smarterweather.com/, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http smarterweather-weather 'https://mcp.smarterweather.com/'
```

### Cursor

```json
{
  "mcpServers": {
    "smarterweather-weather": {
      "url": "https://mcp.smarterweather.com/"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "smarterweather-weather": {
      "type": "http",
      "url": "https://mcp.smarterweather.com/"
    }
  }
}
```

### Codex

```toml
[mcp_servers.smarterweather-weather]
url = "https://mcp.smarterweather.com/"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "smarterweather-weather": {
      "type": "remote",
      "url": "https://mcp.smarterweather.com/",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add smarterweather-weather --url 'https://mcp.smarterweather.com/' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  smarterweather-weather:
    url: "https://mcp.smarterweather.com/"
```

### Netclaw

```json
{
  "McpServers": {
    "smarterweather-weather": {
      "Transport": "http",
      "Url": "https://mcp.smarterweather.com/"
    }
  }
}
```

### Vellum

```bash
assistant mcp add smarterweather-weather -t streamable-http -u 'https://mcp.smarterweather.com/'
```

### Other

```json
{
  "mcpServers": {
    "smarterweather-weather": {
      "type": "http",
      "url": "https://mcp.smarterweather.com/"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-20 (score 84, +1)

No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-19 (score 83, 0)

- [functional] Server version: 0.0.0.148 → 0.0.0.149
- [functional] New tool “get_path_exposure”

### 2026-09-18 (score 83, +1)

- [functional] Server version: 0.0.0.147 → 0.0.0.148

### 2026-09-17 (score 82, 0)

- [functional] Server version: 0.0.0.146 → 0.0.0.147

### 2026-09-15 (score 82, +1)

- [functional] Server version: 0.0.0.145 → 0.0.0.146

### 2026-09-13 (score 81, +1)

No change was recorded against any check on this day. Stability & Change Management went from 63 to 67. That category is still filling its 30-day observation window: 19 days of observed history at the previous scan, 20 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-12 (score 80, 0)

- [functional] Server version: 0.0.0.143 → 0.0.0.145

### 2026-09-11 (score 80, +1)

- [functional] Server version: 0.0.0.142 → 0.0.0.143

## MCP tools (33)

### `get_forecast` (~441 tokens)

Get forecast

Complete weather overview for a location: current conditions, daily forecast (day/night periods, SPC threats, severity, CAPE, UV), active alerts, and convective outlooks in one call. Data is pre-aggregated across NBM, HRRR, GFS, RTMA, and SPC and unit-converted server-side. This is the primary weather tool; reach for lower-level tools only when you need raw observations or a specific dataset. Accepts a place name directly. Examples: {"location": "Denver"} or {"location": "Portland, OR", "days": 5} or {"lat": 41.4, "lon": -92.9}.

Input parameters:

- `days` (integer): Number of forecast days (1-14). Default 10.
- `detail_level` (string): standard: compact response (~5-10KB); daily includes day_precip_probability / night_precip_probability when available (precip_probability is max of day/night). detailed: also preserves CAPE, UV, full…
- `include` (string): Comma-separated sections: current, daily, hourly, alerts, outlooks. Default "current,daily,alerts,outlooks". Use get_hourly_forecast for hourly detail.
- `lat` (number): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `location` (string): Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
- `lon` (number): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).
- `units` (string): Unit system for all values in the request and response: imperial (°F, mph, inches), metric (°C, km/h, mm), or si (K, m/s, mm). Defaults to imperial.

Output parameters:

- `data_status` (object): Present only when the platform reports degraded/outage data sources: overall state, a caveat note, and the affected sources. Absent means no advisory was available -- not a freshness guarantee. See g…
- `forecast` (object)
- `location` (object)
- `units` (string)
- `widget` (object): sw-ui-spec widget block rendered by the MCP Apps weather widget (ui://weather-widget/v1/index.html). Additive; safe to ignore.

### `get_hourly_forecast` (~558 tokens)

Get hourly forecast

Blended hourly forecast: temperature, feels-like, humidity, wind, precipitation probability/amount, conditions, and icon per hour. Snapped to the current hour so hourly[0] is "now". Timestamps are UTC ISO 8601; convert to the local timezone before presenting. Ask for the days you need up front -- one call with days: 4 beats four calls. ALWAYS check hourly_coverage before answering about a specific hour: it reports first_time and last_time (the window the rows actually span), sample_interval_hours (past the first day rows are every 2-3h, not every hour), and truncated: true when upstream returned less than you asked for. If the hour the user cares about is after last_time, say the forecast does not reach that far yet rather than answering from the nearest row you do have. For one stretch of time ask for that stretch with hours_from/hours_to: it comes back hour by hour even where the full range would be sampled. Accepts a place name or coordinates. Examples: {"location": "Portland, OR", "days": 2} or {"lat": 41.88, "lon": -87.63, "hours_from": 36, "hours_to": 48}.

Input parameters:

- `days` (integer): Days of hourly data (1-7). Default 2. Widened when hours_to reaches further.
- `detail_level` (string): standard: compact hourly data (sampled past 24h). detailed: preserves CAPE, ceiling, UV, gust, thunderstorm probability for the first 48h.
- `hours_from` (integer): Window start, in hours from now (0 = the current hour).
- `hours_to` (integer): Window end, in hours from now, exclusive. 36 to 48 is hours 36-47.
- `lat` (number): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `location` (string): Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
- `lon` (number): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).
- `units` (string): Unit system for all values in the request and response: imperial (°F, mph, inches), metric (°C, km/h, mm), or si (K, m/s, mm). Defaults to imperial.

Output parameters:

- `data_status` (object): Present only when the platform reports degraded/outage data sources: overall state, a caveat note, and the affected sources. Absent means no advisory was available -- not a freshness guarantee. See g…
- `forecast` (object)
- `location` (object)
- `units` (string)
- `widget` (object): sw-ui-spec widget block rendered by the MCP Apps weather widget (ui://weather-widget/v1/index.html). Additive; safe to ignore.

### `search_locations` (~192 tokens)

Search locations

Resolve a place query to candidate locations with coordinates. Accepts city names ("Denver"), city+state ("Portland, OR" via query), ZIP codes ("50219"), or partial input with fuzzy=true for autosuggest-style matching ("bost" -> Boston). Returns ranked candidates with lat/lon. Most weather tools accept a `location` string directly and geocode internally -- use this tool only to disambiguate ("which Springfield?") or to present location choices to the user. Example: {"query": "Springfield"} returns all major Springfields ranked by place importance.

Input parameters:

- `fuzzy` (boolean): Autosuggest mode for partial/misspelled input. Default false (exact search).
- `limit` (integer): Maximum candidates to return (1-10). Default 5.
- `query` (string, required): Place query: city, "city, state", ZIP, or partial text with fuzzy=true.

Output parameters:

- `candidates` (array)
- `query` (string)

### `reverse_geocode` (~132 tokens)

Reverse geocode

Resolve coordinates to a human-readable place (city, state, county, timezone). Use when you have lat/lon but need a display name or the local timezone. Example: {"lat": 39.74, "lon": -104.99} -> Denver, Colorado, America/Denver.

Input parameters:

- `lat` (number, required): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `lon` (number, required): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).

Output parameters:

- `lat` (number)
- `lon` (number)
- `place` (object)

### `get_alerts` (~369 tokens)

Get NWS alerts

NWS watches, warnings, advisories. Point (city/ZIP/lat+lon): containing polygons. BBox or US state/DC/CONUS (codes, full names, US/national): intersecting polygons. A city miss is not a statewide all-clear — query the state or a bbox; never say regional inventory is impossible. NY/WA and "New York State"/"Washington State" are states; "New York"/"Washington" stay cities. Omit at for now; at (ISO-8601 UTC) is the snapshot then. Empty = all-clear or purged (~24h). alert_id = detail+geometry, ignores at. Ex: {"location":"WI","events":["Tornado Warning"]}.

Input parameters:

- `alert_id` (string): Alert identifier for detail mode. When set, location is ignored.
- `at` (string): ISO-8601 UTC past instant for the in-effect snapshot. Ignored with alert_id.
- `bbox` (object): Bounding box {west,south,east,north}. Skips geocoding; intersecting polygons.
- `events` (array): Optional event-name filter, e.g. ["Tornado Warning"].
- `lat` (number): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `location` (string): Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
- `lon` (number): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).

Output parameters:

- `alert` (object)
- `alert_id` (string)
- `alerts`
- `location` (object)
- `valid_time` (string): Echo of at when an as-of snapshot was requested.
- `widget` (object): sw-ui-spec widget block rendered by the MCP Apps weather widget (ui://weather-widget/v1/index.html). Additive; safe to ignore.

### `get_time_context` (~235 tokens)

Get time context

Complete temporal context for a location: local time, timezone, 14-day calendar with day names and Today/Tomorrow offsets, sunrise/sunset/solar times (from the weather pipeline's astro product), and moon phase. Use whenever you need to reason about dates, times, or daylight for a location -- including "what time is sunset?", "is it dark there now?", or "what day of the week is the 4th-day forecast?". Accepts a place name directly. Example: {"location": "Seattle"}.

Input parameters:

- `lat` (number): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `location` (string): Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
- `lon` (number): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).

Output parameters:

- `calendar` (array)
- `current_time` (object)
- `daylight` (object)
- `location` (object)
- `moon` (object)

### `get_period_totals` (~435 tokens)

Get period totals

Aggregate a weather variable over one or more time periods. Returns server-computed totals, maxima, minima, or averages per period. Period start/end times should use the user's local timezone boundaries (not UTC midnight). Response includes the converted value and unit per period. Ideal for questions like "total rainfall today and tomorrow" or "peak wind speed this weekend". Accepts a place name directly. Example: {"location": "Portland, OR", "variable": "precipitation", "aggregation": "sum", "periods": [{"start": "2026-07-08T07:00:00Z", "end": "2026-07-09T07:00:00Z", "label": "Today"}]}.

Input parameters:

- `aggregation` (string): Aggregation function. Default sum. Use sum for precipitation/snowfall, max for temperature/wind, min for low temperatures, avg for humidity/cloud cover.
- `dataset_id` (string): Dataset override. Default: auto-resolved NBM for the location.
- `lat` (number): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `location` (string): Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
- `lon` (number): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).
- `periods` (array, required): Time periods to aggregate over (1-14).
- `units` (string): Unit system for all values in the request and response: imperial (°F, mph, inches), metric (°C, km/h, mm), or si (K, m/s, mm). Defaults to imperial.
- `variable` (string, required): Standard variable name (e.g. precipitation, snowfall, temperature_2m, wind_speed_10m, cape).

Output parameters:

- `aggregation` (string)
- `location` (object)
- `message` (string)
- `periods` (array)
- `variable` (string)

### `compare_locations` (~168 tokens)

Compare locations

Compare forecast variables across multiple locations side-by-side in one batched call. Returns a distilled per-location series matrix for direct comparison -- prefer this over N sequential forecast calls. Locations accept place names directly. Example: {"locations": [{"location": "Denver"}, {"location": "Boulder, CO"}], "variables": ["temperature_2m", "precipitation_probability"], "hours": 48}.

Input parameters:

- `dataset_id` (string): Dataset override. Default: auto-resolved NBM per location.
- `hours` (integer): Forecast hours. Default 24.
- `locations` (array, required): Locations to compare (2-10). Each takes location OR lat/lon, optional label.
- `variables` (array, required): Standard variable names (e.g. temperature_2m, precipitation).

Output parameters:

- `comparisons` (array)
- `hours` (number)
- `variables` (array)

### `find_best_window` (~348 tokens)

Find best weather window

Find the optimal time window for an activity based on weather criteria. Scans the forecast and returns daylight-aware periods matching all conditions. Criteria are expressed in the selected `units` system (default imperial: °F, mph, miles, feet). Example: {"location": "Boulder, CO", "criteria": {"min_temperature": 55, "max_wind_speed": 15, "max_precipitation_probability": 20}, "hours": 72, "activity_duration_hours": 3}.

Input parameters:

- `activity_duration_hours` (integer): Minimum consecutive hours meeting criteria. Default 2.
- `criteria` (object, required): Weather criteria defining acceptable conditions (all optional).
- `daylight_only` (boolean): Only consider daylight hours (sunrise to sunset). Default true.
- `hours` (integer): Hours to search. Default 72.
- `lat` (number): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `location` (string): Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
- `lon` (number): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).
- `units` (string): Unit system for all values in the request and response: imperial (°F, mph, inches), metric (°C, km/h, mm), or si (K, m/s, mm). Defaults to imperial.

Output parameters:

- `activity_duration_hours` (number)
- `criteria_applied` (object)
- `daylight_only` (boolean)
- `location` (object)
- `message` (string)
- `sun_times` (array)
- `units` (string)
- `windows` (array)

### `get_outlooks` (~403 tokens)

Get hazard outlooks

Hazard outlooks affecting a location. hazard=severe returns SPC convective outlooks (Day 1-8 categorical risk + tornado/wind/hail probabilities); hazard=fire returns SPC fire weather outlooks; hazard=rain returns WPC Excessive Rainfall Outlook polygons (days 1-3); hazard=heat returns the NWS HeatRisk index at the point (0 none .. 4 extreme, days 1-3). include_narrative=true adds the forecaster discussion for severe (SWO), fire (FWD), or rain (QPF/QPFERD; one PIL for all days). An empty result means no outlook covers the point -- not a failure. Examples: {"location": "Moore, OK", "hazard": "severe", "include_narrative": true} or {"location": "Phoenix", "hazard": "heat"}.

Input parameters:

- `day` (integer): Outlook day for the narrative filter (1-8). Default 1.
- `hazard` (string): Hazard family: severe = SPC convective, fire = SPC fire weather, rain = WPC excessive rainfall, heat = NWS HeatRisk index. (Winter/WSSI is a planned expansion.)
- `include_narrative` (boolean): Include the forecaster narrative for the requested day (severe, fire, and rain).
- `lat` (number): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `location` (string): Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
- `lon` (number): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).

Output parameters:

- `day` (number)
- `hazard` (string)
- `heat_risk` (array)
- `location` (object)
- `narrative`
- `outlooks` (array)

### `get_forecast_discussion` (~644 tokens)

Get forecast discussion

Expert forecaster text products. type=afd: Area Forecast Discussion. type=hwo: Hazardous Weather Outlook. type=now: WFO short-term NOW. type=fwf/hls/esf: local fire weather / hurricane local statement / hydrologic discussion. type=mcd: SPC Mesoscale Discussion. type=mpd: WPC Mesoscale Precipitation Discussion (flash flood). type=swo/fwd/ero: national outlook discussions. type=tcd/tcp/tcm/twd/two: NHC tropical text (type=two is the text TWO, not GIS nhc_two). type=pmd: WPC/CPC desk discussion (pass awips_id for a specific desk, e.g. PMDSPD). type=pwo: SPC public weather outlook. National types (swo/fwd/ero/tcd/tcp/tcm/twd/two/pmd/pwo) need no location; `day` selects the outlook day for swo and fwd. summary_only=true returns the pipeline LLM summary without the full body. Examples: {"location": "Des Moines", "type": "afd"} or {"type": "swo", "day": 2, "summary_only": true}.

Input parameters:

- `awips_id` (string): Full AWIPS identifier (e.g. TCDAT1, PMDSPD). More specific than type + location. Exact source_ref match.
- `day` (integer): Outlook day for type=swo or type=fwd (1-8). Ignored for the other types; WPC files ERO days 1-3 under one product.
- `lat` (number): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `limit` (integer): Number of recent products (1-10). Default 1 (latest).
- `location` (string): Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
- `lon` (number): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).
- `summary_only` (boolean): Return only the LLM summary + sections, omitting the full body text.
- `type` (string, required): Product type: afd (WFO discussion), hwo (hazard outlook), now (short-term NOW), fwf/hls/esf (local WFO), mcd (SPC mesoscale), mpd (WPC precipitation discussion), swo (SPC convective outlook), fwd (SP…
- `wfo` (string): WFO identifier override (e.g. BOU). Default: resolved from the location.

Output parameters:

- `location` (object)
- `products` (array)
- `type` (string)

### `get_storm_reports` (~256 tokens)

Get storm reports

Recent NWS Local Storm Reports (LSRs) -- verified reports of tornadoes, hail, damaging winds, flooding near a location. Use to confirm severe weather occurrence or assess reported damage. valid_time is event occurrence (UTC); cite in local time. Example: {"location": "Wichita", "hours": 12, "type": "H"}.

Input parameters:

- `hours` (integer): Lookback window in hours (1-24). Default 6.
- `lat` (number): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `location` (string): Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
- `lon` (number): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).
- `type` (string): Report type filter: T=tornado, H=hail, W=wind, F=flood, D=damage, S=snow.

Output parameters:

- `hours` (number)
- `location` (object)
- `reports` (object)

### `get_lightning_activity` (~225 tokens)

Get lightning activity

Real-time lightning near a location: GLM satellite flash count (30km/10min) and MRMS ground-truth lightning density + 30-minute probability. The summary field is ready-to-use. A zero flash count means no lightning inside that window -- report it as a quiet observation scoped to the window in `scope`, never as a data gap. Only call when storms may be active or the user asks about lightning. Example: {"location": "Tampa"}.

Input parameters:

- `lat` (number): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `location` (string): Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
- `lon` (number): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).

Output parameters:

- `lightning` (object)
- `location` (object)
- `scope` (string): Area and time window searched, so a zero count is unambiguous to report.

### `get_sounding` (~286 tokens)

Get radiosonde sounding

Nearest RAOB (radiosonde) vertical soundings to a point. Each sounding carries: profile (pressure-indexed thermodynamics: pressure_hpa, height_m, temperature_c, dewpoint_c, wind arrays), wind_profile (height-indexed winds for hodographs/shear), and derived indices (sbcape/mucape/mlcape + cin, lifted_index, k_index, total_totals, pwat_mm, freezing_level_m, lcl/lfc/el, bulk_shear_0_6km_kt). Soundings launch at 00Z/12Z so data can be hours old. Example: {"location": "Norman, OK"}.

Input parameters:

- `lat` (number): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `location` (string): Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
- `lon` (number): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).
- `n` (integer): Number of nearest soundings (1-5). Default 1.

Output parameters:

- `location` (object)
- `soundings` (object)

### `get_forecast_distribution` (~478 tokens)

Get forecast distribution

Probabilistic forecast guidance from NBM for one aspect of the weather: percentile ranges (p10-p90), exceedance probabilities, and ensemble spread. Use this for any question about odds, ranges, potential or confidence ("how much could we get", "worst case for the wind", "how sure is this") -- a deterministic forecast value cannot answer one. Reading the percentiles: p50 is the most likely outcome, p90 is the reasonable worst case when the risk is the high end (snow totals, wind, rainfall), and p10 is the reasonable worst case when the risk is the low end (cold, minimum visibility, ceiling). A single percentile is not the forecast -- report the likely value with the tail that matters, and label which is which. Aspects: precip (PoP, QPF + percentiles), snow (accumulation percentiles, >1/2/4in probabilities, snow level), ice (freezing rain, accretion), temperature (temp/dewpoint + stddev), wind (speed/gust percentiles), severe (hail/tornado/damaging-wind probabilities), aviation (LIFR/IFR/MVFR visibility + ceiling probabilities), confidence (ensemble stddev; low spread = settled forecast, high spread = details still in play). Examples: {"location": "Denver", "aspect": "snow", "hours": 72} or {"lat": 32.9, "lon": -97.0, "aspect": "severe"}.

Input parameters:

- `aspect` (string, required): Which distribution family to return (see tool description).
- `hours` (integer): Forecast hours (1-264). Default varies by aspect (48-72).
- `lat` (number): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `location` (string): Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
- `lon` (number): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).

Output parameters:

- `aspect` (string)
- `hours` (number)
- `location` (object)
- `series` (array)

### `get_current_conditions` (~214 tokens)

Get current conditions

Current weather right now at a location from two independent sources in one call: the RTMA gridded analysis (exact-point values, updated sub-hourly) and the nearest METAR station observation (ground truth with raw METAR, flight category). Use the analysis for point-accurate values and the station for verification. For a forecast, use get_forecast. Example: {"location": "Pella, IA"}.

Input parameters:

- `lat` (number): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `location` (string): Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
- `lon` (number): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).

Output parameters:

- `analysis`
- `location` (object)
- `nearest_station`

### `get_observations` (~274 tokens)

Get station observations

METAR surface observations from weather stations: temperature, wind, visibility, ceiling, flight category, raw METAR. Nearest mode (default) returns the closest N stations to a location; station mode returns history for a specific ICAO identifier. Examples: {"location": "Denver", "n": 3} or {"station": "KJFK", "hours": 6}.

Input parameters:

- `hours` (integer): Hours of history in station mode (1-24).
- `lat` (number): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `location` (string): Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
- `lon` (number): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).
- `n` (integer): Number of nearest stations (1-10). Default 1. Ignored in station mode.
- `station` (string): ICAO station identifier (e.g. KJFK). Switches to station-history mode.

Output parameters:

- `location` (object)
- `observations` (object)
- `station` (string)

### `list_datasets` (~228 tokens)

List datasets

Discover the datasets (model grids, analyses, observations) available at a location, with per-dataset freshness (data age, latest model run). Datasets vary by domain (CONUS/Alaska/Hawaii). Use this to find dataset_id values for query_dataset and describe_dataset, or to assess whether data is current before making decisions. Example: {"location": "Anchorage"}.

Input parameters:

- `include_freshness` (boolean): Include per-dataset data age and run times. Default true.
- `lat` (number): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `location` (string): Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
- `lon` (number): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).

Output parameters:

- `datasets` (object)
- `freshness` (object)
- `location` (object)

### `describe_dataset` (~96 tokens)

Describe dataset

Variables available in a dataset, with standard names, units, descriptions, and the time range of available data. Use before query_dataset to discover valid variable names. Example: {"dataset_id": "nbm_conus"}.

Input parameters:

- `dataset_id` (string, required): Pipeline dataset identifier (e.g. "nbm_conus", "mrms_reflectivity_conus"). Discover valid values with list_datasets; inspect variables with describe_dataset.

Output parameters:

- `dataset_id` (string)
- `detail` (object)

### `query_dataset` (~523 tokens)

Query dataset

Raw time series from a specific dataset for specific variables at a point. Power-user access to any gridded product (NBM, HRRR, RRFS, GFS, RTMA, MRMS, air quality, ...). Time modes: hours (next N hours, default 24), time_start+time_end (explicit ISO-8601 window), or latest=true (single most-recent value). reference_time pins a specific model run, and each returned series reports the run that served it (reference_time, or reference_times when a series mixes runs) — check it before comparing two runs, since a run older than about 48 hours may no longer be available. For blended forecasts use get_forecast instead. Examples: {"location": "Denver", "dataset_id": "rrfs_surface", "variables": ["temperature_2m"], "hours": 18} or {"lat": 41.4, "lon": -92.9, "dataset_id": "rtma_conus", "variables": ["temperature_2m"], "latest": true}.

Input parameters:

- `dataset_id` (string): Dataset to query. Default: the NBM dataset for the location domain (nbm_conus/nbm_alaska/nbm_hawaii). Discover options with list_datasets.
- `hours` (integer): Forecast/lookahead hours from now (1-264). Default 24 when no other time mode set.
- `lat` (number): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `latest` (boolean): Return only the most recent value (analysis datasets like RTMA/MRMS).
- `location` (string): Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
- `lon` (number): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).
- `reference_time` (string): Pin a specific model run (ISO 8601). Default: latest run.
- `time_end` (string): ISO 8601 window end (with time_start).
- `time_start` (string): ISO 8601 window start (with time_end).
- `variables` (array, required): Standard variable names (e.g. temperature_2m, precipitation). Discover with describe_dataset.

Output parameters:

- `location` (object)
- `series` (array)

### `get_growing_degree_days` (~481 tokens)

Get growing degree days

Growing Degree Units (GDU / GDD) for a US location (CONUS, Alaska, Hawaii), computed from daily max/min temperatures. Pass a crop id (e.g. "corn", "soybean", "wheat") to use calibrated base/upper thresholds, or crop="custom" with base_temp_c (and optional upper_temp_c / method). Without season_start you get per-day GDU across the forecast horizon; WITH season_start (YYYY-MM-DD) you get the cumulative season-to-date total (observed history + today + forecast) plus a per-day cumulative series -- the number a grower tracks against crop milestones. Answers "how many growing degree days has my corn accumulated since May 1?" and "what's the GDU forecast this week?".

Input parameters:

- `base_temp_c` (number): Custom base threshold in °C. Required when crop="custom".
- `crop` (string, required): Crop id from the catalog (e.g. "corn", "soybean", "wheat") or "custom" to supply your own thresholds via base_temp_c.
- `day_definition` (string): Daily boundary: "nws" (default; NBM MaxT/MinT period extremes) or "local_calendar" (midnight-to-midnight local day).
- `days` (integer): Forecast horizon in days (default 10).
- `include_milestones` (boolean): Include the crop's growth-stage GDU milestones in the response.
- `lat` (number, required): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `lon` (number, required): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).
- `method` (string): GDU method for custom crops. Defaults from whether upper_temp_c is set.
- `season_start` (string): Season/planting start as YYYY-MM-DD (local date). Presence switches the response to a cumulative season-to-date GDU total. Must be within the ~180-day observed window.
- `unit` (string): Unit system for GDU + temps. Default imperial (°F-days).
- `upper_temp_c` (number): Custom upper cutoff in °C (enables the modified method). Optional.

### `get_climate_normals` (~311 tokens)

Get climate normals

Day-of-year climate normals (NCEI 1991-2020 30-year averages) for a US location, from the nearest station with a record. Returns normal high, normal low, and normal mean for each date in the window, plus the station and how far away it is. Use this whenever a question needs a baseline rather than a forecast: "is this warm for October?", "what is a typical high here in January?", "how does this week compare to normal?". Pair it with get_forecast to say how far above or below normal the coming days run. Covers dates by day of year, so it answers for any date, past or future -- these are long-period averages, not a forecast and not observed history for a specific year.

Input parameters:

- `days` (integer): Range length in days when start/end are omitted; the window opens today (default 14).
- `end` (string): Inclusive range end as YYYY-MM-DD. Must be supplied with start.
- `lat` (number, required): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `lon` (number, required): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).
- `start` (string): Inclusive range start as YYYY-MM-DD. Must be supplied with end.
- `unit` (string): Unit system for the normals. Default imperial (°F).

### `get_forecast_skill` (~1339 tokens)

Get forecast skill

How accurate our forecasts have actually been near a location, measured against observed analysis truth. Returns bias (positive = the model runs high), mean absolute error, RMSE, and a skill score against local climatology, per model, weather variable, and forecast lead time; continuous and vector entries also carry persistenceSkillScore, skill against the analysis at forecast issue time (null means not enough persist pairs, not zero skill -- do not compare it to skillScore as if they shared a denominator), and analysisDisagreementMae, the analyses' own disagreement at that lead -- a floor on how good the forecast can look, not a skill score and not an excuse (null means the sibling row is missing or below minimumSamples); for probability forecasts, the Brier score and a reliability breakdown. Use this to qualify a forecast rather than assert it -- "NBM has been running 1.8F warm at 3-day leads near you, so treat that 72 as around 70" -- and to answer "how much should I trust this forecast", "is the model biased here", or "how accurate were you last month". Evidence is reported at three scopes side by side: the exact point (strongest, slowest to accumulate), the ~50km neighborhood, and the ~300km region. Prefer the most specific scope that has samples. Metrics below minimumSamples observations are withheld and listed under insufficientHistory with their count -- say that history is still accumulating rather than treating thin numbers as evidence. Coverage is a rolling recent window over verified US variables, not all of history. Entries are per model and their samples are not matched, so never conclude that one model beats another by comparing their numbers here. Each entry states the truth field it was measured against -- one designated analysis per variable -- so never compare numbers carrying different truth values either. Each entry also states the regime it was measured under: ALL for every observation regardless of weather, or a conditioned tier such as SEA:D…

Input parameters:

- `lat` (number): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `lead_hours` (integer): Narrow to the lead time being asked about, in hours; the containing lead bucket is selected for you (60 gives the 48-72h bucket). Use the lead of the forecast you are qualifying: ~24 for tomorrow, ~7…
- `location` (string): Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
- `lon` (number): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).
- `model` (string): Narrow to one model, e.g. nbm or rrfs.
- `regime` (string): Ask for a track record measured only under particular conditions, as a comma-separated preference chain, most specific first, e.g. "SCN1:WINDY,SEA:JJA". SEA: is the meteorological season (DJF, MAM, J…
- `truth` (string): Measure against a named truth source instead of the default one for each variable, e.g. urma. Only pass this if the user asked which analysis was used or named one; the default is already the designa…
- `unit` (string): Units for the error magnitudes. Default imperial (bias/MAE/RMSE in °F, mph, in).
- `variable` (string): Narrow to one variable, e.g. temperature_2m, dew_point_2m, wind_speed_10m, wind_gusts_10m, wind_vector_10m, cloud_cover, precipitation, precipitation_probability, or a thresholded rain event such as…

Output parameters:

- `cells` (object)
- `insufficientHistory` (array)
- `location` (object)
- `minimumSamples` (number)
- `skill` (array)
- `tracked` (boolean): Whether this exact coordinate is one the verification pipeline tracks.
- `units` (string)

### `get_forecast_skill_map` (~351 tokens)

Get forecast skill map

Measured forecast skill as a map of res-4 hexes inside a bounding box, sliced from the public skill map. Use this when the question is spatial ("where is NBM temperature skill weak across Colorado"), not "how good is the forecast at this point" — that is get_forecast_skill. Requires model, variable, lead_hours, and bbox {west,south,east,north}. lead_hours selects the containing published bucket (20 → NBM 24); a lead we have not published returns no slices rather than a nearby one. A hex is included when its center is inside the box; edge-overlapping hexes are dropped. The box cannot wrap the dateline. Each cell is [h3, samples, skill_score]; skill_score is unitless (fraction of climatological variance explained) and already gated at n ≥ 30. withheld lists hexes still accumulating. Do not compare slices across models or truths. This is CELL# only — never treat a hex as a person.

Input parameters:

- `bbox` (object, required): Bounding box {west,south,east,north}. Hexes whose H3 center falls inside are returned.
- `domain` (string): Optional domain (conus, alaska, hawaii). Omit unless you already know it.
- `lead_hours` (integer, required): Lead time in hours; the containing published bucket is selected. Never approximated.
- `model` (string, required): Model id, e.g. nbm, gfs, hrrr, or rrfs.
- `variable` (string, required): Verified variable, e.g. temperature_2m, dew_point_2m, precipitation, or precipitation_gt_0p254mm.

Output parameters:

- `atom_resolution` (number)
- `bbox` (object)
- `generated_at` (string)
- `minimum_samples` (number)
- `slices` (array)

### `get_tropical` (~130 tokens)

Get tropical activity

Active NHC (National Hurricane Center) tropical systems: forecast cones, track lines, forecast points, coastal watches/warnings, and 7-day Tropical Weather Outlook formation areas -- Atlantic + East Pacific. Each feature carries a kind (cone | track | points | watch_warning | outlook_area) plus storm name, intensity, and timing properties. include_geometry=true adds full GeoJSON geometries (large). An empty result means no active tropical activity. Example: {} or {"include_geometry": true}.

Input parameters:

- `include_geometry` (boolean): Include full GeoJSON geometries (cone/track polygons). Default false.

Output parameters:

- `active` (boolean)
- `feature_count` (number)
- `features` (array)

### `get_population_exposure` (~183 tokens)

Get population exposure

National population-exposure headline for a risk-zone outlook product: how many people are inside risk bands at or above min_level. Powers headlines like "~57M people under major heat risk tomorrow". hazard=heat covers NWS HeatRisk days 1-3 (levels: 1 minor, 2 moderate, 3 major, 4 extreme). Pass product_id directly for other risk-zone products. Example: {"hazard": "heat", "min_level": 3}.

Input parameters:

- `hazard` (string): Hazard family (expands the day-1..3 product set). Currently: heat (HeatRisk).
- `min_level` (integer): Minimum risk level to count (>=). Default 1 (any elevated risk).
- `product_id` (string): Explicit risk-zone product ID (overrides hazard), e.g. heatrisk_day1_conus.

Output parameters:

- `min_level` (number)
- `summaries` (array)

### `get_path_exposure` (~197 tokens)

Get path exposure

Civic POIs (schools, hospitals, airports, …) inside a caller-supplied GeoJSON Polygon or MultiPolygon. Clip first — do not pass a CONUS HeatRisk dissolve. For an NWS alert use get_alerts({alert_id}) (already includes pois). Optional classes filters the civic allowlist. Example: {"geometry":{"type":"Polygon","coordinates":[[[-88.15,41.77],[-88.14,41.77],[-88.14,41.78],[-88.15,41.78],[-88.15,41.77]]]},"classes":["school"]}.

Input parameters:

- `classes` (array): Optional civic classes: airport, station, hospital, school, university, library, museum, stadium, cemetery, place_of_worship, camp_site, golf, attraction.
- `geometry` (object, required): GeoJSON Polygon or MultiPolygon. Clip national outlooks first.

Output parameters:

- `counts` (object)
- `features` (array)

### `get_climate_records` (~274 tokens)

Get climate reports and records

NWS daily climate data: type=reports returns CLI daily climate reports (observed high/low/precip vs normals per station); type=records returns RER record event reports (record highs/lows/rainfall actually set). Filter by wfo (3-letter office, e.g. DMX), station, date (YYYY-MM-DD), start/end range, or hours lookback. Examples: {"type": "records", "hours": 48} or {"type": "reports", "wfo": "DMX", "date": "2026-07-04"}.

Input parameters:

- `date` (string): Single date, YYYY-MM-DD.
- `end` (string): Range end date, YYYY-MM-DD.
- `hours` (integer): Lookback window in hours (1-168) when no date/range is given.
- `record_type` (string): Record type filter (records only), e.g. HIGH, LOW, RAIN.
- `start` (string): Range start date, YYYY-MM-DD.
- `station` (string): Station identifier filter (reports only).
- `type` (string, required): reports = CLI daily climate reports; records = RER record events.
- `wfo` (string): WFO office filter (e.g. DMX, OUN).

Output parameters:

- `results` (object)
- `type` (string)

### `get_storm_cells` (~249 tokens)

Get storm cells

Radar-identified storm cells near a location, merging NEXRAD Level III algorithm output from the nearest radar site: storm tracks (cell position, movement, forecast positions), hail index (probability of hail/severe hail + max expected size), mesocyclone detections (rotation), and TVS (tornado vortex signatures). Use during active convection to see what the radar algorithms flag. An empty result means no detected cells -- common outside active storms. Example: {"location": "Norman, OK"}.

Input parameters:

- `include` (array): Which detection families to include. Default: all.
- `lat` (number): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `location` (string): Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
- `lon` (number): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).

Output parameters:

- `detections` (object)
- `location` (object)
- `summary` (string): Ready-to-use one-liner. States explicitly when nothing was detected.
- `tracks` (object)

### `get_air_quality` (~316 tokens)

Get air quality

AirNow air quality at a location (CONUS): current overall AQI plus per-pollutant detail (PM2.5, ozone, PM10 concentrations) and the AirNow AQI forecast. AQI scale: 0-50 good, 51-100 moderate, 101-150 unhealthy for sensitive groups, 151-200 unhealthy, 201-300 very unhealthy, 301+ hazardous. pollutants=["aqi"] (default) is the cheap headline call; add pollutant keys or include_forecast=true when the user digs in. Example: {"location": "Boise", "pollutants": ["aqi", "pm25"], "include_forecast": true}.

Input parameters:

- `include_forecast` (boolean): Also return the AirNow next-day AQI forecast.
- `lat` (number): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `location` (string): Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
- `lon` (number): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).
- `pollutants` (array): Which measurements to return. aqi = combined AQI index. Default: ["aqi"].

Output parameters:

- `current` (array)
- `forecast` (array)
- `location` (object)
- `widget` (object): sw-ui-spec widget block rendered by the MCP Apps weather widget (ui://weather-widget/v1/index.html). Additive; safe to ignore.

### `get_map_snapshot` (~879 tokens)

Get map snapshot

Render a weather map image for visual analysis. Simple form: pass `product` (a viz-catalog product_id like "mrms_qpe_01h_pass2_conus", "goes_truecolor_conus", "spc_day1_categorical", "hrrr_precip_hybrid_derived_conus" (future radar), "hrrr_subhourly_conus" (15-min Future Radar), "mrms_radar_nowcast_conus", "rtma_conus", "nbm_daily_temps", or "nexrad_l3:{SITE}:{PRODUCT}" for single-site radar, e.g. "nexrad_l3:TLX:N0B") plus a location and zoom (5=regional, 8=metro, 10=city). Composed form: pass `scene` -- a declarative scene document layering basemap + multiple weather products + active alerts + storm features + inline GeoJSON in one image (layers draw bottom-to-top, under basemap labels). Example scene: {"scene":"1.0","view":{"center":{"lat":43.8,"lon":-91.2},"zoom":8},"layers":[{"type":"weather","product":"goes_truecolor_conus"},{"type":"weather","product":"nexrad_l3:ARX:N0B"},{"type":"alerts","filter":{"events":["Tornado Warning"]},"onError":"skip"}]}. Alert filters (all optional, AND-combined): `ids` (specific alerts), `events`, `severities`, `minSeverity` (Extreme>Severe>Moderate>Minor>Unknown). Single-site radar keys: the address is `nexrad_l3:{SITE}:{KEY}` where KEY is `N{tilt}{measurement}` and tilt 0 is the 0.5 degree sweep -- N0B reflectivity (dBZ, where and how heavy), N0G base velocity (knots toward/away from the radar), N0S storm-relative velocity (storm motion removed, so a couplet is rotation rather than translation -- prefer it for rotation questions), N0C correlation coefficient (0-1, debris and hail), N0X differential reflectivity (dB). Legacy codes (N0V, N0R, N0Q) are accepted as aliases. Not every site produces every key; when a render reports which keys a site has, retry with one of those. Optional `time` (unix seconds): closest frame. Forecast (HRRR/nowcast/NBM) honors future times; analysis (MRMS/NEXRAD/RTMA/GOES) clamps to latest past. Pass `time` for future-radar asks — do not claim that capability is missing. Product ids must be real viz-ca…

Input parameters:

- `height` (integer)
- `lat` (number): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `location` (string): Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
- `lon` (number): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).
- `opacity` (number): Weather layer opacity
- `product` (string): viz-catalog product_id or nexrad_l3:{SITE}:{KEY} (simple form)
- `scene` (object): Full scene document (composed form). When set, product/location/zoom are ignored.
- `time` (integer): Unix seconds; closest frame (default: latest). Forecasts honor future times.
- `width` (integer)
- `zoom` (number): Map zoom (simple form)

### `get_sounding_chart` (~265 tokens)

Get sounding chart

Render the nearest RAOB (radiosonde) sounding as a Skew-T log-P + hodograph chart image for visual analysis: temperature/dewpoint traces, wind barbs, height-banded hodograph, and a derived-indices table (CAPE/CIN, lifted index, PWAT, shear, LCL). Soundings launch at 00Z/12Z so data can be hours old. Use get_sounding for the raw profile numbers. Example: {"location": "Norman, OK"}.

Input parameters:

- `lat` (number): Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
- `location` (string): Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
- `lon` (number): Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).
- `scale` (number): Raster scale factor (2 = retina; higher = larger image payload)
- `unit` (string): Temperature axis display unit

### `get_platform_status` (~150 tokens)

Get platform status

Current data-freshness status of the weather platform: overall state, per-source states (ok / degraded / outage / no_signal), open incidents with cause attribution (provider outage vs internal processing delay), and active provider advisories. Use this when a user asks whether data is current, when other tools return surprisingly stale data, or before presenting time-critical weather. If a source is degraded or in outage, tell the user their data may be stale rather than presenting it as live. No inputs. Refreshed about every 5 minutes.

Input parameters:

- `include_ok` (boolean): true: list every monitored source including healthy ones. false (default): only sources that are not ok, keeping the response compact.

Output parameters:

- `advisories` (array)
- `generated_at` (string): When the status document was generated (UTC).
- `note` (string)
- `overall` (string): Worst state across customer-facing data sources; "unknown" when status is unavailable.
- `sources` (array)

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/smarterweather-weather/mcp-2#diagnostics

## Score history

- 2026-09-21: 84
- 2026-09-20: 84
- 2026-09-19: 83
- 2026-09-18: 83
- 2026-09-17: 82
- 2026-09-16: 82
- 2026-09-15: 82
- 2026-09-14: 81
- 2026-09-13: 81
- 2026-09-12: 80
- 2026-09-11: 80
- 2026-09-10: 79
- 2026-09-09: 79
- 2026-09-08: 78
- 2026-09-07: 78
- 2026-09-06: 77
- 2026-09-05: 77
- 2026-09-04: 76
- 2026-09-03: 76
- 2026-09-02: 75
- 2026-09-01: 75
- 2026-08-31: 75
- 2026-08-30: 74
- 2026-08-29: 74
- 2026-08-28: 73
- 2026-08-27: 73
- 2026-08-26: 72
- 2026-08-25: 70
- 2026-08-24: 70

## Common questions

### What is the Smarter Weather MCP server?

Smarter Weather is an MCP server listed in the public MCP registry as io.github.smarterweather/weather. Smarter Weather MCP: forecasts, alerts, outlooks, observations, AQI, grids, and map imagery. This page covers its hosted endpoint (https://mcp.smarterweather.com).

### Is the Smarter Weather MCP server safe to use?

Smarter Weather scores 84 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Smarter Weather MCP server expose?

Smarter Weather exposes 33 tools: get_forecast, get_hourly_forecast, search_locations, reverse_geocode, get_alerts, and 28 more. Their descriptions and schemas cost roughly 11,630 tokens of context every time the server is loaded.

### Does the Smarter Weather MCP server require authentication?

No. We connected to Smarter Weather without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

### Is the Smarter Weather MCP server still maintained?

Smarter Weather is still listed as active in the MCP registry. We last reached this channel on 21 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://mcp.smarterweather.com/
- Repository: https://github.com/smarterweather/developer
- Website: https://smarterweather.com/developers
- Changelog RSS feed: https://verifymcp.io/servers/smarterweather-weather/mcp-2.xml
- Changelog JSON feed: https://verifymcp.io/servers/smarterweather-weather/mcp-2.json
- HTML version of this page: https://verifymcp.io/servers/smarterweather-weather/mcp-2