USASpending.gov

new_awards_over_time

Read-only

Pipeline trend of new awards to a recipient over time.

REQUIRES recipient_id (the recipient hash with -P suffix for parent-level
rollup, or -R for a single recipient). Returns counts of new awards
grouped by month, quarter, or fiscal year.

The endpoint rejects calls without recipient_id with HTTP 422, and it
also requires a time_period. When you omit the dates, a default range
covering all searchable data (2007-10-01 through 2099-09-30) is sent
automatically.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "recipient_id": "<recipient_id>"
    },
    "name": "new_awards_over_time"
  }
}

Input Schema

Name	Required	Default
`group`	No	month
`recipient_id`	Yes
`time_period_end`	No
`time_period_start`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already establish read-only, non-destructive, open-world behavior. The description adds non-obvious behavioral context beyond annotations: the HTTP 422 failure mode without recipient_id, the time_period requirement, and the automatic default range from 2007-10-01 through 2099-09-30. This is strong, though it does not discuss pagination or rate limits.

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?

The description is front-loaded with the core purpose, then requirements and default behavior. It is appropriately sized with no filler; the repeated emphasis on recipient_id being required is reinforcement rather than waste.

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 read-only analytical tool with annotations and an output schema, the description covers the essential call prerequisites, default behavior, and parameter semantics. It does not route the agent to siblings for obtaining a recipient hash or explain when to prefer this tool over spending_over_time, which keeps it from being fully complete.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden and does so well. It explains the recipient_id hash suffixes (-P for parent rollup, -R for single recipient), the grouping granularities (month, quarter, fiscal year), and the time_period requirement/default date range. All four parameters receive meaningful semantic context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource (new awards to a recipient) and transformation (pipeline trend over time), plus the grouping options. It is clear what the tool does, but it does not explicitly distinguish it from siblings such as spending_over_time or search_awards, so it falls short of a 5.

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

Usage Guidelines4/5

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

The description gives clear prerequisites: recipient_id is required and the endpoint returns HTTP 422 without it, and a time_period is also required with a default range sent automatically. It does not explicitly say when to choose this tool over alternative siblings, so it lacks exclusion/alternative guidance beyond the implied recipient-trend use case.

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.