Skip to main content
Glama
Sign In

Openfema

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Disaster Declarations

disaster_declarations
Read-onlyIdempotent

Look up and COUNT US federal disaster declarations (FEMA DisasterDeclarationsSummaries). Filters: state (2-letter), incidentType (e.g. 'Fire', 'Flood', 'Hurricane', 'Severe Storm'), declarationType ('DR' major disaster, 'EM' emergency, 'FM' fire management), year (fyDeclared, the federal FISCAL year), and since/until for a real calendar date range — use since/until for questions like 'in the past year', which a fiscal year does not answer. Counts are DISTINCT DISASTERS by default, not table rows: FEMA publishes one row per disaster per designated county, so Hurricane Harvey is ~60 rows for Texas but one declaration. Pass designatedArea or grain:'area' for county-level rows. Returns the most recent first. The response echoes filters_applied plus a note: declarationType/incidentType/state/designatedArea each narrow the total to a SUBSET (e.g. declarationType:'DR' excludes 'EM' and 'FM') — for an across-all-types/all-states total, call again WITHOUT that filter rather than treating one filtered call's total as the grand total; for a true breakdown, call once per value and sum the totals yourself.

Input Schema

NameRequiredDescriptionDefault
yearNoFederal FISCAL year declared (fyDeclared), e.g. 2024. For a calendar window use since/until instead.
grainNo'disaster' (default) = one record per declaration; 'area' = one record per designated county.
limitNoMax records (default 50, max 1000).
sinceNoOnly declarations on/after this date — ISO 'YYYY-MM-DD'. Use with until for windows like 'the past year'.
stateNo2-letter state/territory code, e.g. 'CA', 'TX'.
untilNoOnly declarations on/before this date — ISO 'YYYY-MM-DD'.
orderbyNoOData $orderby, default 'declarationDate desc'. Live-API path only.
incidentTypeNoIncident type, e.g. 'Fire', 'Flood', 'Hurricane', 'Severe Storm'.
designatedAreaNoFilter to a designated area, e.g. 'Harris (County)'. Implies county-level grain.
declarationTypeNo'DR' (major disaster), 'EM' (emergency), or 'FM' (fire management).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / designatedArea
      Added value: +{
+  "description": "Filter to a designated area, e.g. 'Harris (County)'. Implies county-level grain.",
+  "type": "string"
+}
    • addedInput schema / properties / grain
      Added value: +{
+  "description": "'disaster' (default) = one record per declaration; 'area' = one record per designated county.",
+  "enum": [
+    "disaster",
+    "area"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / orderby / description
      Previous value: -"OData $orderby, default 'declarationDate desc'."New value: +"OData $orderby, default 'declarationDate desc'. Live-API path only."
    • addedInput schema / properties / since
      Added value: +{
+  "description": "Only declarations on/after this date — ISO 'YYYY-MM-DD'. Use with until for windows like 'the past year'.",
+  "type": "string"
+}
    • addedInput schema / properties / until
      Added value: +{
+  "description": "Only declarations on/before this date — ISO 'YYYY-MM-DD'.",
+  "type": "string"
+}
    • changedInput schema / properties / year / description
      Previous value: -"Fiscal year declared (fyDeclared), e.g. 2024."New value: +"Federal FISCAL year declared (fyDeclared), e.g. 2024. For a calendar window use since/until instead."
  2. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "state": "CA",
+    "year": 2024
+  },
+  {
+    "declarationType": "DR",
+    "incidentType": "Hurricane",
+    "limit": 100,
+    "state": "TX"
+  }
+]
  3. First observed

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds substantial non-obvious behavior: counts are DISTINCT disasters, not rows (Harvey is ~60 rows for Texas but one declaration), results are most-recent-first, and the response echoes filters_applied plus a note. That is real value beyond the annotations, though return-shape detail stays thin.

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?

Front-loaded with the verb and resource, and nearly every sentence carries operational weight. It is dense and slightly repetitive — the fiscal-vs-calendar point and the subset-narrowing warning are each stated twice — but the redundancy is defensible for a counting tool where silent misinterpretation is the main risk.

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?

Ten optional parameters and no output schema, yet the description supplies what an agent actually needs to interpret results: the counting unit, ordering, response keys (filters_applied, note), and the fact that per-filter totals are subsets rather than grand totals. Nothing essential to a correct call or to reading the answer 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?

Schema coverage is 100%, so each parameter is already documented and the baseline would be 3. The description still adds cross-parameter meaning the schema lacks: why year and since/until are not interchangeable, and that designatedArea or grain:'area' switches the unit of counting from declaration to county row.

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?

States a specific verb pair ('Look up and COUNT') plus the exact resource ('US federal disaster declarations') and names the underlying dataset (FEMA DisasterDeclarationsSummaries). No sibling tool covers disasters, so the agent can route here unambiguously from the name alone.

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?

Explicitly contrasts year (fiscal) against since/until (calendar) and tells the agent which to use for the common 'past year' question. It also prescribes the correct multi-call pattern: call again WITHOUT a filter for a grand total, and call once per value for a true breakdown — pre-empting a likely misuse.

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

All Openfema toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources