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

Annotations already declare readOnlyHint and destructiveHint, and the description adds substantial behavior beyond those: conservative name matching, live attestation metadata, post-quantum cryptographic settlement receipts, a verification URL, and a per-call cost of $1.00 USDC. This is strong transparency for an API call.

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 compact and front-loaded with the most important use-case information. The 'Source: SAM.gov Exclusions API' sentence is slightly redundant with the opening, but the rest of the sentences contribute meaningful details such as attestation and pricing.

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 tool with no required parameters and no output schema, the description covers purpose, parameter options, matching behavior, attestation, and cost. Still, it does not state whether at least one identifier is necessary, how multiple identifiers behave if supplied, or what the response structure contains, leaving some ambiguity for a correct invocation.

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 schema description coverage is 0%, so the description must compensate for the three parameters. It maps entity_name, uei, and cage_code to 'entity name, UEI, or CAGE' and adds that name matching is conservative, which adds some meaning. However, it does not clarify whether at least one parameter is required, whether multiple can be combined, or any input formatting/precedence rules.

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 specific purpose: verifying federal contractor or grantee eligibility against SAM.gov exclusions. It names the underlying API and differentiates itself from related screening tools by explicitly pointing to SAM.gov.

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 opening phrase 'Use when verifying federal contractor or grantee eligibility against SAM.gov exclusions' provides a clear, explicit when-to-use context. It does not explicitly mention alternatives like OFAC or OIG screening tools, but the SAM-specific framing is strong enough for an agent to select the correct tool.

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