Wait for a group round

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

Annotations already establish the safe, idempotent, non-destructive read profile, and the description adds real behavior beyond that: the five-minute ceiling, early return on completion or blocker, the fact that a blocked seat stays running, and that include_output=false loses nothing because later calls with true return full answers. It does not cover auth requirements, rate limits, or concurrency behavior.

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 timeout and return condition, then the blocker workflow, then the output toggle. Dense and useful, though the reply-tail concept is restated in two sentences where one would suffice.

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 shape need not be explained; the description covers the asynchronous waiting semantics, blocker handling, and the include_output tradeoff well. The remaining hole is round_id semantics and the relationship to wait_agent, which an agent must guess.

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 50%: include_output is documented in the schema, while round_id has no description anywhere. The description adds useful semantics for include_output (data is not lost, later true calls return full answers) but contributes nothing about round_id's format or provenance, so it only partially compensates for the gap.

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 names a specific verb ('Wait'), the resource ('round'), and the bounded scope ('up to five minutes') with the early-return conditions. It implicitly separates itself from wait_agent by operating on a round rather than a single agent, but it never explicitly contrasts the two sibling wait tools, so the differentiation is left partly to inference.

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?

It gives clear operational context: call it while a round is running, keep waiting or use cancel_agent when a blocker appears, and set include_output=false when only status is wanted. It stops short of stating when to prefer wait_round over wait_agent or when not to call it at all.

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