Smarter Weather

Get forecast

get_forecast

Read-onlyIdempotent

Complete weather overview for a location: current conditions, daily forecast (SPC threats, severity; view "detailed" adds CAPE, UV, full day/night periods), active alerts, and outlooks in one call. Pre-aggregated across NBM, HRRR, GFS, RTMA, and SPC and unit-converted server-side. Primary weather tool; reach for lower-level tools only when you need raw observations or a specific dataset. Times are UTC ISO 8601; quote daily[].astro.local to users, not UTC. If forecast.location.timezone_resolved is false, zone unknown: state times as UTC, never as local. Accepts a place name directly. Examples: {"location": "Denver, CO"} or {"location": "Portland, OR", "days": 5} or {"lat": 41.4, "lon": -92.9}.

Input Schema

Name	Required	Description	Default
`lat`	No	Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
`lon`	No	Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).
`days`	No	Number of forecast days (1-14). Default 10.
`view`	No	concise (default; REST's is detailed), ~5-10KB: daily has day_precip_probability / night_precip_probability (precip_probability is their max). detailed, ~12-20KB: adds CAPE, UV, full day/night periods, extra hourly fields.
`units`	No	Units of every value in and out: imperial (default; °F, mph, in) or metric (°C, km/h, mm). si is deprecated and will be removed; use metric.	imperial
`include`	No	Comma-separated sections: current, daily, hourly, alerts, outlooks. Default "current,daily,alerts,outlooks". Use get_hourly_forecast for hourly detail.	current,daily,alerts,outlooks
`location`	No	Free-text place: "City, ST" (e.g. "Portland, OR"), US ZIP, venue/address where enabled, or "lat,lon". Use this OR lat+lon, not both.
`detail_level`	No	Deprecated alias of view.

Output Schema

Name	Required	Description
`units`	Yes
`widget`	No	sw-ui-spec widget block rendered by the MCP Apps weather widget (ui://weather-widget/v1/index.html). Additive; safe to ignore.
`_sources`	No	Per-source provenance: what produced these values and when.
`forecast`	Yes
`location`	Yes
`data_status`	No	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 get_platform_status for the full document.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 24, 2026

addedOutput schema / properties / _sources

Added value: +{
+  "description": "Per-source provenance: what produced these values and when.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "dataset_id": {
+        "type": "string"
+      },
+      "dataset_ids": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "issued_at": {
+        "type": "string"
+      },
+      "label": {
+        "type": "string"
+      },
+      "method": {
+        "type": "string"
+      },
+      "office": {
+        "type": "string"
+      },
+      "product": {
+        "type": "string"
+      },
+      "provider": {
+        "type": "string"
+      },
+      "time_zone": {
+        "type": "string"
+      },
+      "type": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "type",
+      "provider",
+      "label"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Changed2 schema fields changedOct 22, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

removedOutput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

Changed4 schema fields changedOct 22, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedOutput schema / properties / data_status / properties
```
Added value: +{}
```
- addedOutput schema / properties / forecast / properties
```
Added value: +{}
```
- addedOutput schema / properties / widget / properties / entries / items / properties / props / properties
```
Added value: +{}
```

Changed2 schema fields changedOct 16, 2026

changedInput schema / properties / location / description

Previous value: -"Free-text place: city (\"Denver\"), city+state (\"Portland, OR\"), US ZIP, venue/address where enabled, or \"lat,lon\". Use this OR lat+lon, not both."New value: +"Free-text place: \"City, ST\" (e.g. \"Portland, OR\"), US ZIP, venue/address where enabled, or \"lat,lon\". Use this OR lat+lon, not both."

changedInput schema / properties / units / description

Previous value: -"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."New value: +"Units of every value in and out: imperial (default; °F, mph, in) or metric (°C, km/h, mm). si is deprecated and will be removed; use metric."

Changed3 schema fields changedOct 15, 2026

removedInput schema / properties / detail_level / default
```
Removed value: -"standard"
```

changedInput schema / properties / detail_level / description

Previous value: -"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 day/night period objects, extra hourly fields (~12-20KB)."New value: +"Deprecated alias of view."

addedInput schema / properties / view

Added value: +{
+  "description": "concise (default; REST's is detailed), ~5-10KB: daily has day_precip_probability / night_precip_probability (precip_probability is their max). detailed, ~12-20KB: adds CAPE, UV, full day/night periods, extra hourly fields.",
+  "enum": [
+    "concise",
+    "detailed"
+  ],
+  "type": "string"
+}

Changed2 schema fields changedOct 14, 2026

changedInput schema / properties / location / description

Previous value: -"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."New value: +"Free-text place: city (\"Denver\"), city+state (\"Portland, OR\"), US ZIP, venue/address where enabled, or \"lat,lon\". Use this OR lat+lon, not both."

addedOutput schema / properties / location / properties / matched_via

Added value: +{
+  "enum": [
+    "autosuggest",
+    "fuzzy"
+  ],
+  "type": "string"
+}

Changed1 schema field changedJul 21, 2026

changedInput schema / properties / detail_level / description

Previous value: -"standard: compact response (~5-10KB). detailed: preserves CAPE, UV, day/night periods, extra hourly fields (~12-20KB)."New value: +"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 day/night period objects, extra hourly fields (~12-20KB)."

Changed1 schema field changedJul 15, 2026

addedOutput schema / properties / data_status

Added value: +{
+  "additionalProperties": {},
+  "description": "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 get_platform_status for the full document.",
+  "type": "object"
+}

First observedJul 14, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations (which only declare read-only/idempotent/open-world) by disclosing server-side aggregation across NBM, HRRR, GFS, RTMA and SPC, server-side unit conversion, approximate payload sizes for each view (~5-10KB vs ~12-20KB), and the UTC-ISO-8601/timezone_resolved caveat with an explicit instruction never to present UTC as local when the zone is unresolved.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose and contents, then usage routing, then output-timing caveats, then examples. Dense but every sentence carries operational value and nothing is repeated from the schema verbatim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present it correctly avoids explaining return shapes, focusing instead on section selection, payload-size tradeoffs, aggregation provenance, and the timezone presentation rule. An agent has everything needed to invoke it correctly on the first try.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds practical guidance by showing accepted input shapes (place name directly, lat/lon pair) and clarifying that view='detailed' expands CAPE, UV and full day/night periods. The semantic link between units and all returned values is also stated, though most parameter detail still lives in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource and then enumerates exactly what the single call returns: current conditions, daily forecast with SPC threats, alerts, and outlooks. It also self-identifies as the 'Primary weather tool,' which clearly separates it from the lower-level sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states when to use it (default/primary overview) and when not to ('reach for lower-level tools only when you need raw observations or a specific dataset'), and gives three concrete invocation examples. It never names the specific alternatives (get_current_conditions, get_alerts, get_hourly_forecast) that an agent sees in the tool list, leaving the routing decision partly inferential.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Smarter Weather tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.