Mmcp.market

Smarter Weather MCP server

by smarterweather·io.github.smarterweather/weather·v0.0.1

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

A90/100grade A
What users say
No reviews yet
Be the first
Safety scan
A90/100

full report

Adoption
Growing

1 stars42 downloads/wk

Reviews

Write one

Nobody has reviewed Smarter Weather yet.

If you have run it, two minutes of your experience saves the next person an afternoon.

Smarter Weather tools (33)

write = sends, deletes, buys or posts
  • compare_locationsFree

    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}.

  • describe_datasetFree

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

  • find_best_windowFree

    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}.

  • get_air_qualityFree

    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}.

  • get_alertsFree

    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"]}.

  • get_climate_normalsFree

    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.

  • get_climate_recordsFree

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

  • get_current_conditionsFree

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

  • get_forecastFree

    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}.

  • get_forecast_discussionFree

    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}.

  • get_forecast_distributionFree

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

  • get_forecast_skillFree

    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:DJF (winter), SCN1:WINDY / SCN1:WET / SCN1:QUIET (what the forecast was showing), or JC1:NW (a circulation pattern). Pass the regime parameter to ask for a conditioned track record. It falls back, so asking for SCN1:WINDY and getting back regime ALL is a successful answer, not a missing one -- always read the regime field and qualify the claim with it, because "NBM runs warm here when it shows windy" and "NBM runs warm here" are different statements. Regimes overlap by construction across families, so entries under different regimes are alternative answers to one question and must never be compared or added; within SCN1: the labels are mutually exclusive. Entries with a categorical block answer a yes/no question instead of an error magnitude -- did it rain, at the thresholdMm stated on the entry -- with pod (of the times it happened, how often we called it), far (of the times we called it, how often it did not happen), and frequencyBias (above 1 = we call it too often). Use these for "will it actually rain" questions, where a small average error means nothing if the rain lands in the wrong hour. A null rate means the sample cannot answer it -- the event has not happened, or been forecast, enough times to divide by -- and must be reported as unknown, never as zero. The counts beside it are still evidence, and for a rare event they are often the whole answer: "it has only rained twice here in the record" is a useful thing to say.

  • get_forecast_skill_mapFree

    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.

  • get_growing_degree_daysFree

    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?".

  • get_hourly_forecastFree

    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}.

  • get_lightning_activityFree

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

  • get_map_snapshotFree

    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-catalog entries -- shorthand like "radar" or "reflectivity" is not one. Omit `product` for the default hybrid precip still. For Alaska and Hawaii prefer a local site or `mrms_precip_hybrid_derived_alaska` over CONUS mosaics, which do not cover them. Returns the rendered image plus per-layer resolved valid times.

  • get_observationsFree

    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}.

  • get_outlooksFree

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

  • get_path_exposureFree

    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"]}.

  • get_period_totalsFree

    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"}]}.

  • get_platform_statusFree

    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.

  • get_population_exposureFree

    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}.

  • get_soundingFree

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

  • get_sounding_chartFree

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

  • get_storm_cellsFree

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

  • get_storm_reportsFree

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

  • get_time_contextFree

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

  • get_tropicalFree

    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}.

  • list_datasetsFree

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

  • query_datasetFree

    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}.

  • reverse_geocodeFree

    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.

  • search_locationsFree

    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.

Public scan report

scanner v0.1.9 · 2026-09-21 · same rubric, same numbers if you re-run it

1 low
  • Code scan5 source files scanned25/25
  • Live reliabilityremote reachable in 1018ms20/20
  • Tool poisoning33 tool descriptions checked13/15
  • Auth qualityopen endpoint, read-only tools10/15
  • Maintenancelast push 3 days ago15/15
  • Maintainer identityregistry namespace matches repository owner7/10

Findings (1)

  • lowUnusually long tool description (over 2,000 characters)poison.long-description
    tool 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:DJF (winter), SCN1:WINDY / SCN1:WET / SCN1:QUIET (what the forecast was showing), or JC1:NW (a circulation pattern). Pass the regime parameter to ask for a conditioned track record. It falls back, so asking for SCN1:WINDY and getting back regime ALL is a successful answer, not a missing one -- always read the regime field and qualify the claim with it, because "NBM runs warm here when it shows windy" and "NBM runs warm here" are different statements. Regimes overlap by construction across families, so entries under different regimes are alternative answers to one question and must never be compared or added; within SCN1: the labels are mutually exclusive. Entries with a categorical block answer a yes/no question instead of an error magnitude -- did it rain, at the thresholdMm stated on the entry -- with pod (of the times it happened, how often we called it), far (of the times we called it, how often it did not happen), and frequencyBias (above 1 = we call it too often). Use these for "will it actually rain" questions, where a small average error means nothing if the rain lands in the wrong hour. A null rate means the sample cannot answer it -- the event has not happened, or been forecast, enough times to divide by -- and must be reported as unknown, never as zero. The counts beside it are still evidence, and for a rare event they are often the whole answer: "it has only rained twice here in the record" is a useful thing to say.…
