mcp_qwen_submit_task

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

With no annotations provided, the description carries the full burden and does substantial work: it discloses the server-side behavior (auto-building a tree, attaching up to 10 files, including a txt prompt for missing files, up to 5 images), the orchestrator-only constraint, and the polling requirement. It does not explicitly state side effects or cost implications, but it reveals the main behavioral traits that affect output and downstream actions.

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 long and front-loaded with imperative instructions in all caps, which is useful for the Gemini orchestrator rule but makes the text redundant and heavy. It conveys critical constraints, though it could be condensed and better structured (e.g., bullets). It stays on-topic and every sentence contributes something, but the all-caps presentation undermines readability.

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?

The description is thorough for a complex 8-parameter delegation tool: it covers the mandatory vs optional selection logic, the server's automatic file-attachment behavior, the post-call polling procedure, and the no-rewrite rule. There is no output schema, so the description could have mentioned what to do with the task_id result, but it already directs the agent to check status. Slightly incomplete in not specifying how to handle the returned task_id beyond polling, but still strong.

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 each parameter is documented in the schema. The description adds extra meaning to project_dir (mandatory if files exist, auto-attach behavior), target_files (only these files are attached), and user_prompt (must be original, unmodified). The descriptions for custom_system_prompt, skills_content, workspace_context are thin, but the schema covers their basic purpose, so the baseline is 3 and the added detail pushes it 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 delegates a task to a subagent (Qwen 3.8 Max), and the schema shows it accepts a user_prompt plus optional context files. However, the description is heavily focused on behavioral mandates and doesn't sharply distinguish it from siblings like mcp_qwen_continue_task or mcp_qwen_extract_and_write_files, so it loses one point.

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 gives explicit when-to-use rules: always delegate original user text, always pass project_dir if any project files exist, use target_files for point edits, use images for design assets, and then poll via mcp_qwen_check_status. This is exceptionally actionable guidance with alternatives implicitly used (check_status as follow-up, target_files for narrower scopes).

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