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

Annotations already declare readOnly, idempotent, and non-destructive hints, and the description adds complementary behavior details: 'No side effects', 'US only', fuzzy name matching caveat, '24-hour cache', and verified source. It also discloses what the return contains, going well beyond the annotation hints.

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?

Although the description is long, every sentence contributes distinct information: purpose, safety, format, caveats, use-case, alternative routing, source/cache, and feedback fallback. It is front-loaded with the core purpose, and no sentence is redundant with the schema or annotations.

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 one-parameter compliance check with existing output schema and comprehensive annotations, the description covers all operational needs: input format, fuzzy matching caveat, use case, alternative tool, data freshness, and what to do if the response is inadequate. Nothing essential 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 description coverage is 100%, so baseline is 3. The description adds meaningful value by specifying format ('9-digit EIN with or without dash'), providing an example ('Acme Corp or 13-1234567'), and warning that name match is fuzzy and EIN should be used for exact results. This exceeds the schema's basic documentation.

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 ('Check') and resource ('US federal exclusions list'), clarifying it checks debarment status. It also explicitly distinguishes itself from the sibling tool govcon_search_contract_awards, telling the agent what this tool is not for.

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?

Explicitly states when to use ('before awarding federal contracts or grants') and names the alternative for a different need ('Use govcon_search_contract_awards instead to find what contracts an entity has won'). This is clear, actionable routing guidance.

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