# Smarter Weather Developer Onboarding [Health: Active]

**Category:** 🌳 Environment & Nature  
**Repository:** https://github.com/smarterweather/developer  
**GitHub Stars:** 1  
**npm Downloads (last month):** 209  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/smarter-weather-developer-onboarding

## Description
Agent-first onboarding to Smarter Weather: plans, docs, signup, API keys, MCP config, billing.

## Tools
Capabilities this server exposes over MCP:

- **find_places** — Find places: a name, ZIP, venue or address to ranked candidates with lat/lon, or coordinates to the place and timezone. Pass `query` (fuzzy=true for partial input) or `lat`+`lon`; rows carry `type` place|zip|address|poi, `matched_via: "autosuggest"` marks fallback rows and `partial` a timed-out section. Weather tools take `location`; use this to disambiguate or name a point. Example: {"lat": 39.74, "lon": -104.99} -> Denver, Colorado, America/Denver.
- **get_forecast** — Forecast for a US place: current conditions, daily forecast with sunrise and sunset, active alerts and outlooks in one call, and hour by hour with include=hourly. Blended across NBM, HRRR, GFS, RTMA and SPC and unit-converted server-side; times are UTC ISO 8601, quote daily[].astro.local as local, and if forecast.location.timezone_resolved is false state times as UTC. For hours set `hours` (next N, default 48) or `start`+`end` for one stretch hour by hour, and check hourly_coverage (first_time, last_time, sample_interval_hours, truncated) before answering about a specific hour; past last_time say the forecast does not reach that far. Example: {"location": "Portland, OR", "include": "hourly", "hours": 24}.
- **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. Analysis fields: temperature_2m, dew_point_2m, relative_humidity_2m (derived here from temperature and dew point; listed in analysis.derived), wind_speed_10m, wind_direction_10m, wind_gusts_10m, surface_pressure (station pressure at ground level, not sea-level pressure), visibility, cloud_cover, cloud_ceiling, in units (labels in analysis.unit_labels). nearest_station is the station's own report, unconverted. For a forecast, use get_forecast. Example: {"location": "Pella, IA"}.
- **get_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"]}.
- **get_observed_precipitation** — How much rain fell: observed precipitation totals at a location. Use for "did it rain", "how much rain fell", "rain in the last 24 hours / since yesterday". Source: MRMS MultiSensor QPE Pass2 (radar bias-corrected to rain gauges) over 1/3/6/24/48/72 h windows (CONUS; 1 h only in Alaska and Hawaii). Values have about 2 mm (0.08 in) resolution, so 0 means under about 1 mm; data runs about an hour behind real time. Pass `at` (within 33 h) for totals ending at a past time (newest frame up to 3 h before it). With include_nowcast (default) it also returns a next-hour radar nowcast (CONUS): peak intensity (light/moderate/heavy), type and start time, not an amount. Forecast totals past the next hour: get_data (catalog); station reports: get_observations (observed).
- **get_forecast_distribution** — NBM probabilistic guidance for one weather aspect: percentiles (p10-p90), exceedance probabilities and ensemble spread. Use this for any question about odds, ranges, potential or confidence ("how much could we get", "range of possible highs", "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 when the risk is the low end (cold, 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, snow-type probability), ice (ice accretion, freezing-rain / ice-pellet probabilities), temperature (`daily` high/low p10/p50/p90: the NBM value -/+ 1.28 stddev; hourly temp + stddev), wind (speed/gust percentiles), severe (thunderstorm probability plus NBM CWASP, a severe-environment index, both in percent: severe_weather_prob_p50 is the median CWASP value and severe_weather_prob_above_75 the probability CWASP exceeds 75; NBM has no tornado, hail or damaging-wind odds; SPC's: get_outlooks (guidance) hazard=severe), aviation (LIFR/IFR/MVFR visibility + ceiling odds), confidence (ensemble stddev; low = settled, high = details still in play). Labels in unit_labels. Example: {"location": "Denver, CO", "aspect": "snow", "hours": 72}.
- **search_data** — Search the data catalog: which dataset's values answer a weather question, or what data exists at a point. With `query` it ranks grids, radar, satellite, outlooks and observations and returns hits with variable, units, cadence, why, the exact `call` to run next and any verified `example`; without it, it lists datasets at the place with freshness, or every public one. A place (`location` or lat/lon) or `domain` keeps datasets covering it; variables come from describe_data. Example: {"location": "Anchorage, AK"}.
- **find_tools** — Lists the weather tools this connection does not show (best times, routes, air quality; station observations, soundings, hurricane recon; lightning, storm cells, storm reports; outlooks, forecaster text, hurricanes; climate records and normals; forecast accuracy; maps and charts; crop heat units), with when to use each and its required arguments. Run one with call_tool, in this session, no reconnect. With `tools`, returns their full input schemas. Free; no network call.
- **call_tool** — Runs a tool find_tools lists, by name: same price, limits and result as calling it directly. Tools already in your list are called directly, not through this. `arguments` follows that tool's input schema.
- **describe_data** — A dataset's variables or properties (standard names, units, categories, bands, aggregates), horizon, step, cadence, freshness, cost class, verified `examples` and an example_query to read its values. Free; call it after search_data, before get_data. Example: {"dataset_id": "<from search_data>"}.
- **get_data** — Values, totals, comparisons, people and POI counts from any catalog dataset (models, radar, alerts, outlooks, reference layers) at a place or several, over a bbox or area, or as items. `select` takes `product:variable` or `product:property` tokens, a standard name or a concept such as `population`; send one space word (an `area` reference is `{product, feature_id}`) and at most one time word (hours, start+end or at; run pins a cycle); `stats` reduces per `step` or over the area; omit units for SI. Example: {"select": ["nbm_conus:temperature_2m"], "location": "Denver, CO", "hours": 24}.
- **get_status** — Data freshness of the weather platform (no inputs needed; refreshed about every 5 minutes): overall state, per-source states (ok / degraded / outage / no_signal), open incidents with their cause (provider outage vs internal processing delay) and active provider advisories. Use it when asked whether data is current, when other tools return stale-looking data, or before presenting time-critical weather. If a source is degraded or in outage, say the data may be stale rather than presenting it as live. Example: {}.
- **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?". If current_time.timezone_resolved is false, zone unknown: state times as UTC, never as local. Accepts a place name directly. Example: {"location": "Seattle, WA"}.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "smarter-weather-developer-onboarding": {
    "command": "npx",
    "args": ["-y","@smarterweather/mcp-weather"]
  }
}
```

## Documentation

## What Smarter Weather Developer Onboarding MCP server does

Smarter Weather Developer Onboarding MCP server provides an agent-oriented entry point to the Smarter Weather developer platform. It covers the steps that typically precede API use: learning about available plans and documentation, creating an account, obtaining an API key, configuring MCP access, and understanding billing. The repository publishes the onboarding MCP package, hosted service details, documentation, examples, and related agent plugins.

The hosted service is separate from the weather MCP server. The onboarding endpoint is `https://mcp.developers.smarterweather.com`, while weather tools are hosted at `https://mcp.smarterweather.com`. Keeping these services separate lets an agent complete account setup before using weather capabilities.

