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

With zero annotations, the description carries the full burden and delivers thoroughly: it discloses blocking-until-settle behavior, the output shape (final result plus stats, prefixed [session: <id>]), the separate-context limitation (qwen cannot see this conversation), the yolo approval default that edits files and runs shell commands as the user without asking, kill-time resumability, and stream-vs-print reachability semantics. This is exemplary behavioral disclosure for a mutation-capable 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?

Well-organized in descending importance: core purpose first, then return format and session routing, then 'Good for' usage, then the safety caution. Although on the longer side, every sentence conveys distinct information — parameter implications, failure resumability, and approval semantics all earn their place with no 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?

For a complex 9-parameter tool with no annotations and no output schema, the description covers the full operational picture: blocking behavior, output contract with session-id prefix, the self-contained-prompt requirement, safety default, failure mode (resumable on kill), and integration with siblings (qwen_reply, qwen_send). Nothing an agent needs to invoke it correctly is missing.

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 100%, so the baseline is 3. The description adds genuine value beyond the schema by contextualizing approval_mode (yolo defaults to full delegation, 'delegation is the point'), allowed_tools (pairs with yolo for read-only runs), transport (steerability via qwen_send), and cwd (where qwen edits and reads QWEN.md). This meaningfully exceeds the baseline by linking parameters to behavioral consequences.

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 ('Start a NEW task in the local Qwen Code agent') and explicitly frames it as a separate agent with its own file/shell tools and context window. The 'NEW task' emphasis and 'continue that session later with qwen_reply' directly distinguish it from all siblings (qwen_reply, qwen_send, qwen_models, qwen_running, qwen_sessions) 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?

Provides explicit 'Good for' scenarios: a second opinion from a different model, work kept out of this context, and parallel investigation. It implies routing (continue with qwen_reply) and steers safety-constrained usage via the caution. However, it lacks an explicit 'when not to use' or a comparative list against the sibling tools, leaving some selection logic to inference.

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

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

No annotations are present, so the description carries the full burden. It discloses that the tool reads live from the CLI over a control protocol, that it reflects what is 'actually reachable right now' (i.e., dynamic, not cached), and that it 'starts no task'. It also names the return fields, covering the main behavioral aspects of a listing operation without side effects.

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 compact sentences with zero fluff. The first sentence states the action, scope, and output fields; the second gives the direct use case and a safety note ('Starts no task'). Information is front-loaded and every clause earns its place.

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 simple listing tool with one optional parameter and no output schema, the description is complete. It explains what the tool returns, when to use it, that it is live, and that it is non-mutating. An agent has everything needed to invoke it correctly — no missing context about return format, side effects, or usage.

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?

The input schema already documents the single optional `search` parameter with a description ('Optional substring filter on model id or label, e.g. 'coder', 'max''), giving 100% schema coverage. The tool description adds no semantic detail beyond that — it simply repeats that it lists models. Per the rule, with full schema coverage the baseline is 3, and no additional value is provided.

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 begins with 'List the models' — a specific verb and resource — and enumerates the exact fields returned (id, label, capabilities, context window). It also differentiates from siblings by specifying it reads live from the CLI and is used to select a `model` value for `qwen` / `qwen_reply`, making its role distinct from conversation and send tools.

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?

Explicitly states when to use it ('Use it to pick a `model` value for `qwen` / `qwen_reply`') and notes 'Starts no task', which implies it is a read-only query rather than an action. It does not explicitly name sibling alternatives to avoid, but the purpose is clear enough that an agent would not confuse it with the conversation tools. The condition for selection is stated, though not the exclusion of alternatives.

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

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

With no annotations provided, the description carries the full burden and delivers richly: it discloses that sessions survive timeouts/cancels in qwen's own store, survive server restarts, and that qwen never sees this conversation (so the follow-up should be short). The parameter texts add further behavioral detail (effort only applies to stream transport and is rejected in print mode; timeout-killed runs still return their session id and are resumable), going well beyond what the schema names alone imply.

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?

Four sentences, zero filler, and the core purpose plus scope constraint are front-loaded in the first clause. Every sentence earns its place: purpose/scope, persistence rationale, context-separation note, and sibling routing. Dense but efficient.

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 complex 10-parameter, 3-enum tool with no output schema, this is nearly complete. It explains the session lifecycle, resumability guarantees, how to obtain a session id, and routes to the correct sibling for a running turn. All parameters are documented, and the nuance about context separation helps the agent craft an appropriately scoped follow-up.

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 100% and the property descriptions are already behavior-rich, so the baseline is 3. The main description adds genuine value on top for the two required params: session ('the session survives… resume it here') and prompt ('the follow-up can be short'). That lifts it above baseline, though individual property semantics are largely carried by the schema itself.

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 ('send a new turn to an existing qwen session') plus a hard scope constraint ('not executing right now', including timed-out or cancelled sessions). It explicitly names sibling alternatives (qwen, qwen_send) and the conditions that select between them, so an agent can distinguish it without opening a 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?

