Flood, wildfire, earthquake, and coastal-storm hazard lookup for a US property.
Scored across 1 tool
With only a single tool, there is no possibility of confusion or overlap. The tool's purpose is clearly defined and unambiguous.
The single tool name 'assess_property_hazard' follows a clear verb_noun pattern, which is consistent with best practices. There are no other names to create inconsistency.
A single tool feels thin for a server, even a focused one. The tool is comprehensive for its stated purpose, but the surface area is minimal, limiting broader workflows.
The tool covers the core hazard assessment workflow end-to-end, including geocoding and multiple hazard lookups. A minor gap is the lack of a per-hazard breakdown, which could help agents understand what drives the score.
Assess natural hazard exposure for a single US property address.
Validates and geocodes the address (US Census Bureau geocoder), then looks up FEMA flood zone, wildfire hazard, USGS seismic PGA, active fault proximity, and coastal proximity. Returns a location-only hazard score (0-100) and tier. US addresses only; no building characteristics required.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
| Name | Required | Description |
|---|---|---|
| lat | No | Latitude of the matched address |
| lng | No | Longitude of the matched address |
| sfha | No | Whether the address is in a Special Flood Hazard Area |
| message | No | Explanation of why validation failed, if it did |
| validated | Yes | Whether the address was successfully validated/geocoded |
| flood_zone | No | FEMA flood zone code (e.g. AE, X, VE); null if unavailable |
| hazard_tier | No | Hazard tier label: Low, Moderate, High, or Very High |
| seismic_pga | No | USGS peak ground acceleration in g (ASCE 7-22) |
| hazard_score | No | Deterministic location-only hazard score, 0-100 |
| input_address | Yes | The address as provided by the caller |
| hazard_drivers | No | Up to 5 human-readable factors driving the score |
| wildfire_score | No | Coarse wildfire hazard tier, 0 (none) to 4 (very high) |
| flood_available | No | Whether the FEMA flood zone lookup succeeded |
| matched_address | No | Normalized address returned by the geocoder |
| fault_distance_miles | No | Distance to the nearest known active fault, in miles |
| coastal_distance_miles | No | Distance to the nearest coastline, in miles |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it mentions address validation/geocoding via US Census Bureau geocoder, the specific hazard data sources, and that the score is location-only. Annotations already indicate read-only, idempotent, and non-destructive behavior. No contradictions.
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 very concise: two short paragraphs with no wasted words. It front-loads the main action and then lists details. Every sentence adds value.
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 a single parameter and the presence of annotations and an output schema, the description fully covers what the tool does, its input requirements, the process, and the output format (hazard score 0-100 and tier). No critical information 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?
Only one parameter (address) with 0% schema description coverage. The description compensates by explaining that the address is validated and geocoded, and implies it must be a US property address. This adds meaning beyond the bare parameter name.
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 assesses natural hazard exposure for a single US property address. It lists specific hazards (FEMA flood zone, wildfire, USGS seismic PGA, active fault, coastal proximity) and notes it returns a location-only hazard score and tier. The purpose is specific and well-defined.
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 specifies that only US addresses are accepted and that no building characteristics are required. This provides clear guidance on when to use the tool. However, it does not explicitly mention when not to use it or any alternatives, though there are no sibling tools to distinguish from.
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.
assess_property_hazardProperty intelligence: 180M+ US parcels — lookup, search, owners, hazards, permits, deeds.
Address-level storm event data and forecasted property risk API for AI agents
US property risk data for agents: flood, hazards, taxes, air quality. Credits or USDC.
Zoning, ADU eligibility, flood zone, setbacks, and buildability intelligence for U.S. parcels.
Add one secure layer between your agents and this server.
