Skip to main content
Glama

usaspending-mcp-server

by io.github.cyanheads

Get Federal Account Breakdown

usaspending_get_federal_account_breakdown
Read-onlyIdempotent

Fetch a federal account's obligations broken down by program activity (what the money funds) or object class (what it buys — personnel, supplies, contracts). Use the dimension parameter to select the axis. Account codes are AGENCY-MAIN format and come from usaspending_search_federal_accounts (its account_number output field), usaspending_get_award_federal_accounts (its federal_account field), or usaspending_get_federal_account. Paginated with an honest total count. For the account's own metadata and top-level totals, use usaspending_get_federal_account.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number (1-based)
limitNoMaximum results per page (1–100)
dimensionYesBreakdown axis: program_activity (obligations by the program the funds support) or object_class (obligations by the category of goods/services purchased)
account_codeYesFederal account code in AGENCY-MAIN format (e.g., 097-0100). Returned as account_number by usaspending_search_federal_accounts and as federal_account by usaspending_get_award_federal_accounts.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
noticeNoRecovery hint when results are empty — the account code may not exist or may have no obligations on this axis. Absent when results are present.
resultsNoBreakdown rows for the requested dimension
dimensionNoBreakdown dimension returned
totalCountNoTotal number of breakdown rows across all pages (when available)
account_codeNoFederal account code queried
current_pageNoCurrent page returned
has_next_pageNoWhether there are more pages of breakdown rows
page_metadataNoPagination metadata
applied_dimensionNoBreakdown dimension applied

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context: pagination with an 'honest total count' and the axis options. This exceeds the minimal bar set by the annotations.

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 of dense, front-loaded content. The purpose comes first, alternatives are embedded, and no filler exists. 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?

Given the presence of a complete schema (100% coverage), an output schema for return shape, and annotations covering safety, the description covers the remaining context: pagination behavior, total count, and routing to the correct sibling tool. Nothing an agent needs to call it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the distinction between the two dimension values and mentions the account_code format and source tools, but this information is largely duplicated in the schema's property descriptions. No new semantic detail is added beyond what the schema already provides.

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 ('Fetch a federal account's obligations') and immediately defines the two breakdown axes, distinguishing this from siblings. It also names the alternative tool for metadata/totals, making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use this tool (for breakdown by dimension) and when not to ('For the account's own metadata and top-level totals, use usaspending_get_federal_account'). It also tells the agent exactly where to obtain account codes from three sibling tools, leaving no ambiguity about prerequisites.

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