FEMA Disasters

get_disaster_detail

Get detailed information about a specific FEMA disaster declaration.

Returns comprehensive data for a single disaster including all declared
programs, incident dates, and affected areas. Use disaster numbers
from get_disaster_declarations results.

Args:
    disaster_number: The FEMA disaster number (e.g. 4737, 3604).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`disaster_number`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description must disclose behavior. It states the tool 'Returns comprehensive data' and lists what is included (programs, dates, areas), but does not explicitly mention side effects (none expected), error handling, or access constraints. The read-only nature is implied by 'Get' but not stated explicitly.

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 about five sentences, front-loaded with the primary purpose, followed by return details and parameter guidance. Every sentence earns its place without redundant fluff or repetition of schema information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple one-parameter tool, an output schema exists (so return values need not be described), and the description covers the essential workflow (getting numbers from the list tool). It could add guidance on handling missing/invalid disaster numbers, but the current description is sufficient for a typical detail lookup.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, yet the description includes a dedicated 'Args' section fully explaining disaster_number with examples ('e.g. 4737, 3604') and its source. This adds substantial meaning beyond the bare integer schema, making parameter usage clear.

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 opens with a specific verb and resource: 'Get detailed information about a specific FEMA disaster declaration.' It clearly distinguishes from siblings like get_disaster_declarations (list) by emphasizing 'single disaster' and 'specific'.

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 instructs to 'Use disaster numbers from get_disaster_declarations results,' providing a clear source for the input parameter. It implies the tool is for detailed lookups after listing, though it does not explicitly name alternative tools for filtering or exclusion conditions.

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

All FEMA Disasters 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

Each tool targets a distinct resource: declarations list, single declaration detail, and three separate assistance programs (HMGP, IHP, PA). The differentiation between declaration metadata and assistance data is clear, and the three assistance tools are distinguishable by their program-specific descriptions.

Naming Consistency5/5

All tool names follow the same verb_non ('get_') pattern with a clear noun descriptor, making the API predictable. There are no mixed conventions or vague verbs.

Tool Count5/5

With 5 tools, the count is well-scoped for a read-only FEMA data retrieval server. Each tool covers a major data category, and the count feels neither thin nor bloated.

Completeness4/5

The core domain of FEMA disasters is well-covered with declarations, detail, and the three main assistance programs. Minor gaps exist, such as no year filter on assistance queries or other FEMA datasets, but these do not severely hinder core workflows.

Resources

Need Help?