run_qwen

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

With zero annotations, the description carries the full behavioral burden and delivers extensively: async/non-blocking execution, automatic task tracking, auto-edit approval mode that lands write_file to disk, session resumption semantics with id capture, and automatic retry with exponential backoff on 429/timeout (default 2 retries, 3 attempts). This far exceeds the sparse schema's 31% coverage.

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 purpose and use cases before behavioral details; nearly every sentence carries distinct information about invocation, sessions, or retry policy. Minor defects: the mixed-language 'qwen 端点' typo and slight redundancy where the OpenAI-compatible endpoint is mentioned twice.

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 13-parameter async tool with no output schema, the description covers invocation-critical behavior well: async semantics, session id capture/return for resumption, retry tuning, and file-landing approval mode. It omits semantics for several undocumented params and the task-tracking mechanism, but an agent can invoke the tool correctly with what is provided.

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 31%, so the description must compensate — and it does for the key params: session_id (resume with preserved context), max_retries (set to 0 to disable retries), and auto (maps to --approval-mode auto-edit). However, model, task_id, workdir, timeout_sec, and prompt have neither schema descriptions nor description coverage, leaving notable gaps.

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 operation and resource ('Async call Qwen CLI (qwen --auth-type openai, Qwen Code) to run a task'). Names two concrete use cases — docs/PPT writing and image analysis — and explicitly maps one to a sibling complement ('complements vision_analyze'). An agent can tell this apart from the other run_* 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?

Provides clear context for when to use the tool ('For writing/iterating docs & PPT', 'image analysis (complements vision_analyze)') and a comparative differentiator ('qwen has real resume via --resume, unlike opencode'). Stops short of explicit when-not-to-use statements or routing to the run_codex/run_claude siblings.

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