USASpending.gov

get_award_count

Read-only

Count awards matching filters, broken down by award category.

Returns counts grouped by: contracts, idvs, grants, loans, direct_payments, other.
Use this for dimensional analysis: how many FFP vs T&M awards, how many
competed vs sole-source, how many small business set-asides, etc.

Unlike search_awards, this returns total counts across ALL award categories
in a single call (not just the one specified in award_type). The award_type
parameter is ignored here; filters apply to the count query directly.

def_codes filters to Disaster Emergency Fund codes; see
get_def_codes_reference().

At least one filter is required (the API rejects empty filter sets with HTTP 400).
Typical usage: pass time_period_start + time_period_end, or a keywords/agency filter.

date_type controls the award date window. Omitted (the default),
the latest action must be on/after the window start and the first signing
on/before its end. This interval overlap does NOT prove an action occurred
inside the window. For actual dated actions use spending_by_transaction,
read every page, and deduplicate award identifiers for distinct awards;
get_transactions provides a discovered award's complete action history.
'action_date' bounds the latest action, not any action; 'date_signed'
bounds first signing; 'last_modified_date' bounds the latest update.
'new_awards_only' keeps awards first signed in the window.
date_type needs time_period_start and/or time_period_end.

program_numbers filters assistance awards by assistance listing (CFDA)
number, e.g. ['93.778'] for Medicaid; use it with award_type='grants',
'loans', 'direct_payments', or 'other'. autocomplete_cfda() finds numbers
by program name.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_award_count"
  }
}

Input Schema

Name	Required	Default
`keywords`	No
`date_type`	No
`def_codes`	No
`psc_codes`	No
`award_type`	No	contracts
`naics_codes`	No
`funding_agency`	No
`recipient_name`	No
`awarding_agency`	No
`program_numbers`	No
`time_period_end`	No
`award_amount_max`	No
`award_amount_min`	No
`time_period_start`	No
`awarding_subagency`	No
`set_aside_type_codes`	No
`extent_competed_type_codes`	No
`place_of_performance_state`	No
`contract_pricing_type_codes`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations cover safety (readOnly, openWorld, non-destructive), and the description adds real behavioral context beyond them: the empty-filter HTTP 400 rejection, that award_type is silently ignored here, and a substantive caveat that date_type's interval overlap does NOT prove an action occurred inside the window, plus pointers to spending_by_transaction / get_transactions for that case. That is unusually valuable disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, output shape, and sibling contrast before the detailed filter mechanics. The date_type paragraph is dense and run-on (interval-overlap caveat plus four mode definitions in one block), but every sentence carries information an agent needs; nothing is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 19-parameter read-only counting tool with an output schema, the description covers the pitfalls (filter requirement, ignored award_type, date semantics) and cross-references the right helper tools. It is nearly complete; the gap is undisclosed semantics for the remaining code-list filters, which the agent must infer or resolve via autocomplete tools.

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 description coverage is 0% across 19 params, so the description must carry the load, and it does for the hardest ones: date_type enumerated modes are each explained, program_numbers gets a concrete CFDA example plus which award_types accept it, def_codes points to get_def_codes_reference. Remaining filters (naics_codes, psc_codes, set_aside_type_codes, extent_competed_type_codes, contract_pricing_type_codes, place_of_performance_state, award amount bounds) are left to intuition and autocomplete siblings, so it falls short of full compensation.

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?

States a specific verb+resource ('Count awards matching filters') and the exact output shape (counts grouped by contracts, idvs, grants, loans, direct_payments, other). It explicitly contrasts itself with search_awards and clarifies that award_type is ignored, so an agent can distinguish it from siblings without opening a schema.

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?

Gives concrete when-to-use framing ('dimensional analysis: how many FFP vs T&M, competed vs sole-source, small business set-asides'), names the alternative tool and why it differs, and states a hard precondition: at least one filter or the API returns HTTP 400, with a typical usage pattern (time_period_start + time_period_end or keywords/agency).

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

All USASpending.gov tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.