Skip to main content
Glama

Smarter Weather

by io.github.smarterweather
OverviewDiscussionsAdmin

Get lightning activity

get_lightning_activity
Read-onlyIdempotent

Real-time lightning near a location: GLM satellite flash count (30km/10min) and MRMS ground-truth lightning density + 30-minute probability. The summary field is ready-to-use. A zero flash count means no lightning inside that window -- report it as a quiet observation scoped to the window in scope, never as a data gap. Only call when storms may be active or the user asks about lightning. Example: {"location": "Tampa"}.

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).
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
scopeYesArea and time window searched, so a zero count is unambiguous to report.
locationYes
lightningYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / scope
      Added value: +{
+  "description": "Area and time window searched, so a zero count is unambiguous to report.",
+  "type": "string"
+}
    • changedOutput schema / required
      Previous value: -[
-  "location",
-  "lightning"
-]New value: +[
+  "location",
+  "scope",
+  "lightning"
+]
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With annotations already providing readOnly, idempotent, and non-destructive hints, the description adds valuable interpretation context: a zero flash count means a quiet observation within the window, not a data gap, and the `summary` field is ready to use. It also explains the temporal/spatial window of the data, which is not in the annotations.

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 is tight and front-loaded, leading with the core function and data types before adding interpretive guidance and usage conditions. Every sentence earns its place, and the example is compact and useful.

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 rich annotations, a fully described input schema, and an output schema, the description covers the remaining context an agent needs: what the data represents, how to interpret zero values, the appropriate invocation window, and an example. Nothing critical is missing.

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?

The input schema already has 100% coverage with clear descriptions for lat, lon, and location. The description adds a practical example ({"location": "Tampa"}) and reinforces that the tool is location-oriented, helping agents choose between coordinate and place-name inputs, though it does not introduce deep semantic detail beyond 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?

Description clearly identifies the tool as retrieving real-time lightning activity near a location, with specific data sources (GLM satellite flash count, MRMS lightning density) and a 30-minute probability. It distinguishes itself from sibling weather-data tools by naming the exact resource and scope.

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?

States an explicit trigger condition: 'Only call when storms may be active or the user asks about lightning.' This tells an agent when the tool is appropriate, but it does not name alternative sibling tools for non-lightning weather queries, so it stops short of full alternatives 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 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