Skip to main content
Glama

KeyVex

get_federal_grants

Read-only

Returns federal GRANTS and cooperative agreements from USAspending. Distinct universe from get_federal_contracts — recipients here are universities, non-profits, state and local agencies, research labs, healthcare institutions, public-private partnerships. ⚠ award_amount and total_outlays are NULLABLE. USAspending omits Total Outlays from the search response for most grants, and this tool reports that as null rather than as $0 — a 0 means the source really said zero. Null-check before doing arithmetic. Null values never satisfy min_amount and sort last. Award type codes covered: 02 (Block Grant), 03 (Formula Grant), 04 (Project Grant — most common), 05 (Cooperative Agreement). Killer query patterns: - All NIH R01 grants this quarter: cfda_number='93.847' + since=... - State and local infrastructure funding: awarding_agency='Department of Transportation' + min_amount=1000000 - Recipient-specific grant history: recipient_name='Stanford' - Recipient by federal UEI: recipient_uei='ABC123XYZ' (most precise) Source: api.usaspending.gov — official Treasury federal-spending data. Awards covering both COVID/IIJA emergency-funding codes and routine appropriations. Pure-publisher posture: raw award data, no derived rankings or performance scores. COVERAGE — live passthrough (source:'live'): each call queries USAspending's API over the full dataset (2007-10 onward), with recipient/CFDA/min-amount/date filters applied server-side. The response's total_count is USAspending's authoritative grant count for your filtered query — USE IT for volume answers (the results array is just the requested page). total_count is omitted — and coverage_warning says why — when USAspending cannot count the answer: a recipient_uei that is also the PARENT of other recipients (USAspending cannot filter to one UEI's own grants), recipient_name combined with recipient_uei, or a start_date window (sort_by start_date with since/until). Then has_more is true whenever the search stopped before the end. Note: live cfda_number matching is against the award's FULL assistance-listings array (awards can carry several CFDAs); the cached fallback matches the primary listing only. On USAspending outage the tool falls back to a recent cached window (source:'cache' + coverage_warning) — don't infer volume there.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax records. Default 50, max 500.
sinceNoInclusive lower bound (YYYY-MM-DD) on last_modified_date — or on start_date when sort_by is start_date.
untilNoInclusive upper bound (YYYY-MM-DD), on the same date field as since.
sort_byNoSort key. since/until apply to start_date when this is start_date, and to last_modified_date for every other sort. Default: last_modified_date.
min_amountNoInclusive lower bound on award_amount in dollars.
sort_orderNoDefault: desc.
cfda_numberNoCatalog of Federal Domestic Assistance program number (e.g., '93.847' = NIH R01 research grants, '20.939' = highway safety improvement). Filter to one program.
recipient_ueiNoExact federal UEI (Unique Entity ID) — most precise: only grants made to this UEI itself. If it is also the parent of other recipients, their grants are NOT included and total_count is omitted — coverage_warning names the parent; use recipient_name with that name for the whole family.
recipient_nameNoCase-insensitive substring on the recipient's name (e.g., 'Stanford', 'Mayo Clinic'), applied by USAspending — which also matches the PARENT's name, so a parent name returns its subsidiaries' grants. Combined with recipient_uei it is matched against that recipient's OWN name instead, and coverage_warning says how many grants it removed.
awarding_agencyNoThe TOPTIER awarding agency name — exact and case-sensitive; a sub-agency name (e.g. 'National Institutes of Health') or an abbreviation ('NSF') matches nothing. Examples: 'National Science Foundation', 'Department of Energy', 'Department of Health and Human Services'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnly/openWorld/non-destructive, but the description discloses far more: award_amount and total_outlays are nullable, nulls mean 'source omitted' rather than $0, nulls never satisfy min_amount and sort last, and total_count may be omitted with a coverage_warning under specific filter combinations. It also explains the live-vs-cache passthrough and the fallback posture on outage, none of which is derivable from 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.

Conciseness4/5

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

Front-loads purpose, then behavior, then query patterns, then coverage semantics, so the agent can stop reading early. It is long, and details like the award-type code enumeration and source posture are helpful but not strictly load-bearing for invocation, which keeps it just short of a 5.

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?

With no output schema, the description fully carries return-value semantics: total_count as the authoritative count, results as only the requested page, has_more meaning, and coverage_warning behavior. Combined with the nullable-field guidance, an agent has everything needed to interpret and use the response 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 the baseline is 3, but the description adds cross-parameter meaning beyond the schema: null handling relative to min_amount/sort, and that live cfda_number matches the full assistance-listings array while the cached fallback matches only the primary listing. These are real behavioral additions rather than restatements.

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 and resource ('Returns federal GRANTS and cooperative agreements from USAspending') and immediately distinguishes it from its closest sibling by naming get_federal_contracts and contrasting the recipient universe (universities, non-profits, agencies vs. contractors). An agent can route between the two without opening either 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 explicit query patterns (cfda_number='93.847' for NIH R01, awarding_agency + min_amount for infrastructure, recipient_uei for precision) and states exactly when to rely on total_count versus the results page. It also names the fallback condition (USAspending outage -> cached window) and warns not to infer volume there, which is genuine when-to-use guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources