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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real substance beyond that: it computes rather than mutates, evaluates three regulatory criteria each returning yes/no/to-verify, and depends on wdText being re-passed so rowIds remain valid. It does not discuss error or validation behavior.

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 trigger condition is front-loaded in the first sentence and every following clause carries operational content (criteria, neighbour sourcing, worked example). It is dense but not padded, though the single long run-on sentences make it slightly harder to scan than it could be.

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 10-parameter tool with nested objects and an output schema, the description covers the workflow, the regulatory check, the two ways to supply related classifications, and a full example call. Return values are handled by the output schema, so the remaining gap is minor.

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?

With 60% schema coverage, the description compensates well: it names the three criteria semantics behind the answers object, explains that neighbourRowIds requires wdText while neighbours is supplied directly, and gives a concrete example object showing missingClassification, tasks, wd, wdText, neighbourRowIds and proposed together.

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 first sentence states a precise verb and resource with its trigger: drafting an SF-1444 when a worker performs a classification missing from the WD. It then enumerates exactly what the tool does (fills SF-1444 fields, compares proposed rate against related classifications, checks 29 CFR 5.5(a)(1)(iii)(A) criteria), which no sibling 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?

It gives an explicit when-to-use condition (a missing classification that the contractor must ask the CO to add) and routes the agent to the sibling get_wage_rates to source neighbourRowIds from wdText. The relationship between neighbourRowIds and the directly-supplied neighbours alternative is spelled out.

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