Smarter Weather

Observed precipitation

get_observed_precipitation

Read-onlyIdempotent

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. For forecast totals beyond the next hour use get_period_totals; for station reports use get_observations.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`at`	No	RFC3339 end time within the last 33 h. Default: latest.
`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).
`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
`windows`	No	Accumulation windows ending at the latest frame (or at `at`).
`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.
`include_nowcast`	No	Next-hour radar nowcast (CONUS; ignored with `at`).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`as_of`	No
`notes`	No
`units`	Yes
`derived`	Yes
`nowcast`	No
`windows`	Yes
`_sources`	Yes
`location`	Yes
`data_status`	No
`quantization_step`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial operational context beyond them: data source (MRMS QPE Pass2), coverage limits (CONUS; 1 h only in AK/HI), ~2 mm resolution with the meaning of zero, ~1 h data latency, and the 33 h `at` limit.

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

Conciseness4/5

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

Front-loaded with the plain-language purpose before any caveats, and each sentence carries distinct information (source, windows, resolution, latency, `at` behavior, nowcast, alternatives). It is dense and slightly long, but no sentence is redundant.

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?

An output schema exists, so return values need not be described, and the remaining gaps an agent would care about - spatial/temporal coverage, data latency, measurement resolution, and where to go for adjacent needs - are all addressed.

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, but the description earns extra by explaining semantics the schema cannot: that `at` selects totals ending at a past time with the newest frame up to 3 h before it, and that include_nowcast returns intensity/type/start time rather than an amount.

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?

Opening clause states a concrete verb+resource ('observed precipitation totals at a location') and immediately frames it with example questions. It distinguishes itself from named siblings get_period_totals (forecast) and get_observations (station reports) within the same description.

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?

Explicit when-to-use hedges ('did it rain', 'how much rain fell', 'rain in the last 24 hours') plus explicit routing to alternatives for the adjacent cases. An agent can pick this tool over the 30+ siblings without reading any schema.

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.