MCP server for querying US federal spending data from api.usaspending.gov. Covers awards, agencies, recipients, spending breakdowns, disaster funding, federal accounts, and bulk downloads.
The USASpending MCP server provides 2 tools with reasonable structure, but falls short of production quality in several key areas. Tool names follow the query_ verb pattern (good), descriptions are present and moderately detailed (average 180-220 chars, within baseline 194 range), and input schemas are fully visible with proper JSON Schema typing. However, critical gaps in output schema documentation, missing parameter descriptions in some fields, and no error handling guidance significantly limit agent reasoning. The decision_tree/router.py module shows parameter validation awareness but this logic is not exposed as tool behavior or error recovery patterns. Elicitation support (building missing param schemas) is a positive sign but underutilized, tools should raise and recover from missing required params automatically. Overall composition is clean: each tool does one thing (query agency data, query account data), but output structure is undocumented, forcing LLMs to guess what fields to expect and how to chain calls.
Query federal and treasury account data. - With `federal_account_id`: returns account detail - With `treasury_account_symbol`: returns TAS breakdown - With neither: lists federal accounts
Query federal agency data — overview, budgets, sub-agencies, and more. Without a breakdown, returns the agency overview. With a breakdown, returns detailed data for that category.
Output schemas completely missing for both tools. LLM cannot infer response structure, must guess at field names for downstream tool calls or data extraction. Forces blind reasoning and increases hallucination risk.
Enums constrained in description text, not in JSON Schema. breakdown parameter in query_agency lists valid values as prose ('budgetary_resources, sub_agencies, ...') rather than enum constraint. breakdown in query_accounts omits values entirely. LLM cannot reliably discover or validate options.
query_accounts has three mutually exclusive modes but no schema constraint enforcing the rule. Parameter description states modes but does not say 'must provide exactly one of federal_account_id or treasury_account_symbol to list mode'. LLM could pass both IDs or neither, resulting in undefined behavior.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | 2025-06-18+ | v1 |
No error handling guidance. If agency_name not found, if fiscal_year is invalid, if breakdown type unsupported, tools provide no recovery suggestions. Error responses are not documented, forcing LLM to retry blindly.
Parameter descriptions exist but lack format/validation guidance. agency_name accepts both 'Department of Defense' and 'DOD' per description but no validation rules stated. fiscal_year 'defaults to current' but no range given. breakdown has typos or unclear semantics (e.g., does 'program_activities' mean active programs or their activity logs?).
No pagination documentation in descriptions. query_accounts accepts page/limit but does not state: typical result counts, recommended limit, whether list is sorted, or total result availability. Without this, LLM cannot plan multi-page queries.