Storm history by address since 2003, recent storm leads, model-based weather and storm forecasts.
Scored across 6 tools
The descriptions do heavy lifting, explicitly naming the sibling tool to use instead, which makes most boundaries clear. However, get_weather_data is an intentional catch-all that overlaps with every other tool, and get_address_report vs get_property_storm_history_report differ mainly by time window, creating some residual selection risk.
All six tools use the consistent get_ prefix with snake_case nouns, so the surface reads predictably. Minor inconsistency in that the same entity is called both 'address' and 'property' (get_address_report vs get_property_storm_history_report) and both 'weather' and 'storm' are used loosely.
Six tools is a reasonable, well-scoped set for a storm/weather data API covering address vs county and past vs future. The catch-all get_weather_data is somewhat redundant with the dedicated tools, but it earns a place by exposing extra parameters and paid pulls.
Coverage spans the core lifecycle: address-level 365-day and full 2003-present history, county-level past and future forecasts, and current/48-hour weather with alerts. No obvious dead ends for the storm-data domain, though a dedicated alerts-only or forecast-address tool is only reachable through the catch-all.
ONE PROPERTY, PAST 365 DAYS. Property Snapshot by Address: Past Storm Leads plus County Forecast Label. Use for recent storms at one exact address: its own reported and radar-detected storm events within a tight radius (about 150 m), with the county's current forecast label as secondary context. Input is an address with county and state, or lat/lon. Not the full archive (use get_property_storm_history_report, Storm History by Address, which searches a wider 5-mile radius so counts will differ), not a county summary (use get_storm_history), and not forecasts (use get_risk_forecast, ML Storm Forecast by Address). For paid single-address data, call get_weather_data with dataset=address and addresses=true ($0.05 flat per address; needs an Atlas United Data API key or an x402 payment).
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude. | |
| lon | No | Longitude. | |
| state | No | 2-letter US state code, e.g. TX. | |
| county | No | County name without the word 'County', e.g. Dallas. | |
| address | No | Street address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint and openWorldHint. The description adds real behavioral context beyond them: the ~150 m detection radius, that the county forecast label is secondary, and that the paid single-address route is a different tool with a flat per-address price and an API-key/x402 requirement. It doesn't state this tool's own cost or auth picture explicitly, only contrasting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense and front-loaded: the scope constraint comes first, then routing, then the paid-alternative caveat. Slightly penalized for restating the title verbatim in the first two sentences, which duplicates the title field rather than adding information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does name the payload (own reported and radar-detected events plus a county forecast label). It omits output shape/pagination details and its own cost/auth status, but for a read-only lookup with clear routing it is close to sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning the schema cannot: it clarifies that input is 'an address with county and state, OR lat/lon' — an either/or usage pattern that is not obvious from five optional parameters with no required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Property Snapshot by Address: Past Storm Leads plus County Forecast Label') with the precise scope front-loaded ('ONE PROPERTY, PAST 365 DAYS'). It distinguishes itself from all four relevant siblings by name and by what each does differently (wider radius, county-level, forecast-only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the when-to-use case (recent storms at one exact address, ~150 m radius) and gives three explicit exclusions with the sibling to use instead: get_property_storm_history_report (wider 5-mile radius, counts will differ), get_storm_history (county), get_risk_forecast (forecasts). It even flags that counts will differ between tools, which prevents misreading divergent results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude, alternative to address. | |
| lon | No | Longitude, alternative to address. | |
| address | No | Street address. Real server-side geocoding -- no separate geocoding step needed. | |
| details | No | true = full pull, $0.0002/call, requires an API key or x402 payment. false (default) = free lean response. | |
| x_payment | No | Optional signed x402 payment payload, used instead of an API key when details=true. | |
| hours_ahead | No | 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. |
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.
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.
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.
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.
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.
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.
ONE PROPERTY, 2003 TO PRESENT. Storm History by Address: Reported and Radar-Detected Events Since 2003. Use when the user wants the full citable record for a single address, or a date-of-loss lookup: 11 event categories (hail, wind, flood, lightning, tornado, hurricane, winter storm, extreme heat/cold, drought, wildfire, coastal) in one report. Input is a street address or lat/lon. Not the 365-day snapshot (use get_address_report) and not a county summary (use get_storm_history). Free preview shows the report-line count and exact price before anything is paid. Paid report: $0.05 per line, $10.00 minimum per report. Optional date_of_loss anchors the report around one date and lists the events reported or radar-detected on and around it, for reference; it is not a determination of whether any claim is valid. Address and date of loss are sent in a POST body, which keeps them out of URLs and logs.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude, alternative to address. | |
| lon | No | Longitude, alternative to address. | |
| address | No | Street address. Real server-side geocoding -- no separate geocoding step needed. | |
| addresses | No | false = free preview (line count + price). true = the real full report -- requires the user's own Atlas United Data API account key, or an x402 payment. | |
| radius_mi | No | Search radius in miles. Default 5, max 25. | |
| x_payment | No | Optional signed x402 payment payload, used instead of an API key. | |
| date_of_loss | No | Optional, YYYY-MM-DD. Anchors the report around this date. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnly/openWorld; the description adds material traits beyond that: a free preview of line count and price, the paid rate ($0.05/line, $10.00 minimum), that address and date_of_loss travel in a POST body to stay out of logs, and a caveat that date_of_loss is a reference anchor and not a claim determination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the scope and the routing rules, and most sentences carry unique information. The second sentence duplicates the title verbatim, which is wasted text already present in structured metadata.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter, no-required-parameter pricing tool with no output schema and thin annotations, the description covers selection, alternatives, cost, preview mechanics, input privacy, and the date_of_loss caveat. It stops short of describing what a report 'line' or the returned report actually contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 real meaning: date_of_loss semantics (anchors the report, is not a validity determination), address vs lat/lon as alternatives, and privacy handling of inputs. It does not clarify the potentially confusing address (string) vs addresses (boolean preview/full flag) pair.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource (storm history report for one property) with scope stated as '2003 to present' and 11 named event categories. It explicitly names the siblings it is not (get_address_report for the 365-day snapshot, get_storm_history for county summaries), so an agent can differentiate 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('full citable record for a single address, or a date-of-loss lookup') and explicit when-not with the exact alternative tool for each case. Nothing about tool selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| peril | No | Narrows the forecast to one storm type -- check a free preview's storm_types for real values available in this window. | |
| state | Yes | 2-letter US state code, e.g. TX. | |
| county | Yes | County name without the word 'County', e.g. Dallas. | |
| window | No | Forecast window. Default 24h. |
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.
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.
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.
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.
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.
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.
COUNTY LEVEL, FREE, PAST 365 DAYS. Past Storm Leads by Address: Reported and Radar-Detected, Last 365 Days. Use when the question is how much storm activity a county has had in the past year: event counts, storm types, measured severity ranges and repeat properties. Input is state plus county, never a street address. Not for one property (use get_address_report), not for the 2003-to-present record (use get_property_storm_history_report), not for future storms (use get_risk_forecast). Not a damage assessment. For the paid address-level list, call get_weather_data with dataset=storms and addresses=true ($0.05 per address; needs an Atlas United Data API key or an x402 payment).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look-back window in days (up to 365). | |
| peril | No | Storm/risk type filter. Used by dataset=storms and dataset=risk (narrows to one storm type -- use the exact names returned under storm_types in a free preview) and by dataset=at_risk (narrows to one peril bucket, a different real meaning -- check that dataset's own preview for its real values). Common storms/risk values: HAIL, THUNDERSTORM_WIND, FLASH_FLOOD, HEAVY_RAIN, FLOOD, TORNADO. | |
| state | Yes | 2-letter US state code, e.g. TX. | |
| county | Yes | County name without the word 'County', e.g. Dallas. | |
| min_severity | No | Minimum severity, e.g. 1.75 for golf-ball hail. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description usefully adds that this is FREE, county-scoped, and 'not a damage assessment', plus pricing/auth for the paid alternative. However it says nothing about return shape, pagination, or result limits that the annotations don't cover. With the safety profile carried by annotations, this is an adequate but not rich addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the key constraints (COUNTY LEVEL, FREE, PAST 365 DAYS) and every sentence routes or excludes. Slightly redundant, restating the title's 'Past Storm Leads by Address' and the 365-day window, but no wasted clauses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description carries the return-value burden, and it does name the result contents (event counts, storm types, severity ranges, repeat properties) plus all routing and the paid alternative. It stops short of describing any response structure or limits, leaving a small gap for a 5-param data tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds a real semantic constraint the schema only implies: 'Input is state plus county, never a street address', which disambiguates the required params from address-level tools. Otherwise param details (peril values, min_severity example) merely restate the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource+scope: county-level reported and radar-detected storm history for the past 365 days, returning event counts, storm types, severity ranges and repeat properties. It explicitly names the siblings it is NOT (get_address_report, get_property_storm_history_report, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use ('how much storm activity a county has had in the past year'), several when-not cases with named alternatives, and even the paid escalation path (get_weather_data with dataset=storms and addresses=true) including cost and auth requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CATCH-ALL and PAID-PULL tool. Prefer the dedicated tools below when one fits (get_storm_history: one county, past 365 days; get_risk_forecast: one county, next 24 hours to 10 days; get_address_report: one address, past 365 days; get_property_storm_history_report: one address, 2003 to present; get_current_weather: one point, now to 48 hours). Use THIS tool for: every PAID address-level pull (set addresses=true), county coverage, facilities, wildfire (county-level), at_risk, daily, a counties multi-county rollup (comma-separated, max 15), hazard_score, or any parameter the dedicated tools do not expose (radius_mi, date_of_loss, window, months, category, limit, kind, details, hours_ahead). Datasets: ML Storm Forecast by Address (risk), Model-Based Weather by Address (weather), Model-Based Hourly Forecast by Address (weather with hours_ahead), Storm History by Address: Reported and Radar-Detected Events Since 2003 (history), Past Storm Leads by Address: Reported and Radar-Detected, Last 365 Days (storms). addresses=false (default) is a FREE preview; addresses=true (or details=true for weather) returns the paid data and requires the user's own Atlas United Data API account key, or an x402 payment. Call with no arguments for the full menu. HARD RULE when called with no arguments: this returns the full menu. Output that entire raw response back to the user verbatim, every dataset, every field, every example. Do not summarize or paraphrase. A shortened version is wrong even if it looks complete.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude in decimal degrees. | |
| lon | No | Longitude in decimal degrees. | |
| days | No | Look-back window in days where supported. | |
| kind | No | dataset=at_risk only. Narrows to 'schools' or 'businesses'. | |
| limit | No | Max records on the real paid pull (default 2000, real per-dataset caps still apply -- e.g. storms caps at 5000). | |
| peril | No | Storm/risk type filter. Used by dataset=storms and dataset=risk (narrows to one storm type -- use the exact names returned under storm_types in a free preview) and by dataset=at_risk (narrows to one peril bucket, a different real meaning -- check that dataset's own preview for its real values). Common storms/risk values: HAIL, THUNDERSTORM_WIND, FLASH_FLOOD, HEAVY_RAIN, FLOOD, TORNADO. | |
| state | No | 2-letter US state code, e.g. TX. | |
| county | No | County name without the word 'County', e.g. Dallas. | |
| format | No | Response format. json (default) or csv. | json |
| months | No | dataset=storms only. Returns month-bucketed history totals instead of individual leads, for the last N months. | |
| window | No | dataset=risk only. Forecast window. Default 24h. | |
| address | No | Street address, for dataset=address. | |
| dataset | No | Target dataset. Default storms. | |
| details | No | dataset=weather only (Model-Based Weather by Address). true = full current-conditions pull, billed $0.0002/call. false (default) = free lean response, no account needed. Equivalent to addresses=true for this dataset. | |
| category | No | dataset=facilities only. Facility category filter. | |
| counties | No | Comma-separated county names (max 15) plus state, for a multi-county rollup. Free preview only. | |
| addresses | No | false = free preview. true = address-level records -- requires EITHER the user's own Atlas United Data API account key (Authorization header) OR an x402 payment (see x_payment param below); no account needed for the x402 path. | |
| radius_mi | No | dataset=history only. Search radius in miles. Default 5, max 25. | |
| x_payment | No | Optional. A signed x402 protocol payment payload (base64), used instead of an API key to pay for ONE address-level pull in USDC on Base network. If addresses=true and neither an API key nor x_payment is provided, the response is an HTTP 402 with full payment instructions (pay_to address, amount, network) an agent can act on to construct this payload and retry. | |
| hours_ahead | No | dataset=weather only (Model-Based Hourly Forecast by Address). 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. | |
| date_of_loss | No | dataset=history only. YYYY-MM-DD. Anchors the report around this date -- returns the real weather events recorded on and immediately around that date, for reference. Not a determination of whether any claim is valid. | |
| max_severity | No | Maximum measured severity. | |
| min_severity | No | Minimum measured severity (e.g. 1.5 = 1.5 inch hail). Check severity_by_type in a preview for the real unit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover only readOnlyHint and openWorldHint. The description adds the behavior that actually matters: free preview vs paid pull, the requirement for the user's own API key or an x402 USDC payment, the HTTP 402 fallback with pay_to/amount/network, and per-call billing. It also discloses a hard operational rule for the no-argument case.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Long but front-loaded: routing guidance and the sibling exclusion list come first, then the dataset enumeration, then payment behavior, then the no-argument rule. The parenthetical parameter list is dense, but nearly every clause carries routing or billing information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates by describing the free-preview vs paid return semantics, the HTTP 402 error shape, and fields like forecast_hour_used. It stops short of describing the structure of the dataset payloads themselves, which for a spillover tool of this breadth is a real but acceptable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 23 parameters (e.g. window, months, date_of_loss, radius_mi). The description reinforces which parameters the dedicated tools do not expose and repeats the addresses/details free-vs-paid semantics, but adds little beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource and scope immediately: it is a 'CATCH-ALL and PAID-PULL tool' for Atlas United data across all datasets. It names all five siblings and the exact conditions under which this tool (not them) applies, so an agent can route without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use and when-not-to-use: 'Prefer the dedicated tools below when one fits' with a per-sibling scope (one county / one address / past 365 days, etc.), followed by an enumerated 'Use THIS tool for:' list. This is textbook routing guidance with named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_weather_data3 fields changedInput schema / properties / details / descriptionPrevious value: -"dataset=weather only. true = full current-conditions pull, billed $0.0002/call. false (default) = free lean response, no account needed. Equivalent to addresses=true for this dataset."New value: +"dataset=weather only (Model-Based Weather by Address). true = full current-conditions pull, billed $0.0002/call. false (default) = free lean response, no account needed. Equivalent to addresses=true for this dataset."Input schema / properties / hours_ahead / descriptionPrevious value: -"dataset=weather only. 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."New value: +"dataset=weather only (Model-Based Hourly Forecast by Address). 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."Input schema / properties / radius_mi / descriptionPrevious value: -"dataset=history or dataset=weather only. Search radius in miles. Default 5, max 25."New value: +"dataset=history only. Search radius in miles. Default 5, max 25."get_current_weather2 fields changedInput schema / properties / details / descriptionPrevious 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."Input schema / properties / hours_ahead / descriptionPrevious 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."get_weather_data2 fields changedInput schema / properties / details / descriptionPrevious value: -"dataset=weather only. true = full 164-field pull, billed $0.0002/call. false (default) = free 10-field lean response, no account needed. Equivalent to addresses=true for this dataset."New value: +"dataset=weather only. true = full current-conditions pull, billed $0.0002/call. false (default) = free lean response, no account needed. Equivalent to addresses=true for this dataset."Input schema / properties / hours_ahead / descriptionPrevious value: -"dataset=weather only. 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: +"dataset=weather only. 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."get_weather_data1 field changedInput schema / properties / date_of_loss / descriptionPrevious value: -"dataset=history only. YYYY-MM-DD. Anchors the report around this date -- returns a real yes/no on whether weather data supports a loss that day, plus real events immediately before and after it."New value: +"dataset=history only. YYYY-MM-DD. Anchors the report around this date -- returns the real weather events recorded on and immediately around that date, for reference. Not a determination of whether any claim is valid."get_current_weather1 field changedInput schema / properties / hours_aheadAdded 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"
+}get_weather_data1 field changedInput schema / properties / hours_aheadAdded value: +{
+ "description": "dataset=weather only. 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"
+}get_risk_forecast1 field changedInput schema / properties / window / enumPrevious value: -[
- "24h",
- "48h",
- "3d",
- "5d",
- "7d",
- "10d",
- "16d"
-]New value: +[
+ "24h",
+ "48h",
+ "3d",
+ "5d",
+ "7d",
+ "10d"
+]get_weather_data1 field changedInput schema / properties / window / enumPrevious value: -[
- "24h",
- "48h",
- "3d",
- "5d",
- "7d",
- "10d",
- "16d"
-]New value: +[
+ "24h",
+ "48h",
+ "3d",
+ "5d",
+ "7d",
+ "10d"
+]get_weather_data1 field changedInput schema / properties / dataset / enumPrevious value: -[
- "storms",
- "risk",
- "address",
- "coverage",
- "facilities",
- "wildfire",
- "at_risk",
- "daily",
- "history",
- "weather"
-]New value: +[
+ "storms",
+ "risk",
+ "address",
+ "coverage",
+ "facilities",
+ "wildfire",
+ "at_risk",
+ "daily",
+ "history",
+ "weather",
+ "hazard_score"
+]get_current_weatherget_property_storm_history_reportget_risk_forecast2 fields changedInput schema / properties / perilAdded 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"
+}Input schema / properties / windowAdded value: +{
+ "description": "Forecast window. Default 24h.",
+ "enum": [
+ "24h",
+ "48h",
+ "3d",
+ "5d",
+ "7d",
+ "10d",
+ "16d"
+ ],
+ "type": "string"
+}get_storm_history1 field changedInput schema / properties / peril / descriptionPrevious value: -"Storm type filter (dataset=storms only). Use the exact names returned under storm_types in a free preview for that county, e.g. HAIL, THUNDERSTORM_WIND, FLASH_FLOOD, HEAVY_RAIN, FLOOD, TORNADO."New value: +"Storm/risk type filter. Used by dataset=storms and dataset=risk (narrows to one storm type -- use the exact names returned under storm_types in a free preview) and by dataset=at_risk (narrows to one peril bucket, a different real meaning -- check that dataset's own preview for its real values). Common storms/risk values: HAIL, THUNDERSTORM_WIND, FLASH_FLOOD, HEAVY_RAIN, FLOOD, TORNADO."get_weather_data9 fields changedInput schema / properties / categoryAdded value: +{
+ "description": "dataset=facilities only. Facility category filter.",
+ "type": "string"
+}Input schema / properties / date_of_lossAdded value: +{
+ "description": "dataset=history only. YYYY-MM-DD. Anchors the report around this date -- returns a real yes/no on whether weather data supports a loss that day, plus real events immediately before and after it.",
+ "type": "string"
+}Input schema / properties / detailsAdded value: +{
+ "default": false,
+ "description": "dataset=weather only. true = full 164-field pull, billed $0.0002/call. false (default) = free 10-field lean response, no account needed. Equivalent to addresses=true for this dataset.",
+ "type": "boolean"
+}Input schema / properties / kindAdded value: +{
+ "description": "dataset=at_risk only. Narrows to 'schools' or 'businesses'.",
+ "type": "string"
+}Input schema / properties / limitAdded value: +{
+ "description": "Max records on the real paid pull (default 2000, real per-dataset caps still apply -- e.g. storms caps at 5000).",
+ "type": "integer"
+}Input schema / properties / monthsAdded value: +{
+ "description": "dataset=storms only. Returns month-bucketed history totals instead of individual leads, for the last N months.",
+ "type": "integer"
+}Input schema / properties / peril / descriptionPrevious value: -"Storm type filter (dataset=storms only). Use the exact names returned under storm_types in a free preview for that county, e.g. HAIL, THUNDERSTORM_WIND, FLASH_FLOOD, HEAVY_RAIN, FLOOD, TORNADO."New value: +"Storm/risk type filter. Used by dataset=storms and dataset=risk (narrows to one storm type -- use the exact names returned under storm_types in a free preview) and by dataset=at_risk (narrows to one peril bucket, a different real meaning -- check that dataset's own preview for its real values). Common storms/risk values: HAIL, THUNDERSTORM_WIND, FLASH_FLOOD, HEAVY_RAIN, FLOOD, TORNADO."Input schema / properties / radius_miAdded value: +{
+ "description": "dataset=history or dataset=weather only. Search radius in miles. Default 5, max 25.",
+ "type": "number"
+}Input schema / properties / windowAdded value: +{
+ "description": "dataset=risk only. Forecast window. Default 24h.",
+ "enum": [
+ "24h",
+ "48h",
+ "3d",
+ "5d",
+ "7d",
+ "10d",
+ "16d"
+ ],
+ "type": "string"
+}get_weather_data1 field changedInput schema / properties / dataset / enumPrevious value: -[
- "storms",
- "risk",
- "address",
- "coverage",
- "facilities",
- "wildfire",
- "at_risk",
- "daily"
-]New value: +[
+ "storms",
+ "risk",
+ "address",
+ "coverage",
+ "facilities",
+ "wildfire",
+ "at_risk",
+ "daily",
+ "history",
+ "weather"
+]get_address_reportget_hazard_forecastget_risk_forecastget_storm_historyget_storm_previewget_weather_datalookup_address_hazardquery_weather_dataget_hazard_forecastget_storm_previewlookup_address_hazardquery_weather_dataRadar-verified hail/wind storm detection and affected-property intelligence for the continental US.
Forecasts, severe-weather alerts, air quality, 20-year weather history, solar and wind production.
Published weather records for a U.S. address and date, with provenance, and current NWS forecasts.
Forecasts for any US point, with context: alerts, what changed overnight, why, and history.
Add one secure layer between your agents and this server.