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

With no annotations, the description carries the full burden and does add real behavioral detail: the child process is also terminated and job files/worktree are intentionally preserved for inspection. However, it omits permissions/auth needs, whether cancellation is graceful or immediate, and what happens when the task has already completed or failed.

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 tight sentences with zero filler. The action and its scope are front-loaded, and the second sentence delivers the non-obvious side effect about retained files.

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 state-mutating tool with no annotations and no output schema, the description covers the core action and cleanup semantics but leaves open the return value, idempotency, and behavior against already-finished tasks. These are gaps an agent may hit in practice.

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 description coverage is 0%, so the description would need to compensate, but it says nothing about task_id's format or where to obtain it. The single required parameter is close to self-evident from its name, so this is adequate rather than harmful.

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 gives a specific verb (cancel) and resource (delegated task, plus its child process), and the phrase 'queued or running' scopes which tasks are affected. It is distinguishable from submit_task/get_task by the verb alone, though it never names a sibling explicitly, which keeps it just short of a 5.

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?

'Queued or running' implicitly tells the agent the applicable task states, but there is no explicit guidance on when to prefer this over siblings, no mention of what to do if the task is already terminal, and no prerequisites. Usage is implied rather than stated.

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

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

With no annotations, the description carries full behavioral burden and does disclose real traits: long-polling semantics via wait_seconds, that full prompts/research packets are retained in artifacts, and that truncated answers are explicitly labeled. It still omits error behavior, auth needs, and what happens when a task is absent or still running.

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?

Three dense sentences with the return content front-loaded and no filler; each sentence carries information. The phrasing is slightly telegraphic ('when exposed'), but nothing is wasted.

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 4-param, no-output-schema, no-annotation tool, the description does a fair job covering return shape (compact vs full, token counters, truncation labeling) and the polling model. The remaining gap is the identifier parameters and the one-of task_id/workflow_id requirement, which the description never addresses.

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 0%, so the description must compensate. It adds genuine meaning for two params (wait_seconds as an anti-polling delay, detail=full as an opt-in to artifacts), but says nothing about task_id vs workflow_id or the anyOf constraint requiring one of them, leaving the most important identifier semantics undocumented.

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 conveys what the tool returns (compact results, token counters, artifact-retained prompts) and the name get_task signals retrieval, so an agent can roughly infer the purpose. However, it never states the core operation plainly (fetch a task's results/status by id) and offers no differentiation from siblings like cancel_task or list_workers.

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 gives two concrete usage cues: use wait_seconds up to 45 instead of repeated polling, and request detail=full only when artifacts are actually needed. What is missing is any guidance on when to call this versus siblings (e.g., after submit_task, instead of cancel_task), so usage is only implied.

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

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

With no annotations, the description carries the full burden, and it does disclose some non-obvious traits: that usage counters are measured worker counters and exclude coordinator/browser totals, and that historical success does not guarantee current login/quota. However, it omits permissions, cost, and any hint about the response shape beyond the compact/full split.

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 text is short and front-loads the purpose, but it is written as disconnected fragments and semicolon-joined clauses rather than complete sentences, which costs clarity for no real gain in brevity. Every clause carries information, so nothing is padding, but the structure is cryptic.

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 3-parameter, no-annotation, no-output-schema tool, the description covers the output mode split, the usage counter scope, and a freshness caveat, which is more than nothing. It still leaves the meaning of 'since', the definition of a worker, and the full return structure for the agent to guess.

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 description coverage is 0%, so the description must compensate, and it partially does: include_usage is explained (measured worker counters, excludes coordinator/browser totals), detail=full is linked to full paths/config, and 'since ISO timestamp scopes them' gestures at the since parameter. Still, the since semantics are only obliquely implied and the compact enum value is never defined.

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 fragment 'Compact worker/model availability' identifies the resource (workers/models and their availability) but supplies no explicit verb and never says it lists them, so the agent must infer 'list'. It is distinguishable from siblings like submit_task or recommend_route by resource, but the phrasing is telegraphic rather than a clear statement of purpose.

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?

There is no statement of when to call this tool versus alternatives such as recommend_route, nor any prerequisite or exclusion. The only conditional language ('Full paths/config only when detail=full') governs a parameter, not the decision to use the tool.

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

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

With no annotations, the description carries full burden. It usefully discloses that the output is a suggestion, that the heuristics are editable, and that the coordinator makes the final call based on capabilities and prior outcomes — important advisory semantics. It says nothing about cost, latency, determinism, or whether the recommendation is binding, so coverage is partial.

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 tight sentences with no filler, and the core purpose is front-loaded in the first. The second sentence is slightly abstract but does add the decision rationale.

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 2-parameter advisory tool with no annotations and no output schema, the description should clarify what comes back (a single provider? a ranked list?) and whether the result is consumed automatically. It leaves the return contract unstated, which is a meaningful gap even for a low-risk recommendation call.

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 description coverage is 50% — 'task' is documented but 'category' is only an enum with no field description. The description adds no parameter-level meaning, no hints on how category interacts with task, and no explanation of the enum values beyond what the schema shows. It does not compensate for the coverage 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?

The description states a specific verb and resource: 'Suggest a provider using editable task-fit heuristics.' An agent can tell this is an advisory routing tool, distinct from the sibling actions (submit_task, get_task, cancel_task). It stops short of explicitly naming how it differs from those siblings, so it is clear rather than sharply differentiated.

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 explains the basis of the selection ('actual capabilities, context, previous outcomes and explicit user requests') but never states when to call this instead of submit_task or list_workers. Usage is only implied — presumably before submitting work — leaving the agent to infer the workflow position.

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

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

With no annotations, the description carries the full burden and does so well: default read-only, isolated clean Git worktrees for code jobs, bounded 30-minute attempts for heavy profiles, automatic bounded provider fallback with no paid API fallback, and it explicitly says the prompt is never echoed. Missing only permission/auth and mutation side-effects for create_workflow.

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 purpose is front-loaded, but the body is a dense semicolon-joined run-on mixing purpose, safety, fallback, and return behavior. It is terse yet unstructured, and the external doc reference ('See the DeltaRoute heavy-workflows reference') adds noise.

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 an 18-param tool with nested objects, an anyOf of three call shapes, and no output schema, the description is only partially complete. It helpfully states the return shape ('compact status/result and full artifact path'), but does not explain the anyOf call patterns, the limit_error reporting flow, or permissions.

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 description coverage is only 28% across 18 params, so the description must compensate but largely does not. It mostly repeats enum values already in the schema (action names, mode) and the wait_seconds bound, adding only 'default read-only' for mode; key params like category, provider, detail, context, research_scope, and media_options get no elaboration.

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 states specific verbs and resources ('Delegate a task or manage a heavy workflow') and enumerates the workflow actions (create_workflow, run_step, checkpoint). It is clearly distinguishable from siblings like get_task and cancel_task, though it never names them explicitly to route the agent.

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 implies usage contexts (heavy workflows, short jobs via wait_seconds, code jobs) and points to a 'DeltaRoute heavy-workflows reference,' but gives no explicit when-to-use vs when-not guidance relative to recommend_route or get_task. Usage must be inferred.

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