Skip to main content
Glama

usaspending-mcp-server

by io.github.cyanheads

Disaster and Emergency Spending

usaspending_disaster_spending
Read-onlyIdempotent

Fetch disaster and emergency supplemental spending (COVID-19, hurricanes, infrastructure law, etc.) broken down by agency, CFDA assistance program, recipient, or geography. Use the dimension parameter to select the breakdown axis: overview (top-level totals), agency, cfda, recipient, or geography. Filter by DEF codes (Disaster/Emergency Funding codes) to isolate a specific emergency appropriation. DEF codes appear in usaspending_get_award account_obligations_by_defc and usaspending_get_agency def_codes fields.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number (1-based)
limitNoMaximum results per page (1–100). Applies to the agency, cfda, and recipient dimensions; ignored for overview and geography, which are not paginated.
filtersNoFilters — def_codes is required for all non-overview dimensions (agency, cfda, recipient, geography)
dimensionYesBreakdown axis: overview (top-level totals and DEF code funding), agency (by awarding agency), cfda (by assistance program), recipient (by recipient), geography (by state/county)
spending_typeNoData type for the agency and recipient dimensions: award (award-level obligations and outlays) or total (includes direct non-award spending). Ignored for cfda and overview; the geography dimension is not user-controllable and always reports obligation-based amounts.award

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
capNoThe result-set ceiling the upstream applied.
errorNoPresent when the call failed. Absent on success.
shownNoNumber of results returned on this page.
noticeNoCaveat explaining a capped total and how to bring the set under the cap.
resultsNoBreakdown results (empty for overview dimension)
overviewNoTop-level overview totals (dimension=overview only)
dimensionNoBreakdown dimension returned
truncatedNoTrue when the upstream capped the reachable result set rather than counting it.
totalCountNoTotal items for paginated dimensions (when available)
current_pageNoCurrent page (non-overview dimensions)
has_next_pageNoWhether there are more pages
page_metadataNoPagination metadata (non-overview dimensions)
spending_typeNoData type returned — award/total for agency, cfda, and recipient; obligation for geography; spending for overview
applied_dimensionNoBreakdown dimension applied

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds minimal behavioral context—mentioning DEF codes and pointing to other tools for those codes—but does not describe return formats, pagination nuances, or any side effects beyond what annotations and schema already imply. Since annotations carry the burden, a 3 is appropriate.

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?

Three sentences with no redundancy. The primary purpose is front-loaded, dimension options are listed compactly, and DEF code rationale is explained efficiently. Every sentence earns its place.

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?

The description is complete given the rich schema (100% coverage) and the presence of an output schema. It covers the main decision points (dimension, DEF codes) and provides cross-references. The schema handles all parameter details, so nothing critical is missing for an agent to invoke this tool correctly.

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 baseline is 3. The description adds value by explaining the semantic purpose of the dimension parameter and DEF codes, including examples of actual codes and how to use them. This goes slightly beyond the schema's per-parameter descriptions, elevating the score to 4.

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 clearly states the tool fetches disaster/emergency supplemental spending and lists the breakdown axes (overview, agency, cfda, recipient, geography). It provides concrete examples (COVID-19, hurricanes, infrastructure law) and names the specific domain, distinguishing it from other spending-related tools in the sibling list.

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 implies usage for disaster/emergency spending scenarios and explains how to select dimensions and filter by DEF codes. However, it does not explicitly contrast with sibling tools (e.g., when to use this vs. usaspending_spending_by_category) or state exclusions, so some inference is required.

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

All usaspending-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.3/5.0
Disambiguation5/5

Each tool targets a distinct entity or operation: agency, award, subaward, transaction, federal account, recipient, and various spending breakdowns. Even similar-sounding tools like get_award_federal_accounts vs get_federal_account are clearly separated by their core purpose (award funding sources vs account budget details).

Naming Consistency4/5

Almost all tools follow the usaspending_<verb>_<object> pattern (e.g., get_award, search_recipients). The spending_* series breaks the verb-noun convention but is internally consistent. Minor deviation lowers the score slightly.

Tool Count4/5

At 18 tools, this is on the higher end of reasonable but each tool maps to a distinct USAspending API endpoint and covers a different aspect of federal spending. The count is justified by the breadth of the domain, though it feels slightly heavy.

Completeness5/5

The surface covers award search/detail, agency navigation, federal accounts, recipients, subawards, transactions, IDVs, and multiple spending aggregations (category, geography, time, disaster). No obvious dead ends: all ID-producing tools have corresponding lookup tools, and common workflows like award→federal account→breakdown are fully supported.

Resources