Address-level storm event data and forecasted property risk API for AI agents
Scored across 4 tools
Each tool targets a distinct data slice: address-specific report, county forecast, county past storms, and a catch-all for other datasets. The descriptions explicitly clarify boundaries and direct users to the simpler tools for common cases, eliminating ambiguity.
All four tools follow a consistent 'get_' + descriptive_snake_case pattern (get_address_report, get_risk_forecast, get_storm_history, get_weather_data). This makes the API predictable and easy to navigate.
With 4 tools, the server is well-scoped for its purpose of providing weather and property risk data. Each tool covers a major query type without redundancy, and the catch-all prevents the need for additional tools.
The surface covers the core domain (property reports, forecasts, past storms) and provides an extensible 'get_weather_data' for additional datasets like coverage, facilities, wildfire, and multi-county rollups. No obvious gaps or dead ends exist for a read-only data API.
Everything on file for ONE property: past storm history (up to 365 days) plus forecast risk. Give an address with county+state, or lat/lon.
| 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?
The description adds specifics beyond the readOnlyHint and openWorldHint annotations: it discloses the data scope (storm history up to 365 days and forecast risk) and the input modes. It does not mention output format or error handling, but it provides meaningful behavioral context for a read-only tool.
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?
The description is two sentences, front-loaded with the core purpose and then the input instructions. Every word earns its place; no filler or repetition of schema details.
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 read-only report with no output schema, the description explains what is returned and how to specify input, which is sufficient for an agent to invoke it correctly. It does not describe the output structure or edge cases (e.g., conflicting parameters), but the tool is simple and the annotations already cover safety.
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% with simple descriptions for each parameter. The description adds grouping: either address+county+state or lat/lon, clarifying how the parameters should be combined, which goes beyond the individual schema entries. This adds value without redundancy.
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 clearly states the tool returns both past storm history (up to 365 days) and forecast risk for a single property, which distinguishes it from sibling tools that focus on one aspect. It also specifies the input modes (address with county+state, or lat/lon), making the purpose unambiguous.
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?
The description implies a combined report but does not explicitly reference sibling tools or state when to prefer this over get_storm_history or get_risk_forecast. It gives clear input instructions but no when-to-use or when-not-to-use guidance, leaving the agent to infer from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE AtlasCast forecast for a county: severe weather risk 0 to 16 days ahead with county risk grades and property exposure. Forecast risk, not storms that already happened. Refreshed several times a day from NOAA models.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | 2-letter US state code, e.g. TX. | |
| county | Yes | County name without the word 'County', e.g. Dallas. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, and the description adds useful behavioral context: it is 'FREE AtlasCast', refreshed several times a day from NOAA models, and specifically forecasts risk rather than reporting observed storms. No contradiction with annotations exists.
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?
Three short, front-loaded sentences each serve a purpose: scope, deliverable, and data provenance. There is no filler or repetition of schema details.
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 read-only tool with two simple parameters and no output schema, the description adequately explains what the caller can expect (risk grades and property exposure) and the time range. A more complete version might define 'AtlasCast' or clarify the output format, but the essential invocation context is present.
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 schema already documents state and county. The description adds little beyond restating that this is a county-level forecast; it does not provide formula, units, or additional meaning for the two parameters.
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 uses a specific verb ('forecast') with a clear resource ('county risk grades and property exposure') and a defined time horizon (0 to 16 days ahead). It clearly distinguishes itself from historical storm reporting, which is enough to separate it from sibling get_storm_history.
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?
It provides clear context: this is for future risk, not past events, which implies when to prefer it over historical tools. However, it does not explicitly name alternatives like get_storm_history or get_weather_data, so the agent must infer which sibling to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE preview of reported and radar-detected past storm events (hail, wind, tornado, flooding) for a county: event counts, storm types, measured severities and repeat-hit properties.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look-back window in days (up to 365). | |
| peril | No | 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. | |
| 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, so the read-only nature is covered. The description adds that it is a 'FREE preview' and mentions data sources (reported and radar-detected), which is useful but does not disclose other behaviors like rate limits, pagination, or whether the preview is limited in depth. It does not contradict annotations.
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?
The description is a single, information-dense sentence that front-loads the key points (FREE preview, data source, scope, and output types). It is concise with no wasted words, though it is somewhat long and could be split for readability. Still, it earns its place.
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?
Given the lack of an output schema, the description adequately conveys what the agent will receive (event counts, types, severities, repeat-hit properties). It also clarifies the preview nature and county scope. It does not mention limits like max days (but that's in schema) or any prerequisites, but overall it is complete enough for a read-only preview 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%, and the descriptions are detailed (e.g., peril explains exact names, min_severity gives an example). The tool description itself adds no additional parameter meaning beyond what the schema already provides. Baseline 3 is appropriate since the schema carries the load.
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 (preview/reported and radar-detected), a clear resource (past storm events), and a precise scope (for a county). It enumerates the outputs (event counts, storm types, severities, repeat-hit properties), making it unambiguous what the tool does and distinct from siblings like get_risk_forecast or get_weather_data.
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?
The description implies usage for retrieving past storm history but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions (e.g., 'for forecasts use get_risk_forecast'). The context is clear enough from the name and description, but there is no direct routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Advanced query for datasets NOT covered by the other tools: dataset='coverage' (county coverage check), 'facilities' (nearby business/facility data), 'wildfire', 'at_risk' (properties currently in an active risk window), 'daily' (daily lead digest), or a 'counties' multi-county rollup (comma-separated, max 15). For a single county's past storms use get_storm_history, for a single county's forecast use get_risk_forecast, for one property use get_address_report -- those are simpler and cover the common case. Call with no arguments to get the full API menu. addresses=false (default) is a FREE preview with counts, severities and dollar exposure. addresses=true returns address-level records and requires the user's own Atlas United Data API account key.
| 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. | |
| peril | No | 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. | |
| 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 |
| address | No | Street address, for dataset=address. | |
| dataset | No | Target dataset. Default storms. | |
| 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. | |
| 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. | |
| 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 only declare readOnlyHint and openWorldHint, so the description carries the behavioral burden and meets it: it discloses the free preview behavior, the address-level paid tier requiring an API key or x402 payment, and the HTTP 402 fallback with payment instructions. It also documents multi-county limits and the no-arguments menu behavior.
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?
The description is dense but well-structured: purpose and scope first, sibling alternatives second, usage discovery third, and pricing/auth details fourth. Every sentence contributes decision-relevant information, and there is no repetition of annotation or schema boilerplate.
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 14-parameter tool with no output schema)Skip is complete: it covers dataset selection, sibling routing, free vs. paid behavior, authentication paths, error handling, and a fallback discovery mechanism. The absence of an output schema is mitigated by describing what free previews return and by offering the no-arguments menu.
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?
Although schema coverage is 100%, the description adds crucial semantic context beyond the schema: the meaning of each dataset option, the addresses=true authentication/payment distinction, the comma-separated counties constraint, and the fact that peril only applies to dataset=storms. This materially helps an agent select and combine parameters correctly.
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 opens with 'Advanced query for datasets NOT covered by the other tools' and enumerates the eight supported dataset modes, making the tool's role as an advanced aggregate/query tool explicit. It clearly distinguishes itself from the single-county and single-property sibling tools.
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?
The description explicitly names get_storm_history, get_risk_forecast, and get_address_report as the simpler alternatives for common single-county/property cases. It also tells the agent to call with no arguments to get the full API menu, leaving no ambiguity about when or how to invoke this tool.
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_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.
Weather, climate, terrain, fire and flood risk data for any point or polygon on Earth. Free tier.
US property risk data for agents: flood, hazards, taxes, air quality. Credits or USDC.
US weather & geo for AI agents: forecasts, alerts, earthquakes, elevation, geocoding. No keys.
Add one secure layer between your agents and this server.
