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

Annotations mark this as a non-read-only, non-destructive, non-idempotent write, and the description explains the consequences well beyond that: values are traced to their source words, ambiguities collapse into a single clarifying question, and unparsed words are preserved verbatim. It also clarifies that no order is placed. It omits the retry/turn_id semantics and any note on state that persists across turns, which keeps it from a 5.

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?

Front-loads the core action and its effect, then the continuation rule, then the boundary against send_requirement, then the alternative tool. Dense but every clause carries information; the long first sentence packs several distinct behaviors and could be split for scanability.

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?

With no output schema, the description carries the return-value burden and does so: it says what comes back (a structured requirement with word-level provenance, and at most one question for conflicts). For a 5-parameter tool with a nested object, that is enough for an agent to call and interpret the result correctly.

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 would be 3, but the description adds real meaning: it explains why the requirement id/token pair is passed (to continue an existing requirement) and frames 'utterance' as the buyer's own words plus corrections or additions. That is more than the schema's per-field text conveys.

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 and resource ('Give Groundtruth the buyer's requirement ... in their own words') and immediately names what it is not: sending/ordering. It also names the sibling to use instead when fields are already structured, so the agent can distinguish it from send_requirement, edit_requirement, and submit_request without reading any schema.

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?

Explicit when-to-use (free-text requirement, or a correction/addition to one) and explicit when-not-to-use ('Nothing is sent or ordered: send_requirement sends it'; 'When you already have the fields in structured form, use submit_request instead'). The continuation condition ('Pass the requirement (id, token) from the first answer to continue it') tells the agent exactly when to supply the nested object.

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