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

Beyond the annotations (which only say non-read-only, non-idempotent, non-destructive), the description discloses the real behavioral profile: values carry provenance back to source words, conflicting or unclear facts collapse into a single question, and unread words are preserved verbatim. It also makes clear nothing is transmitted or ordered, which is the key side-effect question for a non-read-only tool. It stops short of covering how the requirement is continued across sessions beyond passing id/token, and says nothing about limits or failure 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?

Front-loaded with the core action, then the reading behavior, then the continuation rule, then the two routing exclusions. Dense but every clause carries distinct information; no restatement of the name or empty filler.

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 does the work of explaining what comes back: a structured requirement with per-value word provenance, a single clarifying question, and preserved unread text. Combined with the sibling routing, an agent has enough to call it correctly. Minor gaps remain around what happens on follow-up turns and any size or failure limits.

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 baseline is 3; the description goes beyond it by explaining the requirement object's role ('Pass the requirement (id, token) from the first answer to continue it'), which clarifies a nested parameter the schema only labels 'The requirement to continue'. It does not add anything about timezone or turn_id, leaving those entirely to the schema.

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 opening names a specific verb and resource ('Give Millsheet the buyer's requirement ... in their own words') and immediately states the transformation performed: reading free text into a structured requirement. It is clearly distinguishable from send_requirement (sending/ordering) and submit_request (already-structured fields).

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 explicit when-to-use (free-text requirement, or a correction/addition to an existing one), explicit when-not ('When you already have the fields in structured form, use submit_request instead'), and routes the sending step to send_requirement. The alternative and the condition that selects it are both stated.

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