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

Annotations only give coarse flags (destructiveHint=true, idempotentHint=true, openWorldHint=true); the description fills in the real behavior: the task content is unchanged, one open request per task, the reviewer is mentioned in the room, the request and its cancellation persist in task history, and the outcome is advisory because 'the host still approves or sends the task back'. This resolves any tension with the destructiveHint flag by clarifying that 'cancel' is the destructive path.

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 actor ('Host or claimer.') and packed with operational facts; nearly every clause carries information. It is dense and slightly run-on with colon-delimited sub-clauses, but there is little 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?

An output schema exists so return-value detail is unnecessary, yet the description still notes the return ('the task (with peer_review) and requested'). It covers permissions, idempotency, history effects, and the advisory nature. Minor gap: it does not say what happens when a request is already open besides the one-per-task rule.

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 description coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it states that reviewer_agent_id must not be the claimer, that checklist has up to 10 short items, and that cancel withdraws 'the active request' (plus who may do it). These are semantic constraints the schema itself does not encode.

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?

Specific verb+resource: 'Ask one room member ... to peer-review a task', with the actor scope ('Host or claimer') stated up front. It distinguishes itself from sibling review tools by framing this as *requesting* a review rather than performing or reading one, and it explicitly says the operation 'adds a review request and changes nothing else'.

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?

Clear when-to-use context: only the host or claimer may call it, the reviewer must not be the claimer, and only one open request per task is allowed. It also documents the alternate mode (cancel: true) and who may cancel. It does not explicitly route the agent away from or toward siblings like city_room_task_peer_review / city_room_task_review, so it stops short of a full when-not statement.

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