Skip to main content
Glama

search_awards

Filter federal contract awards by exact fields — recipient, awarding agency, NAICS code, state — instead of keyword search. Includes a single-bid filter for awards that drew exactly one offer. Use this when you know the slice you want; use get_award_history for topic/keyword search. Requires a BidCatch intel key.

Input Schema

NameRequiredDescriptionDefault
sortNorecent
naicsNoNAICS code, e.g. 541512
stateNoTwo-letter US state code, e.g. TX
agencyNoAwarding agency (partial match), e.g. 'Veterans Affairs'
recipientNoRecipient name (partial match), e.g. 'Lockheed'
one_bid_onlyNotrue = only awards that received exactly one offer

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden; it does disclose the auth requirement (BidCatch intel key) and the meaning of the one-bid filter, which are valuable. But it says nothing about result shape, pagination/limits, or sort behavior, and the read-only nature is only implied by 'filter'/'search'.

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?

Three short sentences, front-loaded with the core purpose, then the routing rule, then the prerequisite. No filler; every sentence contributes distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, routing, and auth, which is solid for a 6-param search with 83% schema coverage and no output schema. However, it omits anything about result volume, pagination, or what a filtered response looks like, leaving a real gap for an agent planning a query.

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

Parameters3/5

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

Schema description coverage is 83% and already documents naics, state, agency, recipient, and one_bid_only, so the description's inline field list largely repeats the schema. It adds no format, matching-mode, or default guidance beyond what structured data provides, so the baseline 3 applies.

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 ('Filter federal contract awards') and enumerates the exact-field dimensions (recipient, awarding agency, NAICS, state), explicitly contrasting with keyword search. An agent can distinguish this from get_award_history without opening the 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 an explicit when-to-use rule ('use this when you know the slice you want') and names the sibling alternative ('use get_award_history for topic/keyword search'). It also surfaces the prerequisite of a BidCatch intel key, which affects whether the call can succeed at all.

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