Skip to main content
Glama
Sign In

TrueFixR Storm Data API

by io.github.truefixr
OverviewDiscussionsAdmin

ML Storm Forecast by Address

get_risk_forecast
Read-only

COUNTY LEVEL, FREE, FUTURE (next 24 hours to 10 days). ML Storm Forecast by Address. Use when the question is which storms could affect a county soon: counts of addresses in the forecast path, the storm types forecast and the estimated cost (the county's A-F grade is shown as a secondary label). Input is state plus county. Per-peril machine-learning models, refreshed 4 times a day. Could happen, not will. Not for past storms (use get_storm_history, get_address_report or get_property_storm_history_report) and not for current weather (use get_current_weather). The paid pull (addresses=true, $0.05 per address) returns one record per address with structure_value (USD replacement cost), people (estimated occupants), full_address, lat, lon, county, storm_type, forecast_time and risk_label. For the paid pull, call get_weather_data with dataset=risk and addresses=true (needs an Atlas United Data API key or an x402 payment).

Input Schema

NameRequiredDescriptionDefault
perilNoNarrows the forecast to one storm type -- check a free preview's storm_types for real values available in this window.
stateYes2-letter US state code, e.g. TX.
countyYesCounty name without the word 'County', e.g. Dallas.
windowNoForecast window. Default 24h.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / window / enum
      Previous value: -[
-  "24h",
-  "48h",
-  "3d",
-  "5d",
-  "7d",
-  "10d",
-  "16d"
-]New value: +[
+  "24h",
+  "48h",
+  "3d",
+  "5d",
+  "7d",
+  "10d"
+]
  2. Changed2 schema fields changed
    • addedInput schema / properties / peril
      Added value: +{
+  "description": "Narrows the forecast to one storm type -- check a free preview's storm_types for real values available in this window.",
+  "type": "string"
+}
    • addedInput schema / properties / window
      Added value: +{
+  "description": "Forecast window. Default 24h.",
+  "enum": [
+    "24h",
+    "48h",
+    "3d",
+    "5d",
+    "7d",
+    "10d",
+    "16d"
+  ],
+  "type": "string"
+}
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only cover readOnly/openWorld, so the description carries real burden and delivers: free county-level tier vs $0.05-per-address paid pull, refresh cadence (4x/day), probabilistic semantics ('could happen, not will'), returned fields for the paid record, and auth requirements (Atlas United Data API key or x402).

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 a scannable all-caps qualifier block, then usage, then routing, then paid-tier detail. Dense but mostly earning its place; the paid-pull mechanics paragraph leans toward documenting a different tool and adds length.

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 no output schema, the description compensates by describing what the forecast reports (address counts, forecast storm types, estimated cost, county grade) and the paid record shape. For a county-scoped forecast tool, an agent has everything it needs to call correctly.

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 four parameters are already documented, including the peril enum hint and window values. The description adds 'input is state plus county,' which restates the required set, and references the free preview's storm_types, which is already in the peril schema description. Baseline 3 is appropriate.

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?

States a specific resource and scope: county-level storm risk forecast from ML per-peril models, next 24h to 10d. It immediately differentiates itself from siblings by naming what it is not (past storms, current weather). An agent can identify it without opening the schema.

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 ('which storms could affect a county soon') and explicit exclusions routing to get_storm_history, get_address_report, get_property_storm_history_report for past storms and get_current_weather for current conditions. It also clarifies when to escalate to the paid path via get_weather_data.

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

All TrueFixR Storm Data API 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