continue_task

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

Annotations only set readOnlyHint=false, destructiveHint=false, etc., which convey a non-mutating, non-destructive profile. The description adds significant behavioral detail: for codex user_confirmation it says '不发送消息' (does not send messages), for login_required it says to recheck environment and resend the task, and for qoder it describes using a dedicated control. It also states that after approval/environment handling only observation is resumed. This goes well beyond the flat annotations, though it leaves some outcomes unspecified (e.g., return values).

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 structured in a scannable list format per agent and condition, with each clause delivering a distinct fact. The opening phrase is a clear verb+resource statement, and the rest is organized into conditional blocks. Although it is longer than a one-sentence blurb, every sentence earns its place by conveying unique scenario-specific behavior. It is not repetitive and front-loads the core purpose.

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—handling multiple agent types and distinct scenarios—the description covers the major behavioral branches (zcode, codex, qoder) and the environmental conditions under which they apply. It also expresses constraints like '审批或环境处理后仅恢复观察' (only resume observation after approval/environment processing). Missing is any explicit statement about the output or success criteria, but since there is no output schema and the safety profile is already captured by annotations, the description covers the essential usage context well.

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?

With 0% schema description coverage, the description must carry the meaning of the parameters. It explains that 'message' is sent to the original session for zcode agent_question, serves as a processed confirmation in certain scenarios, is not sent for codex user_confirmation, and is used for replies via a control for qoder. It also gives a format hint for multi-question messages (JSON object from full question text to answer). However, 'taskId' is never explicitly defined beyond the implicit notion of identifying a task, and the exact JSON structure is not fully specified. This adds some meaning but leaves 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?

The description opens with a concrete action and resource: '恢复处于 needs_user 的任务' (resume tasks in the needs_user state), clearly distinguishing it from sibling tools like query_task or run_task. It further refines the purpose by enumerating agent-specific behaviors (zcode, codex, qoder), which unambiguously defines what the tool does and when it applies.

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 provides explicit context for when to use the tool (tasks in needs_user state) and gives scenario-specific instructions per agent (agent_question, user_confirmation, login_required). While it does not name alternative tools, it clearly states a prohibition: '提交不明时禁止重发' (do not resend when submission is unclear), which helps prevent misuse. This is strong guidance but stops short of explicit when-not-to-use comparisons against siblings.

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