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

No annotations are provided, so the description carries the full burden. It usefully discloses the two possible outcomes (immediate answer vs. session handle to wait on), which is real behavioral information. It says nothing about side effects, cost, permissions, whether execution is asynchronous/background, or how idempotency_key affects retries.

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 short clauses, front-loaded with the action and followed by the result contract. No filler, though the extreme terseness is part of why key parameter details are missing.

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 detail is not strictly needed, and the description covers that adequately. But with 5 parameters at 0% coverage and no annotations, an agent cannot tell what max_steps/max_time_s do or what idempotency_key guarantees — significant gaps for a tool that launches autonomous execution.

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 0% across 5 parameters, so the description must compensate. It only clarifies one parameter's origin ('agent' from list_agents); task, max_steps, max_time_s, and idempotency_key are left entirely undefined, including units and semantics (steps? seconds? retry key?).

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+resource ('Start an agent on a task') and even summarizes the dual-shaped result (answer or session handle). It distinguishes itself from the read/list siblings, though it does not contrast with wait_for_session or send_message explicitly.

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 'agent from list_agents' is a useful prerequisite pointer, and 'session handle to wait on' implies the wait_for_session follow-up. However there is no explicit when-to-use guidance, no when-not, and no statement about how this differs from send_message to an existing session.

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