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

The description reveals that omitted fields are preserved via partial update, which is important behavioral context. It also discloses return format as 'JSON success envelope data, often null' and suggests calling after get_worker_task. Annotations already include idempotentHint=true, but the description adds workflow and partial-update semantics without contradiction.

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 with headers and front-loaded with the key statement. However, the Chinese trigger appears to be an irrelevant copy-paste error and the WHEN NOT TO USE section references unrelated APIs, adding noise without value. Overall it is moderately concise but contains extraneous content.

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 provides a clear workflow, return behavior, and when-to-use guidance. Combined with the 100%-detailed schema, the agent has most context needed to call it correctly. The misleading Chinese trigger and vague exclusion about internal APIs slightly reduce completeness, but the core guidance is present.

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 covers 100% of parameters with detailed descriptions and examples, so the baseline is 3. The description's general 'omit fields to keep current values' reinforces what the schema says for title, and all parameters are already well-documented. No additional parameter-specific semantics are needed.

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 opening sentence 'Update a saved CoreClaw worker task's metadata and schedule' clearly identifies the verb, resource, and scope. It distinguishes the tool from siblings like run_worker_task and update_worker_task_input, and the partial-update note adds useful precision.

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 English 'WHEN TO USE' correctly scopes the tool to changing title, description, or schedule. However, the Chinese trigger states to use this tool when the user wants to query, run, rerun, stop, export, or view task data, which directly contradicts the tool's purpose and overlaps with many sibling tools. This misleading guidance undermines usage clarity.

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