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

Beyond the annotations, the description discloses the core behavioral contract: the first send records a request, a later send of a changed requirement records a revision, and the receipt token doubles as the requirement token for request_status and offers. The line "This orders nothing" is valuable scope-setting that prevents the agent from conflating sending with committing to a purchase. It does not cover failure modes or what a successful response contains, but the annotations already carry the safety profile.

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?

Three sentences, front-loaded with the action and followed by the state-transition rule and the scope caveat; nearly every clause carries information. The parenthetical about the receipt token is slightly dense but earns its place.

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 7-parameter mutation with a nested contact object and no output schema, the description covers the state machine and the ordering caveat well but says nothing about the buyer contact data, op_id idempotency keys, or what comes back after sending. Adequate to call the tool, incomplete for calling it confidently in edge cases.

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 description adds real meaning to `revision` ("Name the revision the buyer saw") and reinforces the dual role of `token`, which goes beyond the schema's own wording. With schema coverage at 57%, though, parameters like `contact` and `op_id` are left without any explanation in either place, so the description does not fully compensate for the gap.

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 states a specific verb and resource ("Send the requirement to Groundtruth") and clarifies the first-send vs. later-send semantics, so an agent can tell it apart from accept_offer or submit_purchase_order. It stops short of naming siblings such as edit_requirement or submit_request explicitly, so the differentiation is inferential rather than stated.

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?

There is a clear trigger condition ("once the buyer says to"), which implies the tool must not be called prematurely. However, no alternative is named: the description never says when to use edit_requirement or submit_request instead, leaving the agent to guess how a 'changed requirement' should be re-sent versus edited.

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