Skip to main content
Glama
Sign In

TrueFixR Storm Data API

by io.github.truefixr
OverviewDiscussionsAdmin

Model-Based Weather by Address (hourly forecast with hours_ahead)

get_current_weather
Read-only

ONE POINT, NOW TO 48 HOURS. Model-Based Weather by Address: point weather for any U.S. coordinate or street address, with current conditions, active severe weather alerts and a short-term rain outlook. Use for what the weather is or will be at a location; add hours_ahead=0-48 for Model-Based Hourly Forecast by Address. Not for storm history or storm-risk forecasts (use get_address_report, get_property_storm_history_report, get_storm_history or get_risk_forecast). FREE by default: the lean response needs no account. details=true returns the full pull, billed $0.0002 per call (not per address).

Input Schema

NameRequiredDescriptionDefault
latNoLatitude, alternative to address.
lonNoLongitude, alternative to address.
addressNoStreet address. Real server-side geocoding -- no separate geocoding step needed.
detailsNotrue = full pull, $0.0002/call, requires an API key or x402 payment. false (default) = free lean response.
x_paymentNoOptional signed x402 payment payload, used instead of an API key when details=true.
hours_aheadNoForecast 0-48h out instead of current conditions -- snaps to the nearest available forecast hour, response's forecast_hour_used says exactly what you got.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / details / description
      Previous value: -"true = full 164-field pull, $0.0002/call, requires an API key or x402 payment. false (default) = free 10-field lean response."New value: +"true = full pull, $0.0002/call, requires an API key or x402 payment. false (default) = free lean response."
    • changedInput schema / properties / hours_ahead / description
      Previous value: -"Real HRRR forecast 0-48h out instead of current conditions -- snaps to the nearest real available forecast hour, response's forecast_hour_used says exactly what you got."New value: +"Forecast 0-48h out instead of current conditions -- snaps to the nearest available forecast hour, response's forecast_hour_used says exactly what you got."
  2. Changed1 schema field changed
    • addedInput schema / properties / hours_ahead
      Added value: +{
+  "description": "Real HRRR forecast 0-48h out instead of current conditions -- snaps to the nearest real available forecast hour, response's forecast_hour_used says exactly what you got.",
+  "maximum": 48,
+  "minimum": 0,
+  "type": "integer"
+}
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds real behavioral context beyond them: the default call is FREE with no account required, details=true is billed $0.0002 per call (explicitly not per address) and requires an API key or x402 payment, and geocoding is server-side with no separate step. This is exactly the billing/auth/behavior surface annotations cannot express.

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 scope ('ONE POINT, NOW TO 48 HOURS') and then packed with routing, exclusion and pricing facts, all of which earn their place. Slight waste in restating the title text ('Model-Based Weather by Address') and a dense run-on final sentence, but no filler.

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 and six optional parameters, the description carries the full burden and does so: it covers what is returned (current conditions, alerts, rain outlook), the forecast mode, geographic limits, cost, and auth. Nothing an agent needs to invoke it correctly 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: the geographic scope is restricted to U.S. coordinates/addresses and the details flag is tied to cost and auth mode. It stops short of clarifying the exclusivity between address and lat/lon, leaving that to 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?

States a concrete verb and resource: point weather for any U.S. coordinate or address, returning current conditions, active severe alerts and a short-term rain outlook. It explicitly names the sibling tools it is not (get_address_report, get_property_storm_history_report, get_storm_history, get_risk_forecast), so an agent can route without opening schemas.

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 usage rule: 'Use for what the weather is or will be at a location', plus a clear negative rule excluding storm history and storm-risk forecasts with the specific alternatives to use instead. The hours_ahead=0-48 condition for switching to the hourly-forecast behavior is stated directly.

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