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

Annotations already declare idempotent=true and destructive=true, and the description adds real context beyond them: it resumes saved work rather than starting anything new, and it enumerates four things it explicitly will not do. What it does not explain is what makes the call destructive here (e.g., step/budget consumption or state overwrite on the resumed run), which is the one behavior an agent would still want clarified given destructiveHint=true.

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, both front-loaded with the operative information: the trigger first, then the token requirement and the negative scope. The four-item exclusion list is dense but each item rules out a plausible agent mistake.

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?

An output schema exists so return values need no explanation, and the two highest-risk inputs (stop_token, read_skills, expected_catalog_version) are either described in-schema or contextualized. The definition is still thin for a 6-parameter, nested-object mutation tool: nothing tells the agent what delegation_id identifies or how request_key affects idempotency.

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?

Adds genuine meaning for the critical nested parameter by specifying the exact provenance of stop_token (read_work workflow detail.failure.stopToken), which the schema does not say. With only 50% schema description coverage, however, delegation_id, work_id and request_key remain unexplained in both places, so the description partially but not fully compensates for the gap.

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 two specific, distinguishing actions: continuing a supervised task after its model-step limit, and retrying one failed workflow step after diagnosing its cause. The scope is narrow enough to separate it from siblings like native.wait_for_work, native.resume_film_work and native.direct_work 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?

Gives explicit triggering conditions (step limit reached, or a failed step whose cause has already been diagnosed and addressed) plus negative boundaries: it never starts another build, changes a spending limit, grants video permission or revokes Stop. It also routes the agent to read_work as the prerequisite source for the stop token.

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