Gives explicit when-to-use ('resume it here instead of restarting with qwen'), when-not-to-use ('For a turn still running under stream, use qwen_send instead'), and names the alternatives directly. Also communicates the follow-up can be short because qwen retains prior turns — practical guidance for how to phrase the prompt.

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

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

With no annotations, the description carries the full burden. It discloses the key behavioral constraint that only stream-transport runs are listed and print runs are excluded mid-run. It also lists the output fields, which adds transparency. It doesn't mention potential failure modes or permissions, but for a simple list operation this is adequate; a 4 reflects strong disclosure without being exhaustive.

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?

The description is three sentences of pure signal. The first sentence states the action and output fields, the second adds a critical scope constraint, and the third names the sibling alternative. There is no fluff or redundancy, and the most important info is front-loaded.

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?

Given zero parameters, no output schema, and low complexity, the description covers everything needed to call the tool correctly: what it returns, the scope (stream-transport only), and the alternative for past runs. No critical information is missing for an agent to invoke it appropriately.

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?

The tool has zero parameters, so the schema covers them 100% (vacuously). Per the rubric, 0 params earns a baseline of 4. The description appropriately adds no parameter-specific detail because there is nothing to add, and it stays consistent with the schema.

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 uses a specific verb ('List') and a precise resource ('qwen turns executing at this moment'), and names the exact fields returned (session id, working directory, elapsed time, messages sent). It also differentiates from the sibling qwen_sessions by stating 'For past sessions use qwen_sessions,' making the purpose unambiguous and distinct.

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 description explicitly states when to use it (to see currently executing qwen turns that qwen_send can reach) and when not to ('Only stream-transport runs appear; 'print' runs are unreachable mid-run'). It also names the alternative for past sessions (qwen_sessions). This gives clear guidance with no inference required.

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

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

With no annotations provided, the description fully carries the behavioral burden. It states that the call returns immediately and queued follow-ups are not awaited, adding critical nuance about asynchronous behavior. It also explains how results surface via qwen_reply, making the operation's effects clear.

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?

The description is well-structured and front-loaded: it opens with the core purpose, then states constraints, then behavioral details, and ends with a clarifying note. Every sentence adds information without redundancy or verbosity, achieving high informational density.

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?

Given the tool's complexity (3 params, no annotations, no output schema), the description covers all necessary aspects: when to use it, when not, how it behaves, and where results appear. It also points to qwen_running for session management, making it self-contained for correct invocation.

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?

The schema already provides 100% description coverage for all parameters, so the baseline is 3. The tool description adds meaningful extra context, such as the note that a follow_up is delivered but its answer is not awaited, which clarifies parameter behavior beyond the schema. This raises the score to 4.

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 clearly states the tool's function: 'Deliver a message into a qwen turn that is executing right now.' It distinguishes itself from siblings by specifying the transport restriction ('stream' vs 'print') and when to use qwen_reply instead. The core purpose is unambiguous and unique among the listed tools.

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 description explicitly delineates when to use this tool versus alternatives: it works only on 'stream' runs, cannot reach 'print' runs, and handles finished sessions via qwen_reply. It also directs agents to qwen_running for session discovery. These are concrete, actionable criteria for tool selection.

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

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

No annotations provided, so the description carries the full burden. It discloses that it lists both running and finished runs including timeouts, and orders them newest first. This is a read-only listing operation with no hidden side effects; the description adequately conveys its behavior without needing to mention permissions or rate limits.

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 sentences, front-loaded with the core listing purpose and ordering, followed by usage guidance. No filler words; every sentence earns its place.

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 zero-parameter, no-output-schema tool, the description covers everything an agent needs: what it lists, the ordering, scoping to this server, inclusion of timeouts, and how to use it for id recovery. It also points to the sibling for a different case. Nothing is missing.

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?

The tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameter meanings since there are none, and it doesn't attempt to add any.

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 states a specific verb (List) and resource (qwen sessions), with details: newest first, with working directory, running or finished, including timeouts. It distinguishes from siblings by referencing qwen_reply and qwen_running, making the purpose unmistakable.

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?

Explicitly instructs to use it to recover an id for qwen_reply, and tells when NOT to use it: 'For turns still executing (qwen_send targets), use qwen_running.' This gives clear when-to-use and alternatives.

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