Skip to main content
Glama

fema-mcp-server

by io.github.cyanheads

Search FEMA Disaster Declarations

fema_search_disasters
Read-only

Search federal disaster declarations by state, incident type, declaration type, date range, and county. Returns deduplicated declaration-level summaries — each disaster number appears once with a designatedAreaCount showing how many counties/municipalities were designated. The disaster number is the chain key for fema_get_disaster, fema_get_public_assistance, and fema_get_housing_assistance. Use declaration_type to filter: DR (major disaster, most common), EM (emergency), FM (fire management). Date filters apply to the declaration date. Use fema_get_disaster to retrieve all designated-area rows for a specific declaration.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of unique disaster declarations to return (1–1000, default 50).
stateNoTwo-letter US state/territory code (e.g., TX, CA, FL, PR). Filters by state.
countyNoFilter by designated area / county name substring (e.g., Harris, Los Angeles). Case-insensitive.
offsetNoPagination offset in declarations (default 0). Use with limit to page through results.
date_toNoEnd of declaration date range in ISO 8601 format (e.g., 2024-12-31). Inclusive.
date_fromNoStart of declaration date range in ISO 8601 format (e.g., 2024-01-01). Inclusive.
incident_typeNoIncident type filter (e.g., Flood, Hurricane, Tornado, Fire, Earthquake, Severe Storm). Case-insensitive substring match.
declaration_typeNoDeclaration type: DR (major disaster declaration), EM (emergency declaration), FM (fire management assistance declaration).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance when no results were found.
totalCountNoTotal unique disaster declarations matching the query — the unit declaration-level pagination pages over. Exceeds returned_count when the matches span more than one page.
declarationsNoDisaster declarations matching the search, one entry per unique disaster number.
returned_countNoNumber of unique deduplicated declarations in this response.
total_area_rowsNoTotal matching designated-area rows from the API (raw row count, not declaration count). DisasterDeclarationsSummaries returns one row per designated area per disaster, so this is always ≥ the number of unique declarations. When total_area_rows exceeds 10 000, results are truncated to the most recent 10 000 rows — apply tighter filters to stay within this window.
total_declarationsNoTotal unique disaster declarations matching the query, before offset/limit paging — the bound for declaration-level pagination (limit/offset apply to declarations, not area rows). A floor rather than the exact total when total_area_rows hits the 10,000-row overfetch cap.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark the tool as readOnlyHint and openWorldHint. The description adds behavioral context: deduplication of disaster numbers with designatedAreaCount, and that date filters apply to declaration date. This goes beyond the annotations and clearly sets expectations for return shape and filter behavior.

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 efficient, about 110 words, with every sentence contributing. It front-loads the main purpose and filters, then explains deduplication, chaining, and alternative usage. No filler or unnecessary detail.

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 the tool has 8 parameters, a comprehensive schema, annotations, and an output schema, the description covers all necessary aspects: purpose, filters, deduplication, chaining, and alternative usage. It does not need to restate return values since an output schema exists, but it still mentions designatedAreaCount as a useful detail.

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 description coverage is 100%, so the schema fully documents each parameter. The description adds value by clarifying the declaration_type meanings (DR, EM, FM) and describing the deduplication behavior, though some parameter descriptions are repeated from the schema. Overall it enriches understanding without redundancy.

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 states a clear verb ('Search') and resource ('federal disaster declarations') with specific filter dimensions (state, incident type, declaration type, date range, county). It distinguishes itself from fema_get_disaster by noting this returns summaries and that fema_get_disaster retrieves all designated-area rows for a specific declaration.

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?

Provides explicit when-to-use and when-not-to: says to use fema_get_disaster for full designated-area rows, explains the chain key usage for related tools, and clarifies declaration_type values (DR, EM, FM). Also notes date filters apply to declaration date, guiding appropriate filter semantics.

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

All fema-mcp-server toolsInspect
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.5/5.0
Disambiguation5/5

Each tool has a distinct purpose: search vs get, specific NFIP vs generic OData, and staging/query helpers. Descriptions clarify boundaries, minimizing confusion.

Naming Consistency5/5

All tools follow a consistent 'fema_<verb>_<target>' snake_case pattern (e.g., fema_search_disasters, fema_get_disaster). No mixed conventions or vague verbs.

Tool Count5/5

With 8 tools covering search, retrieval, NFIP claims, generic OData, and data staging, the count is well-scoped for the FEMA data domain without excess or insufficiency.

Completeness4/5

The set covers core workflows (disaster search/details, housing/PA assistance, NFIP search, generic query). Minor gap: detailed NFIP claim records require the generic query with timeout risks, but overall coverage is strong.

Resources