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

Annotations only declare the safety profile (readOnlyHint=false, idempotentHint=true, non-destructive); the description goes well beyond, disclosing that the default call returns immediately rather than blocking, that repeating with identical arguments converts the call into a ~20s wait, that unanswered questions persist in the user's queue, and that each question consumes the user's attention against the same limit that blocks claiming new work. That is exactly the behavioral context annotations cannot carry.

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?

It is long, but densely informative and front-loaded — the use-only-for rule and the options preference come before the mechanics. Nearly every sentence carries distinct behavior (default flow, no-user case, wait-on-repeat, form channel, attention cost), though the middle section on repeated polling is heavy enough to slow parsing.

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 an 8-parameter tool with no output schema, the description covers what each call path returns (immediate ack vs. in-call wait vs. queued answer at next start_task/get_my_work), including the no-user-present case. Nothing an agent needs to call it correctly — including the failure mode of inventing a user — is left out.

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, but the description adds real semantics: why `options` matters ('a question with alternatives gets read, a yes/no gets rubber-stamped') and how `channel:'form'` changes control flow inside the call. The idempotent-recall behavior tied to `holdSeconds` is also clarified beyond the schema's terse defaults.

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 gives a specific verb+resource ('register a question only the user can answer') plus the crucial side effect ('keep your place on the task while it is open'). It clearly distinguishes itself from siblings like submit_answer (which supplies the answer) and start_task/get_my_work (where queued answers arrive), so an agent can route without opening the 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 gate on when to use it ('ONLY for what is irreversible... or a real fork with no reasonable default') and an explicit when-not ('never for may I continue?'). It also routes to the alternatives by name — submit_answer for delivering answers, start_task/get_my_work for picking up queued answers — and explains when to reuse this call as a wait.

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