FEMA Disasters
Server Details
Federal disaster declarations, emergencies, and assistance data
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.9/5 across 5 of 5 tools scored.
Each tool has a clearly distinct purpose targeting different aspects of FEMA disaster data: declarations overview, detailed disaster info, hazard mitigation grants, individual assistance, and public assistance. The descriptions clearly differentiate between these domains with no overlap or ambiguity.
All tools follow a consistent 'get_[specific_domain]' naming pattern using snake_case. The naming convention is perfectly uniform across all five tools, making them predictable and easy to understand.
Five tools is well-scoped for a FEMA disasters server, covering core data domains without being overwhelming. Each tool serves a distinct purpose that earns its place in the set, providing comprehensive coverage of disaster-related data.
The tool set provides excellent coverage of FEMA disaster data domains including declarations, detailed disaster info, and three major assistance programs. A minor gap exists in not having tools for disaster preparedness or recovery planning data, but the core data retrieval operations are well-covered.
Available Tools
5 toolsget_disaster_declarationsAInspect
Get FEMA disaster declarations filtered by state, year, or type.
Returns federal disaster declarations including major disasters,
emergencies, and fire management assistance. Each record includes
the disaster number, title, declaration date, and affected area.
Args:
state: Two-letter US state abbreviation (e.g. 'CA', 'TX', 'FL').
year: Filter by fiscal year of the declaration (e.g. 2023).
disaster_type: Declaration type code: 'DR' (major disaster),
'EM' (emergency), or 'FM' (fire management assistance).
limit: Maximum number of records to return (default 25, max 1000).| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| limit | No | ||
| state | No | ||
| disaster_type | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description carries full burden: discloses default/max limits (25/1000) and specifies returned fields (disaster number, title, etc.) beyond what structured data provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear separation between purpose, return value summary, and parameter definitions; appropriately concise with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 optional parameters and existence of output schema, description is complete: documents all inputs and provides sufficient return value context without over-explaining what the output schema already covers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Comprehensively compensates for 0% schema description coverage by detailing all 4 parameters with examples (e.g., 'CA', 'TX'), valid value explanations ('DR', 'EM', 'FM'), and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves FEMA disaster declarations with filtering capability; distinguishes from siblings implicitly via plural 'declarations' vs 'detail' and grants/assistance tools, though explicit differentiation is absent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this listing tool versus the singular 'get_disaster_detail' or other related tools; only describes filtering capabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_disaster_detailAInspect
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).| Name | Required | Description | Default |
|---|---|---|---|
| disaster_number | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses what comprehensive data is returned (programs, dates, areas) since no annotations exist, though lacks details on rate limits or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tightly structured with clear Args section; every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriately complete given the single-parameter simplicity and existence of output schema; covers purpose, parameter source, and return value summary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Compensates for 0% schema description coverage by defining disaster_number as a FEMA disaster number with concrete examples (4737, 3604).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves detailed information for a specific/single FEMA disaster declaration, distinguishing it from the list-oriented sibling get_disaster_declarations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs users to use disaster numbers from get_disaster_declarations results, establishing clear workflow sequencing with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_hazard_mitigation_grantsAInspect
Get FEMA Hazard Mitigation Grant Program (HMGP) data.
Returns data on grants awarded to reduce future disaster losses through
mitigation projects such as property acquisition, elevation, and
infrastructure improvements.
Args:
state: Two-letter US state abbreviation (e.g. 'CA', 'TX').
limit: Maximum number of records to return (default 25, max 1000).| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses pagination limits (default 25, max 1000) and describes return data content, but lacks info on error handling, rate limits, or auth requirements given no annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose statement followed by Args documentation; slightly informal docstring style but appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete enough for the tool's complexity; covers parameter semantics since schema lacks descriptions, and appropriately omits detailed return value explanation since output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Fully compensates for 0% schema description coverage by documenting both parameters with clear semantics, examples ('CA', 'TX'), and constraints (max 1000).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves FEMA Hazard Mitigation Grant Program data and explains the specific mitigation focus (property acquisition, elevation), distinguishing it from sibling assistance/declaration tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus the sibling assistance or declaration tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_individual_assistanceAInspect
Get FEMA Individual and Households Program (IHP) assistance data.
Returns aggregated data on individual assistance provided to disaster
survivors including housing assistance and other needs assistance.
Data is aggregated at the county level per disaster.
Args:
disaster_number: FEMA disaster number to filter by (e.g. 4737).
state: Two-letter US state abbreviation (e.g. 'CA', 'TX').
limit: Maximum number of records to return (default 25, max 1000).| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state | No | ||
| disaster_number | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses aggregation level (county-level) and data types (housing, other needs) but omits rate limits, auth requirements, or cache behavior; no annotations exist to contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose front-loaded, followed by data details and parameter documentation; Args section is necessary given empty schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately complete for a 3-parameter tool; covers data semantics (IHP vs other programs) appropriately without needing to detail return values since output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Fully compensates for 0% schema description coverage by providing detailed Args section with format examples (e.g., '4737', 'CA') and constraints (default 25, max 1000).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies the tool retrieves FEMA Individual and Households Program (IHP) data for disaster survivors, distinguishing it from sibling 'public_assistance' (infrastructure) and 'mitigation_grants' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage by describing the data scope (county-level aggregation, housing assistance) but lacks explicit when-to-use guidance or comparisons to alternatives like get_disaster_detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_public_assistanceAInspect
Get FEMA Public Assistance (PA) grant data for disaster recovery.
Returns PA grant obligations that fund debris removal, emergency
protective measures, and permanent restoration of infrastructure.
Filter by disaster number or state.
Args:
disaster_number: FEMA disaster number to filter by (e.g. 4737).
state: Two-letter US state abbreviation (e.g. 'CA', 'TX').
limit: Maximum number of records to return (default 25, max 1000).| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state | No | ||
| disaster_number | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses pagination limits (max 1000) and default values in the Args section, but omits rate limits, auth requirements, or data freshness details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose upfront followed by content explanation and parameter details; docstring-style Args section is functional though slightly informal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately explains the domain concept (PA vs other FEMA programs) and filtering capabilities; appropriately omits return value details since output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the Args section provides critical compensatory documentation for all 3 parameters with clear examples (e.g., '4737', 'CA').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly defines the tool as fetching FEMA Public Assistance grant data and distinguishes it from Individual Assistance by specifying infrastructure/debris focus, though explicit sibling contrasts are absent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context by explaining PA grants fund debris removal and infrastructure restoration, but lacks explicit when-to-use guidance versus siblings like get_individual_assistance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!