fema-mcp-server
Server Details
Query FEMA disaster declarations, public assistance grants, housing aid, and NFIP claims.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/fema-mcp-server
- GitHub Stars
- 1
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 4.5/5 across 8 of 8 tools scored.
Each tool has a distinct purpose: search vs get, specific NFIP vs generic OData, and staging/query helpers. Descriptions clarify boundaries, minimizing confusion.
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.
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.
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.
Available Tools
8 toolsfema_dataframe_describeDescribe FEMA DataCanvas TablesARead-onlyIdempotentInspect
List tables and column schemas on a DataCanvas staged by fema_search_nfip. Call this before fema_dataframe_query to discover the exact table name, column names, and DuckDB data types needed to write valid SQL. Row count reflects what was actually staged — check truncated in the fema_search_nfip response to know whether the canvas holds the full matching set.
| Name | Required | Description | Default |
|---|---|---|---|
| canvas_id | Yes | Canvas ID from the fema_search_nfip response. |
Output Schema
| Name | Required | Description |
|---|---|---|
| tables | Yes | All tables and views available on this canvas. |
| canvas_id | Yes | Canvas ID that was described — pass to fema_dataframe_query. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behaviors. Description adds context about row count reflecting actual staged data and cross-references truncated status, which goes beyond annotations.
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?
Two sentences, no wasted words. Front-loaded with purpose, followed by usage guidance. Ideal length for quick comprehension.
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 the simple single-parameter schema and presence of output schema (implied), the description covers all essential aspects: purpose, when to call, how to interpret results, and relevant warnings.
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?
Only one parameter (canvas_id) with 100% schema coverage. Description adds value by specifying it comes from 'fema_search_nfip response', providing source context beyond the schema description.
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?
Description clearly states the verb 'list' and the resource 'tables and column schemas on a DataCanvas', referencing the specific staging tool. It distinguishes from sibling by indicating it should be called before fema_dataframe_query.
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 instructs to call this before fema_dataframe_query to discover table/column names and types, and advises checking the 'truncated' field in the prior response. Provides clear when and how to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fema_dataframe_queryQuery FEMA DataCanvas TableARead-onlyIdempotentInspect
Run a read-only SQL SELECT against a DataCanvas table staged by fema_search_nfip. Enables aggregation, GROUP BY, SUM/COUNT, time-series, and filtered analysis over the full NFIP claims result without re-fetching from the API. Call fema_dataframe_describe first to get the exact table name and column names needed for valid SQL. Only SELECT statements are allowed — DDL, DML, COPY, and file-reading functions are blocked.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | SQL SELECT statement to run against the staged table. Use the table name from fema_dataframe_describe. Results are capped at the canvas row limit; append LIMIT/OFFSET to page through additional rows, or aggregate (GROUP BY, COUNT, SUM) to summarize the full set in one query. Example: "SELECT year_of_loss, COUNT(*) AS claims, SUM(amount_paid_building) AS total_building_paid FROM df_nfip_abc123 GROUP BY year_of_loss ORDER BY year_of_loss" | |
| canvas_id | Yes | Canvas ID from the fema_search_nfip response (the canvas_id field). |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The canvas row limit that was applied when the result was capped. |
| rows | Yes | Result rows from the query. May be capped at the canvas row limit — when the truncated enrichment field is set, page the remainder with LIMIT/OFFSET (see the notice guidance). |
| shown | No | Number of rows returned in this (capped) response. |
| notice | No | Continuation guidance when capped — how to page the remainder with LIMIT/OFFSET. |
| canvas_id | Yes | Canvas ID that was queried — reuse for follow-up queries. |
| row_count | Yes | Number of rows in this response (may be capped at the canvas row limit). |
| truncated | No | True when the result was capped at the canvas row limit — more rows match than were returned. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by explicitly stating that DDL, DML, COPY, and file-reading functions are blocked, and notes that results are capped at the canvas row limit. No contradiction with annotations.
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?
The description is two paragraphs with an example, well-structured and front-loaded. It is not overly verbose, but could be slightly trimmed without losing clarity. The example adds value but consumes space.
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?
With an output schema present, the description does not need to explain return values. It covers behavioral constraints (read-only, blocked operations), prerequisites (call describe first), and usage patterns (paging, aggregation). The tool is complex but the description is complete.
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?
Schema coverage is 100%, but the description enriches meaning significantly with an example query, explanation of how to obtain the table name from fema_dataframe_describe, and paging/aggregation hints. This goes well beyond the schema alone.
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?
The description clearly states the tool runs a read-only SQL SELECT against a DataCanvas table staged by fema_search_nfip. It specifies the exact verb and resource, and distinguishes itself from siblings like fema_dataframe_describe (which retrieves metadata) and other query 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?
Explicit guidance is provided: call fema_dataframe_describe first to get table/column names, and only SELECT statements are allowed. It also advises on paging with LIMIT/OFFSET and using aggregation for full-set analysis, giving clear when-to-use and how-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fema_get_disasterGet FEMA Disaster DetailsARead-onlyInspect
Fetch all designated-area rows for a specific FEMA disaster by disaster number (e.g., 4781). Returns every county/municipality designated under the declaration along with programs activated, incident period, and state info. Use fema_search_disasters to find disaster numbers. The returned disaster_number chains to fema_get_public_assistance and fema_get_housing_assistance.
| Name | Required | Description | Default |
|---|---|---|---|
| disaster_number | Yes | FEMA disaster number (e.g., 4781). Obtain from fema_search_disasters. |
Output Schema
| Name | Required | Description |
|---|---|---|
| state | Yes | Two-letter state/territory code. |
| title | Yes | Official declaration title (e.g., "SEVERE STORMS AND FLOODING"). |
| hm_declared | Yes | True when Hazard Mitigation grants were declared. |
| ia_declared | Yes | True when the Individuals and Households Program (IHP) was declared — indicates IA housing/personal grants are available. |
| pa_declared | Yes | True when Public Assistance (infrastructure recovery grants) was declared. |
| incident_type | Yes | Type of incident (e.g., Flood, Hurricane, Severe Storm). |
| disaster_number | Yes | FEMA disaster number — use as the chain key for PA and housing assistance tools. |
| declaration_date | Yes | ISO 8601 date the declaration was signed. |
| declaration_type | Yes | Declaration type: DR (major disaster), EM (emergency), or FM (fire management). |
| designated_areas | Yes | All counties/municipalities designated for assistance under this declaration. |
| incident_end_date | No | ISO 8601 end date of the incident. Absent for ongoing or unrecorded incidents. |
| incident_begin_date | No | ISO 8601 start date of the incident. Absent when not recorded. |
| designated_area_count | Yes | Total number of designated areas in this declaration. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, so the description's claim of 'fetch' aligns. Description adds that it returns 'every county/municipality designated under the declaration along with programs activated, incident period, and state info', which is useful context beyond annotations. However, it does not disclose potential behaviors like pagination, error handling for invalid numbers, or performance characteristics for large disasters.
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?
Two sentences, zero wasted words. First sentence states the core purpose with a concrete example. Second sentence provides immediate usage guidance and chaining context. Every sentence earns its place.
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 the tool's simplicity (one optional parameter, read-only, output schema provided), the description covers the essential aspects: what it returns, how to get input, and how to use the output. It does not mention error cases, but the output schema and runtime may handle that. Overall, it is sufficiently complete for an agent to invoke correctly.
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?
Schema has 100% coverage for the single required parameter 'disaster_number'. Description adds an example (e.g., 4781) and states to obtain from fema_search_disasters, providing meaningful guidance beyond the schema's description. This elevates the score above the baseline of 3.
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?
Description clearly states verb 'fetch' and resource 'designated-area rows for a specific FEMA disaster', with a concrete example (disaster number 4781). It distinguishes from sibling tools like fema_search_disasters (which finds disaster numbers) and fema_get_public_assistance/fema_get_housing_assistance (which chain from the result).
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 first use fema_search_disasters to obtain the disaster number, and indicates that the returned disaster_number can chain to fema_get_public_assistance and fema_get_housing_assistance. It does not explicitly state when not to use this tool, but the context is clear: use when you have a specific disaster number.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fema_get_housing_assistanceGet FEMA Housing Assistance DataARead-onlyInspect
Retrieve Individual Assistance (IA) housing data for a disaster by disaster number. Returns owner and/or renter breakdowns by county and ZIP code — valid registrations, total approved IHP amounts, repair/rental amounts, and inspection data. Use type to select owners, renters, or both (default). Use disaster_number from fema_search_disasters.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Which housing assistance dataset to query: owners, renters, or both (default). | both |
| limit | No | Maximum records per dataset to return (default 100). | |
| state | No | Two-letter state code to narrow results when a disaster spans multiple states. | |
| offset | No | Pagination offset (default 0). | |
| disaster_number | Yes | FEMA disaster number. Obtain from fema_search_disasters. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no results were found. |
| owners | Yes | Homeowner (HousingAssistanceOwners) records. Empty when type is "renters" or no owner data exists. |
| renters | Yes | Renter (HousingAssistanceRenters) records. Empty when type is "owners" or no renter data exists. |
| totalCount | No | Total owner + renter records available before the per-dataset limit — exceeds the returned count when either dataset was capped. |
| owners_count | Yes | Total owner records available before the per-dataset limit. |
| renters_count | Yes | Total renter records available before the per-dataset limit. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation on external data. The description adds specific behavioral context about returned fields (valid registrations, IHP amounts, repair/rental amounts, inspection data), which is valuable beyond the annotations. No contradictions.
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?
Two sentences front-load the core purpose and output, then parameter hints. Every clause adds value, no 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 the presence of an output schema and annotations covering readOnly/openWorld, the description is fairly complete. It covers key return fields and parameter usage. However, it does not explicitly mention pagination behavior (offset, limit) or potential limitations, though these are covered in the schema.
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?
With 100% schema description coverage, the schema already documents all 5 parameters. The description adds marginal value by reinforcing that 'type' selects owners/renters and that disaster_number comes from fema_search_disasters. This is helpful but not transformative beyond the schema's own descriptions.
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?
The description clearly states the action 'Retrieve', the resource 'Individual Assistance housing data for a disaster by disaster number', and details the returned data (breakdowns by county/ZIP, registrations, amounts, inspection data). It references the sibling tool fema_search_disasters for getting the disaster number, distinguishing it from related tools like fema_get_disaster or fema_get_public_assistance.
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?
The description provides context on how to get the disaster_number and select data type, but does not explicitly state when to use this tool versus alternatives like fema_get_disaster for raw disaster info or fema_get_public_assistance for public assistance data. The guidance is clear but lacks exclusionary or comparative statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fema_get_public_assistanceGet FEMA Public Assistance ProjectsARead-onlyInspect
Retrieve Public Assistance (PA) funded project records for a disaster or state — shows where federal recovery money was obligated. Returns applicant, damage category, project size and status, federal share obligated, and total obligated amounts. Either disaster_number or state must be provided. Use disaster_number (from fema_search_disasters) to scope to a single declaration, or state to browse all PA projects for a state. PA projects are created only when the PA program is declared (pa_declared: true on the disaster).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of projects to return (1–1000, default 100). | |
| state | No | Two-letter state code to browse all PA projects for a state. | |
| county | No | Filter by county name substring. | |
| offset | No | Pagination offset (default 0). | |
| disaster_number | No | FEMA disaster number to scope results to a single declaration. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no results were found. |
| projects | Yes | Public assistance funded project records. |
| totalCount | No | Total matching projects before pagination — exceeds returned_count when results were capped at the limit. |
| total_count | Yes | Total matching projects before pagination. |
| returned_count | Yes | Number of projects in this response. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. Description adds behavioral context by stating the tool shows 'where federal recovery money was obligated' and listing return fields. Does not contradict annotations.
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?
Four well-structured sentences, front-loaded with the core purpose, no superfluous words. Every sentence serves a clear function.
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 5 parameters (none required), output schema exists, and high schema coverage, the description provides sufficient context for usage, data returned, and relationships. Could mention pagination details (offset/limit) but those are in schema.
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?
Schema coverage is 100%. Description adds crucial semantics: clarifies that disaster_number or state must be provided (mutual exclusivity), explains the origin of disaster_number, and notes county filter is a substring search. Adds significant value beyond schema descriptions.
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 Public Assistance project records for a disaster or state, and specifies the exact data fields returned (applicant, damage category, project size/status, federal share, total obligated). Differentiates from sibling tools by referencing disaster_number from fema_search_disasters and the pa_declared: true condition.
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 guidance on when to use disaster_number vs state, and notes that PA projects exist only when pa_declared: true. Lacks explicit when-not-to-use or alternatives, but contextual cues are strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fema_query_datasetQuery Any OpenFEMA DatasetARead-onlyInspect
Generic OData query against any OpenFEMA v2 dataset — the escape hatch for datasets the convenience tools do not cover (e.g., FimaNfipPolicies, IndividualAssistanceHousingRegistrantsLargeDisasters, FemaWebDeclarationAreas, PublicAssistanceApplicants). Accepts raw OData filter, select, orderby, and pagination parameters. For NFIP Policies, use propertyState (not state) as the state field — always include a county or ZIP filter to avoid timeout. The dataset name must match the exact OpenFEMA v2 entity name (case-sensitive, e.g., FimaNfipClaims). Unknown dataset names return an unknown_dataset error.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum records to return (1–10000, default 100). | |
| filter | No | OData $filter expression (e.g., "state eq 'TX' and declarationDate ge '2024-01-01T00:00:00.000Z'"). String values in single quotes. | |
| offset | No | Pagination offset (default 0). | |
| select | No | Comma-separated field names to return (e.g., "disasterNumber,state,declarationDate"). | |
| dataset | Yes | OpenFEMA v2 dataset entity name (case-sensitive, e.g., FimaNfipPolicies, FemaWebDeclarationAreas, PublicAssistanceApplicants). | |
| orderby | No | OData $orderby expression (e.g., "declarationDate desc"). |
Output Schema
| Name | Required | Description |
|---|---|---|
| rows | Yes | Records returned from the dataset. Field names depend on the queried dataset. |
| notice | No | Guidance when no results were found. |
| dataset | Yes | The dataset that was queried. |
| totalCount | No | Total matching records before pagination — exceeds returned_count when results were capped at the limit. |
| total_count | Yes | Total matching records before pagination. |
| returned_count | Yes | Number of records in this response. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses critical behavioral traits: raw OData parameter acceptance, timeout risk without filtering, case-sensitive dataset names, and the exact error for unknown datasets. This adds significant context for safe invocation.
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?
The description is a single, dense paragraph that efficiently conveys the core purpose, usage guidance, and important warnings. Every sentence is meaningful, though it could benefit from slightly more structured formatting (e.g., bullet points) for readability. Nevertheless, it is concise and front-loaded.
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 the tool's generic nature and the existence of an output schema, the description covers all essential aspects: what it does, when to use it, how to avoid common pitfalls (timeout, case sensitivity, error handling), and parameter usage. It is comprehensive for an escape hatch tool.
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?
With 100% input schema coverage, the schema already documents parameters well. The description adds value by explaining the OData nature of filter, select, and orderby, providing usage examples, and warning about propertyState for NFIP datasets. This enriches understanding beyond the schema.
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?
The description clearly states it performs a generic OData query against any OpenFEMA v2 dataset, explicitly positioning it as an escape hatch for datasets not covered by convenience tools like fema_search_nfip or fema_get_disaster. It provides specific dataset examples and distinguishes its role from sibling 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?
The description explicitly tells when to use this tool (for datasets not covered by convenience tools) and when not to (e.g., for NFIP Policies it advises using propertyState and including county or ZIP filters to avoid timeout). It provides clear context and alternative tools, making it easy for an AI agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fema_search_disastersSearch FEMA Disaster DeclarationsARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of unique disaster declarations to return (1–1000, default 50). | |
| state | No | Two-letter US state/territory code (e.g., TX, CA, FL, PR). Filters by state. | |
| county | No | Filter by designated area / county name substring (e.g., Harris, Los Angeles). Case-insensitive. | |
| offset | No | Pagination offset in declarations (default 0). Use with limit to page through results. | |
| date_to | No | End of declaration date range in ISO 8601 format (e.g., 2024-12-31). Inclusive. | |
| date_from | No | Start of declaration date range in ISO 8601 format (e.g., 2024-01-01). Inclusive. | |
| incident_type | No | Incident type filter (e.g., Flood, Hurricane, Tornado, Fire, Earthquake, Severe Storm). Case-insensitive substring match. | |
| declaration_type | No | Declaration type: DR (major disaster declaration), EM (emergency declaration), FM (fire management assistance declaration). |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no results were found. |
| totalCount | No | Total unique disaster declarations matching the query — the unit declaration-level pagination pages over. Exceeds returned_count when the matches span more than one page. |
| declarations | Yes | Disaster declarations matching the search, one entry per unique disaster number. |
| returned_count | Yes | Number of unique deduplicated declarations in this response. |
| total_area_rows | Yes | Total 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_declarations | Yes | Total 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds important behavioral details beyond annotations: deduplicated summaries with designatedAreaCount. Annotations already indicate read-only and open-world, so description complements well.
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?
Five well-structured sentences, each adding unique value. Front-loaded with the core function and filters, no waste.
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 8 parameters, 100% schema coverage, output schema exists, and sibling context, the description completely covers what an agent needs: filters, pagination, interpretation of results, and linkage to other tools.
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?
Schema coverage is 100%, so baseline 3. The description adds context for declaration_type values and the role of disaster number as a chain key, providing additional meaning beyond parameter names.
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?
The description clearly states the tool's purpose: 'Search federal disaster declarations' with specific filter criteria (state, incident type, etc.). It distinguishes from sibling tools by noting the disaster number as a chain key for related 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 explicit guidance on using declaration_type filter and date filters, and directs users to fema_get_disaster for detailed rows. Lacks explicit 'when not to use' but context from siblings is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fema_search_nfipSearch NFIP Flood Insurance ClaimsARead-onlyInspect
Search National Flood Insurance Program (NFIP) claims data by state, county, ZIP code, and year range. Returns claim counts, amounts paid on building and contents, flood zones, and loss years. state is required — the full NFIP dataset is 2.7 million rows; unfiltered access is prohibited. When DataCanvas is enabled (CANVAS_PROVIDER_TYPE=duckdb) and results exceed the inline preview, the full result set is staged on a canvas for SQL aggregation via fema_dataframe_query. Use fema_dataframe_describe to inspect the staged table schema before writing SQL. Without canvas, results are returned inline up to the limit.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum claim rows to return in the inline preview (1–10000, default 1000). When DataCanvas is enabled, the canvas stages the full matching result set regardless of this value. | |
| state | Yes | Two-letter US state code (required). NFIP dataset is 2.7M rows — state filter is mandatory. | |
| year_to | No | End year of loss, inclusive (e.g., 2023). | |
| zip_code | No | ZIP code to narrow results to a specific area (5-digit, e.g., 77002). | |
| canvas_id | No | Optional canvas ID from a prior call. Omit to create a fresh canvas. The response returns the canvas_id to pass to fema_dataframe_query. | |
| year_from | No | Start year of loss, inclusive (e.g., 2020). | |
| county_code | No | County code to narrow results within the state. Accepts the full 5-digit state+county FIPS (e.g., 48201 for Harris County TX) or the 3-digit county portion (e.g., 201) when state is provided — the server prepends the state FIPS automatically. |
Output Schema
| Name | Required | Description |
|---|---|---|
| claims | Yes | Inline preview of claim records (first N rows). Full dataset available via canvas_id when spilled=true. |
| notice | No | Guidance on canvas usage or result scope. |
| spilled | Yes | True when the full result set was staged on DataCanvas; use canvas_id + fema_dataframe_query for SQL analysis. False when all results fit inline. |
| canvas_id | No | Canvas ID for the staged full result set. Pass to fema_dataframe_query and fema_dataframe_describe. Present only when spilled=true. |
| truncated | No | True when the canvas row cap (50,000) was reached before the full matching set was staged — the canvas holds a partial result. Apply tighter filters (county_code, zip_code, year range) to stage the complete set. |
| total_count | Yes | Total matching claims in the filtered dataset before the limit. |
| canvas_table | No | DuckDB table name on the canvas holding all fetched rows. Reference in SQL FROM clauses. Present when spilled=true. |
| returned_count | Yes | Number of claim records in the inline preview. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds crucial behavioral details: the mandatory state filter, the dataset size (2.7M rows), the inline preview limit, and the canvas staging behavior when DataCanvas is enabled. No contradictions with annotations.
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?
The description is well-structured: starts with a clear one-sentence summary, then explains the required state and dataset size, followed by DataCanvas integration and references to sibling tools. Every sentence adds value 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?
Given the tool's complexity (7 parameters, DataCanvas integration, output schema exists), the description is thorough. It covers filtering options, inline vs. staged results, and the recommended workflow with fema_dataframe_describe and fema_dataframe_query. No gaps for an AI agent.
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?
Schema coverage is 100%, so the schema already documents all parameters with descriptions. The tool description adds minimal extra meaning beyond reinforcing required state and mentioning county_code accepts two formats. Baseline 3 is appropriate.
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?
The description clearly states it searches NFIP claims data by state, county, ZIP, and year range. It uses specific verbs and resource names, and distinguishes itself from sibling tools like fema_dataframe_describe and fema_dataframe_query by explaining the staging behavior and interaction.
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 says state is required and unfiltered access is prohibited due to dataset size. Provides guidance on when to use DataCanvas staging vs. inline results, and references sibling tools for inspection and SQL querying. This gives clear context for when to use this tool vs. alternatives.
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!