Overall 90/100. Components that don't apply are left out of the denominator. Any critical finding is an F.RubricAppeal a findingJSON

What the publisher says

From the Smarter Weather repository's README, as published. We do not edit it. Read it on GitHub

Smarter Weather Developer Platform

The public home for the Smarter Weather developer platform: SDKs, documentation, example apps, the @smarterweather/mcp-weather and @smarterweather/mcp-onboarding packages, agent skills, and the OpenAPI specification for api.smarterweather.com.

Generally available. The REST API, both hosted MCP servers, and both npm

stdio bridges are live in production. Breaking-change policy: six months'

notice before removing a /v1/* endpoint or an MCP tool, 90 days before a

breaking change to a request or response shape. Non-breaking additions ship

immediately.

What lives here

https://api.smarterweather.com. Auto-synced from the canonical source on change. Also served at .

  • OpenAPI specification (openapi.yaml) for the public REST API at

catalog for the weather MCP server, synced on every server change.

  • MCP tool descriptors (descriptors/mcp-tools.json) -- the canonical

bridge that connects MCP clients (Cursor, Claude Desktop, Claude Code, etc.) to the hosted MCP endpoint at https://mcp.smarterweather.com. The bridge attaches your API key from SMARTERWEATHERAPIKEY and proxies every JSON-RPC message; all weather logic runs server-side.

  • @smarterweather/mcp-weather -- npm package source for the stdio

bridge to the developer-onboarding MCP server at https://mcp.developers.smarterweather.com. Provides agent-driven self-service account creation, API key provisioning, and SDK setup walkthroughs. Auth via OAuth (browser callback).

  • @smarterweather/mcp-onboarding -- npm package source for the stdio

shipped; call the REST API directly in the meantime.

  • Client SDKs -- TypeScript and Python first; Go to follow. Not yet

end-to-end recipes.

  • Examples and cookbooks -- runnable apps, agent integrations, and

is the long-lived Agent Plugins 1.0 package (weather MCP + playbooks). plugins/smarterweather-onboarding/ is the one-shot signup / key-mint install; remove it after configure_mcp. Never put both servers in one mcp.json. Cursor Marketplace discovery uses .cursor-plugin/marketplace.json. .cursor/skills/use-smarterweather-api/ is a pointer at the weather skills; .claude/CLAUDE.md remains a follow-up refresh.

  • Agent Plugins -- plugins/smarterweather/

developer portal at https://developers.smarterweather.com. See the docs index for the current map.

  • Documentation -- guides under docs/ that complement the

What does not live here: the Smarter Weather core service, ingestion pipeline, or any internal infrastructure. Those remain in a separate private repository.

Quickstart

The hosted developer portal at https://developers.smarterweather.com is the source of truth for account creation, API key minting, plan management, and usage. Agents can do all of it without the dashboard by connecting to the onboarding MCP server — see docs/mcp-onboarding.md.

Once you have a key:

# REST API
curl -H "Authorization: Bearer $SMARTERWEATHER_API_KEY" \
  "https://api.smarterweather.com/v1/weather?lat=41.88&lon=-87.63"
# Weather MCP bridge (defaults to https://mcp.smarterweather.com;

Shortened. The full README is on GitHub.

Nothing above is checked by us. What we check is on the safety report.

Install directly

claude mcp add --transport http weather https://mcp.smarterweather.com
Add to Cursor

Smarter Weather: common questions

Is Smarter Weather MCP server safe?
Yes, by our scan: it is graded A (90/100). Read the Smarter Weather safety report
How do I install Smarter Weather?
It runs remotely at mcp.smarterweather.com. Add it to Claude Code, Claude Desktop or Cursor with the snippets above, or call it through the mcp.market gateway without installing anything.
Does Smarter Weather need an API key?
Yes. The registry entry asks for SMARTERWEATHER_API_KEY.
Is Smarter Weather maintained?
The last commit was 3 days ago (2026-09-18). The latest release is v0.0.1.
Is Smarter Weather up?
100% of our last 8 checks got an answer. We check remote servers about four times a day.
What can I use instead of Smarter Weather?
Servers from other publishers that do the same job: Weather Data MCP Server, Noaa Spaceweather MCP server and Weather & Geo Intel MCP server. Compare all Smarter Weather alternatives.

Alternatives to Smarter Weather

Same job from other publishers: the closest match first, then the best rated.

All Smarter Weather alternatives →
  • Weather Data MCP Server
    17 weather tools, no API keys: forecasts, alerts, air quality, marine, radar, lightning, wildfires
    A
  • Noaa Spaceweather
    NOAA SWPC space weather: storm scales, Kp index, aurora forecasts, solar wind, activity, alerts.
    A
  • Weather & Geo Intel MCP
    US weather & geo for AI agents: forecasts, alerts, earthquakes, elevation, geocoding. No keys.
    A
  • Xweather Weather MCP
    Hosted MCP server for Xweather weather data: conditions, forecasts, alerts, and more.
    B
  • Open-Meteo Weather
    Current weather and hourly forecasts for any place name, via the free Open-Meteo API. No API key.
    A

More from smarterweather