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

Annotations already flag the call as a non-read, destructive, open-world operation, and the description adds substantial context beyond them. It explains the staged dry-run model, the guarantee that nothing is sent until the user sees the exact text, and the rule that a token not matching the payload is refused, so no message goes out. That is exactly the behavioral disclosure an agent needs before a send.

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 description is front-loaded: it opens with the verb and resource, then covers the no-composition constraint, then the two-call protocol. Every sentence adds a constraint an agent could otherwise get wrong, and there is no redundant restatement of the name or title.

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, non-read tool with no output schema, the description covers the risky part well: the staged send, token binding, and refusal on mismatch. It leaves unclear what the dry-run response contains besides payload and token, but the schema already documents parameter meaning, so this 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?

Schema coverage is 100%, so the baseline is 3; the description goes further and explains how dry_run and confirmation_token work together across two calls, and that the token is bound to the exact payload. It does not clarify request_id idempotency or replies_to beyond what the schema says, but the key non-obvious parameters are covered.

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 uses a specific verb and resource: it answers a thread the user already holds, using the key they hold, and it explicitly says it will not compose text for the user. It does not, however, distinguish itself from the read-side sibling get_exchange_answer, so an agent must infer the split between reading and replying.

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?

The description states the precondition (the user already holds the thread and key) and gives detailed procedural guidance: call once with dry_run=true, then call again with the same arguments plus the token. It still gives no explicit exclusion or alternative to use when the thread is not held or when the agent only needs to read the answer.

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