## How it works

The hosted onboarding MCP server exposes discovery tools without requiring authentication. Account-related actions use OAuth, with browser-based authorization described for the onboarding package. This allows an agent to discover the platform first and then obtain authorization when it needs to create or manage developer access.

The repository also contains `@smarterweather/mcp-onboarding`, an npm stdio bridge that connects an MCP client to the hosted onboarding service. Its account flow uses an OAuth browser callback. The repository describes the hosted MCP servers and npm bridges as live in production.

A documented onboarding flow can lead an agent through account creation, API key provisioning, and MCP configuration. The `configure_mcp` step is specifically referenced in the agent-plugin guidance. After that step, the one-shot onboarding plugin should be removed from a long-lived configuration so its account tools are not retained unnecessarily.

## Setup and configuration

The hosted service does not require local installation for an MCP client that can connect to a remote MCP endpoint. For local-client use, the repository publishes the `@smarterweather/mcp-onboarding` stdio bridge.

Agents can also begin without MCP by calling the REST API at `https://api.smarterweather.com/v1/weather` without a key. The resulting `401` response includes a `next_steps` member describing where to obtain a key and how to use it. Once provisioned, API requests use a bearer token such as `sw_live_*` or `sw_test_*`.

The developer portal remains the source of truth for account creation, key minting, plan management, and usage. The onboarding MCP server offers an agent-driven alternative for those account tasks.

## Tools and capabilities

Smarter Weather Developer Onboarding MCP server supports the following documented areas:

- Discover Smarter Weather plans and developer documentation.
- Create a developer account through agent-guided self-service.
- Provision an API key.
- Walk through SDK setup.
- Configure MCP access with `configure_mcp`.
- Surface onboarding, plan, and billing guidance.

The repository also includes a separate weather MCP package and REST API materials, but those are not onboarding tools. The weather bridge proxies JSON-RPC messages to the weather MCP endpoint and uses `SMARTERWEATHER_API_KEY`; that variable belongs to the weather bridge rather than the onboarding service.

## Limitations and notes

The repository contains client-side and documentation artifacts, not the Smarter Weather core service or internal infrastructure. SDKs are described as planned or in progress in the roadmap, so agents may need to call the REST API directly where an SDK is unavailable.

OAuth is required for account tools, and the account flow involves a browser callback. The repository does not state that onboarding account actions are anonymous. Hosted APIs and services are governed by separate Smarter Weather terms, and access requires the applicable agreement.

The code and package sources use the MIT License, while documentation and prose use CC BY 4.0. The onboarding plugin is intended as a one-shot signup and key-minting component; remove it after `configure_mcp` when maintaining a persistent MCP configuration.

_Full upstream README: https://allmcps.com/mcp/smarter-weather-developer-onboarding/readme_