Federal award market reports
Scored across 2 tools
The two tools share the same underlying data source (federal contract awards) but are separated by intent: one compares 1-10 named competitors, the other runs a filtered search by NAICS/expiration/market criteria. Descriptions explicitly state the boundaries and exclusion cases (no solicitations, bids, or identity verification), so misselection is unlikely, though the shared domain leaves a small risk of picking 'compare' when a simple filtered lookup was wanted.
Both names follow the same snake_case verb_modifier_awards pattern (compare_competitor_awards, search_contract_awards), making the action and resource predictable. No mixing of conventions.
Two tools is thin for a contract-awards research server; basic operations like retrieving a single award or listing awards for one recipient have no dedicated entry point. The count is defensible for a narrow Excel-report generator, but the surface feels minimal.
Search and multi-competitor comparison are covered and both produce reports, but there is no way to fetch details for a specific award, look up a single recipient's history, or query agency-level aggregates directly. These are notable gaps that would force agents to work through broad searches instead.
Use this when the user wants competitor contract awards, government contract award history or recompete research. Looks up live public federal awards for one to ten competitor names and makes an Excel comparison. Up to 25 returned awards per competitor; names match text and may include subsidiaries; dates from 2007-10-01 to today UTC. Failed items leave successful competitors available. Do not use for corporate identity verification, open solicitations or bids.
| Name | Required | Description | Default |
|---|---|---|---|
| states | No | Up to 10 values, each up to 2 characters. Example: ["TX"]. | |
| agencies | No | Up to 5 values, each up to 150 characters. Example: ["VA"]. | |
| end_date | No | Last action date, no later than today UTC; default today UTC. Example: 2026-10-01. | |
| keywords | No | Up to 5 values, each up to 50 characters. Example: ["janitorial"]. | |
| psc_codes | No | Up to 10 values, each up to 4 characters. Example: ["S201"]. | |
| start_date | No | First action date, YYYY-MM-DD, from 2007-10-01. Default end minus 365 days. Example: 2025-10-01. | |
| competitors | No | Up to 10 values, each up to 80 characters. Example: ["Leidos", "SAIC"]. | |
| naics_codes | No | Up to 10 values, each up to 6 characters. Example: ["541512"]. | |
| award_category | No | Award group, default contracts. Example: idvs uses last date to order for the ending window. |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| notes | Yes | |
| total | Yes | USD with two decimal places, for example $150.03 or -$40,013.22. |
| awards | Yes | |
| capped | Yes | |
| ending | Yes | |
| source | Yes | |
| matched | Yes | |
| summary | Yes | |
| agencies | Yes | |
| returned | Yes | |
| downloads | Yes | |
| recipients | Yes | |
| competitors | Yes | |
| ending_count | Yes | |
| period_agencies | Yes | |
| period_recipients | Yes | |
| rows_without_amount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent, but the description still adds substantive behavior: a 25-award cap per competitor, name matching by text that may pull in subsidiaries, a date floor of 2007-10-01 through today UTC, and — most importantly — that failed items do not block successful competitors from returning. That partial-failure semantics is exactly what an agent cannot infer from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the trigger and the core action before limits and exclusions, with no filler sentences. Some sentences are clause-stacked and read more like a spec dump than prose, which slightly hurts scanability, but every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-parameter tool with 9 filters, an output schema, and full annotation coverage, the description supplies the trigger, the limits, the date window, and the failure model. Nothing an agent needs to select or invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the description goes beyond it by stating the 1–10 competitor bound and that name matching includes subsidiaries, which changes how a caller should format names. The remaining filters (naics, psc, agencies, states) are left entirely to the schema, which is reasonable given full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (looks up live public federal awards for competitors and builds an Excel comparison) and frames the intent (award history, recompete research). The exclusive clause 'Do not use for corporate identity verification, open solicitations or bids' separates it from the neighboring search tool without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this when...' plus an explicit 'Do not use for...' gives both a positive and a negative trigger, which is more than most tool descriptions offer. It stops short of naming the sibling search_contract_awards as the single-name lookup alternative, so the routing choice at the tool boundary is left slightly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants government contracts search, federal contract awards by NAICS code, contracts expiring soon or federal market research. Queries live public award records and makes a multi-sheet Excel report with recipient and agency totals. At least one search filter; up to 300 rows, dates from 2007-10-01 through today UTC, prime contracts or IDVs. Totals cover returned rows; period obligations are separate aggregates. Do not use for open solicitations, bids, subcontracts or classified awards.
| Name | Required | Description | Default |
|---|---|---|---|
| states | No | Up to 10 values, each up to 2 characters. Example: ["TX"]. | |
| agencies | No | Up to 5 values, each up to 150 characters. Example: ["VA"]. | |
| end_date | No | Last action date, no later than today UTC; default today UTC. Example: 2026-10-01. | |
| keywords | No | Up to 5 values, each up to 50 characters. Example: ["janitorial"]. | |
| psc_codes | No | Up to 10 values, each up to 4 characters. Example: ["S201"]. | |
| recipients | No | Up to 10 values, each up to 80 characters. Example: ["Booz Allen"]. | |
| start_date | No | First action date, YYYY-MM-DD, from 2007-10-01. Default end minus 365 days. Example: 2025-10-01. | |
| max_results | No | Maximum award rows, 1 to 300, default 100. Example: 200. | |
| naics_codes | No | Up to 10 values, each up to 6 characters. Example: ["541512"]. | |
| award_category | No | Award group, default contracts. Example: idvs uses last date to order for the ending window. |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| notes | Yes | |
| total | Yes | USD with two decimal places, for example $150.03 or -$40,013.22. |
| awards | Yes | |
| capped | Yes | |
| ending | Yes | |
| source | Yes | |
| matched | Yes | |
| summary | Yes | |
| agencies | Yes | |
| returned | Yes | |
| downloads | Yes | |
| recipients | Yes | |
| competitors | Yes | |
| ending_count | Yes | |
| period_agencies | Yes | |
| period_recipients | Yes | |
| rows_without_amount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial behavior beyond them: it queries live public records, produces a multi-sheet Excel report with recipient/agency totals, requires at least one filter, caps at 300 rows, restricts dates to 2007-10-01 through today UTC, and warns that totals cover only returned rows while period obligations are separate aggregates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, front-loaded with the usage trigger and closing with the exclusion — no filler. It is tightly packed to the point of density (report format, row caps, date bounds and totals semantics all compressed), but every sentence carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, an output schema, and full annotation coverage, the remaining risk is misreading the output, and the description pre-empts it by explaining the Excel report shape and that totals reflect returned rows rather than period obligations. Nothing needed to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds a real cross-parameter constraint the schema cannot express: 'at least one search filter' is required even though no parameter is required in the schema. The award_category/IDV date-window nuance is otherwise left to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb+resource (search federal contract awards) and enumerates concrete use cases: NAICS filtering, expiring contracts, federal market research. It clearly distinguishes itself from non-tools (solicitations, bids, subcontracts) but never distinguishes itself from its only sibling, compare_competitor_awards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Opens with an explicit 'Use this when...' trigger list and closes with an explicit 'Do not use for...' exclusion list, covering both sides of the routing decision. The only gap is that it never names the sibling tool as the alternative for competitor-comparison queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compare_competitor_awardssearch_contract_awardsUS federal contracts, grants, and spending awards
SAM.gov, USAspending & state-portal bids, award history, expiring contracts, forecasts, protests
US federal contracts: solicitations, set-asides, deadlines, awards, contractor profiles. Free.
Federal contract intelligence: $7T+ awards, SAM.gov opps, pWin verdicts, recompetes, protests.
Add one secure layer between your agents and this server.
