zadig_workflow_task_list

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

With no annotations, the description carries the full behavioral burden, but it only discloses that the operation is a read/list and that deployment summaries can be toggled. It does not mention that include_deployments defaults to true (so the 'optional' summaries are on by default), pagination defaults (page_size=20), or the effect of include_raw.

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?

A single front-loaded sentence with no filler; the verb and resource lead and every word earns its place. The brevity is structurally clean, though it partly reflects missing content rather than tightly edited rich 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?

For a 9-parameter tool with no annotations and 0% schema description coverage, one sentence is inadequate. The output schema mitigates return-value ambiguity, but the description fails to cover pagination behavior, filter syntax, and routing among the three task-focused siblings (list, detail, job_log).

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% with 9 parameters, and the description compensates only for include_deployments via 'optional deployment summaries.' The other eight parameters (filters format, query_type valid values, include_raw semantics, project_key, job_name) are left unexplained, forcing the agent to guess at accepted values and formatting.

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 a specific verb ('List') and resource ('Zadig workflow tasks'), and 'with optional deployment summaries' adds a scoping detail that points at the include_deployments toggle. It is clear enough to distinguish from workflow-level siblings (zadig_workflow_list lists definitions, this lists their task runs), but differentiation from zadig_workflow_task_detail relies on the name rather than the description.

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?

Provides no when-to-use guidance. It never says to prefer this when an agent needs a paginated overview of task history, nor that zadig_workflow_task_detail or zadig_workflow_task_job_log should be chosen for single-task inspection or logs. An agent must infer all selection logic from sibling names.

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