gov-data-mcp

fema-nri-county-risk-profile

Join locations by coordinates or county FIPS to FEMA National Risk Index county/tract profiles for composite risk, expected annual loss, vulnerability, resilience, and top hazards.

Instructions

FEMA NRI County Risk Profile — Asset Hazard Join. Join any asset (address, lat/lon, or county FIPS) to FEMA's National Risk Index hazard profile at county or census-tract resolution: composite risk score, expected annual loss, social vulnerability, resilience, and ranked top-3 hazards across all 18 FEMA perils. INPUTS: supply assets (FIPS, state+county, or lat/lon) for specific places; states and counties are used ONLY when assets is empty (inventory mode). resolution "tract" applies only to lat/lon assets and inventory pulls; FIPS or state+county assets always get county data. maxResults caps rows in both modes. Reads live from the official government source. Call describe-gov-data-tool (free) for a verified example input. COST AND SIDE EFFECTS: read-only with respect to the government source — it never writes to any external system — but each call starts a metered run on YOUR Apify account, billed $0.006 per result ($6 per 1,000). Lower on paid Apify plans, down to $1.80 per 1,000. Nothing is charged when a run fails. Store page: https://apify.com/malonestar/fema-nri-county-risk-profile

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "fema-nri-county-risk-profile"
  }
}

Input Schema

Name	Required	Description
`assets`	No	Locations to profile. Each item is EITHER {fips:"08031"} (5-digit county FIPS), OR {state:"Colorado", county:"Denver"}, OR {lat:39.7392, lon:-104.9903} (geocoded via the keyless FCC Census Block API). Add an optional "label" to identify each asset in the output. Leave empty to run inventory mode instead (see states/counties below). Example: [{"state":"Colorado","county":"Denver","label":"Denver HQ"},{"lat":29.9511,"lon":-90.0715,"label":"New Orleans warehouse"}].
`states`	No	Used only when Assets is empty. Return full NRI risk profiles for these US states (2-letter postal codes or full names, e.g. CO or Colorado) at the resolution set above (county or tract). Leave empty (with Assets also empty) to return a small nationwide sample bounded by Max results.
`counties`	No	Used only when Assets is empty. Narrows the States filter above to specific bare county names (no "County"/"Parish" suffix), e.g. Denver. Applies at both county and tract resolution.
`maxResults`	No	Maximum number of output records (each is one billed result). In asset mode this caps the number of assets processed; in inventory mode it bounds the row count returned (there are ~3,144 US counties and ~85,000 US census tracts total). Example: 500.
`resolution`	No	Geographic resolution to join against: "county" (default — ~3,144 US counties) or "tract" (~85,000 US census tracts, finer-grained). Tract resolution only applies to lat/lon assets (geocoded to a tract via the FCC Census Block API) and to inventory-mode states/counties pulls; fips or state+county assets carry no tract signal and always use county data. If a tract lookup misses or the tract service errors, the record gracefully falls back to its county profile with resolution_used="county" (never fails the run). Example: "county".

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.2Aug 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare readOnlyHint=false and openWorldHint=true; rather than contradicting them, the description explains the nuance — no external system is written, but each call starts a metered run on the caller's Apify account at $0.006/result ($6 per 1,000, down to $1.80 on paid plans), with no charge on failure. It also discloses graceful degradation behavior (a tract miss falls back to the county profile with resolution_used="county" and never fails the run), which is exactly the operational context 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?

Structure is strong — a one-line purpose, then INPUTS, then COST AND SIDE EFFECTS — and the mode-selection rule is front-loaded. It is somewhat long and partly redundant with the 100%-covered schema (the tract-fallback rule appears in both description and schema), plus a store URL, so it is efficient but not maximally tight.

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?

There is no output schema, and the description compensates by naming the returned risk fields; it also covers cost model, billing failure behavior, mode precedence, resolution limits, and a fallback path. For a metered, open-world, multi-mode tool, an agent has everything needed to call it correctly.

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 schema already carries most parameter documentation, but the description adds genuine cross-parameter semantics: the precedence of `assets` over `states`/`counties`, the interaction between asset type and `resolution`, and the dual meaning of `maxResults` (caps assets processed vs bounds inventory rows, where ~3,144 counties and ~85,000 tracts exist). Some of this repeats the schema's own `resolution` and `maxResults` text, which keeps it below a 5.

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 names a specific verb and resource — joining assets to FEMA's National Risk Index county/tract hazard profile — and enumerates what comes back (composite risk score, expected annual loss, social vulnerability, resilience, top-3 hazards, 18 perils). It also distinguishes its two operating modes (asset join vs inventory pull), so an agent can tell exactly what this tool produces versus the other dataset-specific siblings.

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?

It states the selection rule explicitly: supply `assets` for specific places, and `states`/`counties` are used ONLY when `assets` is empty. It further states that `resolution: "tract"` applies only to lat/lon assets and inventory pulls while FIPS or state+county assets always get county data, and it points agents to the free `describe-gov-data-tool` for a verified example input.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server