USAspending Federal Contracts for AI Agents — Sub-Second Search

The US federal government awards roughly $700 billion in contracts every year, all of it disclosed at USAspending.gov. The data is open, the search interface is mature, and the API is well-documented — in theory it’s a perfect data source for AI agents researching federal vendors, contract opportunities, or who-won-what for any given technology stack.

In practice, integrating USAspending into an agent stack is harder than it should be. The live api.usaspending.gov endpoint silently hangs requests from Cloudflare Worker egress IPs (and probably others), and the underlying API returns enormous payloads when filter parameters don’t match the expected shape — meaning a single agent call can stall the worker until it gets killed. Pipeworx ran into both of these problems running the usaspending pack live, and after the third user bug report we rebuilt the search path so it no longer depends on that endpoint.

What changed

usa_award_search — by a wide margin the most-called tool in the pack — no longer calls the live API. What an agent gets instead:

• Sub-second responses for keyword queries that previously timed out at 30s
• Full-text search across contract descriptions and recipient names
• Filters on NAICS code, set-aside type, agency and date range, all indexed
• No egress failures — the query doesn’t depend on a third-party endpoint answering

Everything an agent sees is the same MCP tool with the same arguments. The reliability difference is the whole point: an agent that has to handle a 30-second hang on a routine lookup will stop making the lookup.

What an agent can ask

usa_award_search(
  keywords: ["cybersecurity"],
  limit: 5
)
→ [
    { recipient: "MAVERIS LLC", amount: 331158125.88,
      awarding_agency: "Department of Veterans Affairs",
      description: "VA CYBERSECURITY OPERATIONS CENTER NEXT GENERATION II..." },
    { recipient: "NTT DATA SERVICES FEDERAL GOVERNMENT, LLC", amount: 78781831.20,
      awarding_agency: "Department of Justice",
      description: "TITLE: CYBERSECURITY OPERATIONS - HACS REQUESTOR..." },
    ...
  ]

Typical query patterns:

• “What contracts has $VENDOR won?” — usa_award_search(keywords: ["Lockheed Martin"])
• “What does the government spend on $TOPIC?” — keyword search with start_date / end_date
• “Who are the top recipients in NAICS $CODE?” — filter by NAICS, aggregate by recipient
• “Recent awards under the SBA 8(a) set-aside” — filter by set_aside, sort by date

For higher-level analysis the govcon-intel compound pack glues usaspending together with samgov (live federal contract opportunities) and sbir (small business R&D grants) into single-call workflows — govcon_opportunity_scan, govcon_contractor_profile, govcon_agency_landscape.

Coverage and freshness

Search covers fiscal year 2020 onward — roughly 1.4 million contract transactions and growing — and refreshes monthly, about a week after USAspending publishes. Amendments and option exercises update the existing award rather than appearing as duplicates.

Coverage limits worth knowing:

• USPS is missing. The US Postal Service is an independent agency that contracts through its own systems and doesn’t report through USAspending. We can’t surface what isn’t there.
• Some agencies file thinly. Defense and Health & Human Services dominate the volume; smaller agencies appear less frequently in the data.
• Recent activity, not deep history. Coverage starts at FY2020. Earlier years may be added later.
• Freshness is monthly, not live. For same-week awards, check USAspending directly.

When to use the live API anyway

The other tools in the pack — usa_spending_by_agency, usa_spending_by_category, usa_recipient_profile, usa_spending_trends — still query USAspending directly. These are lower-volume, and many of them aggregate across the full historical record rather than the recent window. If one of them times out, the pack returns a structured error in under 8 seconds instead of hanging for 30, so your agent can degrade gracefully rather than stall.

That distinction is worth designing around: use usa_award_search for anything on a user-facing path where latency matters, and treat the aggregate tools as best-effort.