Property Hazard MCP

Assess Property Hazard Risk

assess_property_hazard

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`address`	Yes

Output Schema

TableJSON Schema

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

TDQS

A4.5/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Property Hazard MCP tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Only one tool exists, so there is no possibility of confusion with other tools.

Naming Consistency5/5

With a single tool, naming consistency is not applicable, but the name clearly follows a verb_noun pattern.

Tool Count3/5

A single tool feels thin for a property hazard assessment domain; users might expect additional tools for batch processing or detailed breakdowns.

Completeness4/5

The tool covers major hazard types (flood, wildfire, seismic, fault, coastal) and returns a composite score, which is reasonably complete for a single-address assessment, though it lacks batch or historical capabilities.

Assess Property Hazard Risk

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources