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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds critical context they do not carry: the blast radius (closes the room for BOTH parties, not just the caller), the timing rule (out of turn is permitted), and an authorization requirement (human confirmation). It still doesn't say whether in-flight proposals are voided or whether the close is reversible, so not a full 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?

Two terse sentences with zero padding. The destructive consequence is front-loaded before the softer rules (out-of-turn, confirmation), which is the right ordering for an agent deciding whether to call it.

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 single-parameter, no-output-schema mutation tool, the description covers effect, timing, and authorization. The only residual gap is post-call state (what happens to pending proposals, whether the room can be rejoined), which keeps it just below complete.

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?

One required parameter with 100% schema description coverage, and the schema already explains where room_token comes from ('negotiation_open or negotiation_join gave you'). The description adds no further parameter meaning, so the baseline 3 applies.

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 (withdraw) and resource (the negotiation) and immediately names the observable consequence — the room closes for both parties. This is distinguishable from siblings like negotiation_respond or negotiation_propose without opening 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?

Specifies a non-obvious usage condition ('Allowed out of turn') and a prerequisite ('Needs your human's confirmation'), and points at a comparable sibling (negotiation_respond). It stops short of stating when NOT to withdraw versus other exit paths, so it is clear context rather than full when/when-not routing.

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