Skip to main content
Glama

KeyVex

get_federal_contracts

Read-only

Returns federal contract awards from USAspending.gov — government spending data sourced from Treasury/GSA. Each record is one prime contract award (BPA Call, Purchase Order, Delivery Order, or Definitive Contract). Modifications appear as separate records. Use this when the user asks about: who's getting federal contracts, how much a specific recipient (Lockheed Martin, RTX, Raytheon, Booz Allen, etc.) won this year/quarter, contracts by industry (NAICS code) or product type (PSC code), or to cross-reference congressional trading with contract awards. Cross-source pattern (the political-alpha play): 1. get_congressional_trades(ticker:'LMT', since:'2026-01-01') — find LMT trades by members of Congress. 2. get_federal_contracts(recipient_name:'Lockheed Martin', since:'2026-01-01') — find LMT contract awards. 3. Compare timing — trades within 30 days before a major contract are the high-signal cases. ⚠ award_amount and total_outlays are NULLABLE, and total_outlays is null on MOST rows. USAspending omits Total Outlays from the search response about 75% of the time, and this tool now reports that as null rather than as $0 — a 0 here means the source really said zero. Do not do arithmetic on either field without a null check. Rows with a null value are excluded from min_amount filters and sort LAST, because a value we do not have cannot satisfy a threshold. recipient_name is a case-insensitive substring match — use the parent name ('Lockheed Martin') to catch all subsidiaries. COVERAGE — live passthrough (source:'live'): each call queries USAspending's API over the full dataset (2007-10 onward), with recipient/NAICS/PSC/min-amount/date filters applied server-side. The response's total_count is USAspending's authoritative award 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 awards), 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. 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
limitNoMaximum records to return. Default 50, max 500.
sinceNoISO date (YYYY-MM-DD). Only records on or after this date — on last_modified_date, except when sort_by is start_date, where it applies to start_date.
untilNoISO date (YYYY-MM-DD). Only records on or before this date (the same date field as since).
sort_byNoField used for ordering. since/until apply to start_date when this is start_date, and to last_modified_date for every other sort. Default: last_modified_date (most-recently-modified first).
psc_codeNoProduct or Service Code (4-character). Example: 'AR33' (R&D Space Flight Advanced Development). Exact match.
min_amountNoFilter to awards with award_amount >= this value (USD). Use to focus on large contracts.
naics_codeNo6-digit North American Industry Classification System code. Example: '541710' (R&D in Physical/Engineering/Life Sciences). Exact match.
sort_orderNoDefault: desc.
recipient_ueiNoUnique Entity Identifier (replaced DUNS in 2022). 12-character alphanumeric. Exact match: only awards made to this UEI itself. If it is also the parent of other recipients, their awards are NOT included and total_count is omitted — coverage_warning names the parent; use recipient_name with that name for the whole family.
recipient_nameNoRecipient name substring; case-insensitive match. Example: 'Lockheed Martin' matches 'LOCKHEED MARTIN CORP', 'LOCKHEED MARTIN MISSILES AND FIRE CONTROL', etc. USAspending also matches the PARENT company's name, so a parent name returns its subsidiaries' awards (e.g. Sikorsky under 'Lockheed Martin'). Combined with recipient_uei it is matched against that recipient's OWN name instead, and coverage_warning says how many awards it removed.
awarding_agencyNoThe TOPTIER awarding agency name — exact and case-sensitive; a sub-agency name (e.g. 'Defense Logistics Agency') or an abbreviation ('NASA') matches nothing. Examples: 'Department of Defense', 'National Aeronautics and Space Administration', '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; the description goes far beyond by disclosing that award_amount and total_outlays are nullable (with a ~75% null rate), that nulls are excluded from min_amount and sort last, that total_count is omitted under specific conditions with coverage_warning, and that outages fall back to a cached window where volume must not be inferred. This is exactly the behavioral context annotations cannot carry.

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 usage, then the cross-source recipe, then the caveat block — good ordering and no filler sentences. It is long, and the numbered political-alpha recipe is more verbose than strictly needed, but each section still carries usable information.

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?

For an 11-parameter tool with no output schema, the description covers return semantics (total_count as the authoritative count, results as just a page, has_more) and the failure modes (coverage_warning, cache fallback). An agent has enough to answer volume questions correctly without guessing.

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 parameters are already documented, but the description adds real meaning: recipient_name's parent/subsidiary expansion, the recipient_uei-as-parent edge case, and the interaction where null values are dropped from min_amount filtering. It reinforces rather than merely repeats the schema.

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 ('Returns federal contract awards from USAspending.gov'), defines the record granularity (one prime contract award, modifications as separate records), and implicitly separates itself from siblings like get_federal_grants by naming the source and award types.

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 an explicit 'Use this when the user asks about' list covering recipient, NAICS/PSC, and cross-reference scenarios, plus a concrete cross-source workflow naming the sibling get_congressional_trades and the 30-day timing heuristic. Nothing about when to reach for it is left to inference.

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