Get Protests on a Solicitation

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

With annotations already declaring readOnly, idempotent, openWorld, and non-destructive, the description adds rich behavioral context beyond the structured metadata: it resolves the WHOLE GAO case across different docket spellings, returns pre-computed booleans, and explains that alternate real spellings produce the same complete set. This goes well beyond the annotations.

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?

The purpose is front-loaded in the first sentence, the parameter source is a clean bullet, and the return fields are explained in compact prose. Even the longer GAO spelling caveat earns its place by preventing a realistic misreading of duplicate results. Every sentence contributes 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?

Given the output schema exists, the description doesn't need to exhaustively document return values, but it still explains the key pre-computed fields, the statutory deadline, the access restriction, and the non-obvious whole-case resolution behavior. An agent has everything needed to call this tool correctly.

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?

The single parameter has 0% schema description coverage, so the description must compensate. It does add meaningful provenance by telling the agent to take solicitation_number from search_opportunities, search_contracts, or search_protests, but it doesn't give a format, example, or additional constraints. This is adequate but not thorough.

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?

The description opens with a specific verb and resource: 'Get every protest filed on ONE solicitation,' and immediately clarifies the contestability read for a specific opportunity or award. This clearly distinguishes it from broader sibling search tools like search_protests by emphasizing one solicitation and the statutory decision deadline.

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?

The description gives clear context for when to use the tool — for a specific opportunity/award — and even tells the agent where to source the solicitation_number from (search_opportunities, search_contracts, or search_protests). It stops short of explicitly saying when not to use it or naming the broader alternative for cross-solicitation protest searches, so it loses the last point.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.