Skip to main content
Glama

Smarter Weather

by io.github.smarterweather
OverviewDiscussionsAdmin

Get storm cells

get_storm_cells
Read-onlyIdempotent

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNoLatitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
lonNoLongitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).
includeNoWhich detection families to include. Default: all.
locationNoFree-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.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
tracksNo
summaryYesReady-to-use one-liner. States explicitly when nothing was detected.
locationYes
detectionsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / summary
      Added value: +{
+  "description": "Ready-to-use one-liner. States explicitly when nothing was detected.",
+  "type": "string"
+}
    • changedOutput schema / required
      Previous value: -[
-  "location",
-  "detections"
-]New value: +[
+  "location",
+  "summary",
+  "detections"
+]
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses that output is merged from the nearest NEXRAD site and that empty results are normal outside storms. This prevents misinterpretation and adds real behavioral context.

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?

Three sentences, each earning its place: result contents, usage condition, and empty-result interpretation. The product list is formatted with clear parenthetical details and the example is inline rather than an extra paragraph.

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, the description doesn't need to restate return fields. It covers what the tool does, when to use it, and how to read an empty response, leaving no essential gap for an agent invoking it.

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

Parameters3/5

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

Schema coverage is 100%, so the baseline applies. The description's mention of product families mirrors the `include` enum and adds an example, but it doesn't materially extend the parameter explanations already present 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?

The description names a specific resource (radar-identified storm cells) and enumerates the algorithm outputs it returns (storm tracks, hail index, mesocyclone detections, TVS). This clearly distinguishes it from weather siblings like get_storm_reports.

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?

The description gives an explicit use condition ('Use during active convection') and explains what an empty result means, which is essential for interpreting the tool. It doesn't name alternatives or exclusion criteria, but the context is sufficient for an agent to decide when to call it.

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

All Smarter Weather toolsInspect
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.

Resources