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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavioral context beyond that: data source (USAspending.gov), coverage limitations (only prime awards of $1M+ resolving to a listed company), and the key caveat that reported total value is 'not revenue received.' It also notes that sums understate total federal revenue, which helps agents interpret results correctly. No contradiction with annotations is present.

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 appropriately sized for a tool with 7 parameters, packing source, scope, field semantics, coverage caveats, and an alternative into a compact paragraph. The main action is front-loaded in the first sentence, and later clauses are information-dense rather than padded. A slightly tighter organization could help, but it is not bloated.

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 moderate complexity, 7 parameters, and no output schema, the description covers everything an agent needs: what data is returned, source, coverage/exclusions, definition of key values, defaults context, and when to use a sibling tool. Pagination and date defaults are already in the schema, so the description complements rather than duplicates structured info. This is effectively complete for correct invocation and result interpretation.

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 coverage is 100%, so the baseline is 3; the description adds additional meaning by clarifying that total value is 'obligated dollars plus unexercised ceiling — not revenue received,' which informs how sortBy='amount' and maxResults should be interpreted. It also expands on the meaning of output fields such as outlays and period-of-performance end date, enriching parameter context. The description does not repeat parameter names or formats, keeping value-add high.

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 federal government contract awards ... won by a specific public company.' It clearly differentiates from the sibling GetTopGovernmentContractors by noting the per-company scope versus market-wide ranking. The title and annotation reinforce the same purpose, and no ambiguity remains about what the tool does.

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 states the tool is 'useful for gauging a company's reliance on federal spending' and explicitly directs agents to 'use GetTopGovernmentContractors to rank companies market-wide.' This provides clear when-to-use guidance and names the alternative, so an agent can select between the two without opening schemas.

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