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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is partly covered. The description does add real value beyond them: a seven-day deadline cap that appears nowhere in the schema, and the fact that output is a consensus card routed to a human rather than an accepted outcome. It does not explain why the operation is flagged destructive or what is consumed/overwritten, which is the notable gap for a destructive-hint tool.

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 tight sentences, front-loaded with the creation semantics and followed by the output/scope boundary. Every clause carries information; no filler or restatement of the 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 six-parameter mutation with no output schema, the description covers the input constraints that matter (option count, deadline ceiling) and the return artifact (consensus card for human review). What remains thin is the destructive/idempotency behavior and any authorization requirement, the latter only hinted at by the room_id schema note about OAuth consent.

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 only 33%, so the description has to carry weight, and it partially does by stating the 2-6 option range and the seven-day deadline ceiling, neither of which is expressed in the schema's numeric bounds. It says nothing about 'evidence' beyond 'optional' and does not clarify the question field's intent or the client_id retry semantics, leaving several parameters dependent on schema text alone.

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 and resource: creates a room question with two to six options, optional evidence and a bounded deadline. The closing clause 'does not accept decisions' carves out a scope boundary that separates it from decision-accepting siblings, though it never names those siblings directly.

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 phrase 'for human review; does not accept decisions' implies this is the initiation step rather than the resolution step, which is useful routing context. However, no alternative tool is named (e.g. propose_decision, vote_poll, propose_poll_result) and no prerequisites or when-not conditions are stated beyond that single clause.

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