Get Recompete

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

Beyond the readOnly/idempotent annotations, the description adds behavioral details: it is 'Factual, signals-not-scores, no win-probability guess' (indicating the nature of outputs) and 'Not windowed' (suggesting no time filtering). It also notes the consistency of the 'incumbent_uei' field across tools, enhancing predictability. No contradictions with 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 description is moderately detailed but each sentence adds value: it states the purpose, tool category, nature of outputs, contrast with a sibling, parameter source, and output field consistency. It is well-structured and avoids redundancy, though slightly longer than strictly necessary.

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?

The description provides substantial context: tool type, Pro-only restriction, output nature (signals), and difference from search_recompetes. It also gives clues about the response (e.g., includes incumbent_uei). However, it does not elaborate on the exact structure of the vulnerability signals or response format, which might be expected given the absence of an output schema in the provided context.

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 only parameter 'piid' is a string, and the description provides context on its provenance ('from search_recompetes, get_contract, or get_vehicle'), which helps an agent understand what value to supply. It does not specify format constraints, but the guidance is sufficient for typical use. The description also clarifies that 'incumbent_uei' in the response corresponds to the 'uei' parameter in other tools, indirectly aiding parameter understanding.

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 clearly states the tool's primary action: 'Get one recompeting/expiring contract by PIID' and what it provides (incumbent-vulnerability signals). It also distinguishes itself from the sibling 'search_recompetes' by noting it is a direct ID lookup, making the purpose unambiguous.

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 explicitly contrasts with 'search_recompetes' ('Not windowed, a direct ID lookup') and indicates when to use this tool (when you already have a specific PIID). It also specifies the context ('Capture & Teaming / Post-Award tool') and directs where to obtain the PIID ('from search_recompetes, get_contract, or get_vehicle'), providing clear guidance for selection.

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