Smarter Weather

Get forecast

get_forecast

Read-onlyIdempotent

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 Schema

TableJSON 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.
`units`	No	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.	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 ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
`detail_level`	No	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).	standard

Output Schema

TableJSON 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.
`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 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

Behavior4/5

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

Annotations already establish read-only, non-destructive, idempotent behavior. The description adds useful behavioral context by explaining data is pre-aggregated across NBM, HRRR, GFS, RTMA, and SPC and unit-converted server-side. Minor flaw: listing CAPE and UV as part of the daily forecast slightly overstates what the default standard detail_level may include.

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?

The description front-loads the core purpose, then adds behavioral context, routing guidance, and examples in a compact format. Every sentence contributes meaning; the JSON examples are especially efficient for showing valid parameter combinations.

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?

Given the rich output schema, 100% parameter coverage, and helpful annotations, the description fully covers what the tool does, when to use it, and how to call it. It also provides enough sibling differentiation to guide tool selection.

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 description coverage is 100%, so the schema already documents all seven parameters. The description adds value with concrete usage examples, clarification that location accepts a place name directly, and the note about server-side unit conversion.

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?

The description names a specific verb and resource: it returns a complete weather overview for a location, explicitly listing current conditions, daily forecast, alerts, and outlooks. It also distinguishes itself as the primary weather tool, separating it from lower-level siblings like get_current_conditions and get_alerts.

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

Usage Guidelines5/5

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

It explicitly positions itself as the default weather tool and tells agents to reach for lower-level tools only when raw observations or a specific dataset is needed. It also cross-references get_hourly_forecast for hourly detail, giving concrete routing guidance.

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.