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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. With no output schema, the description earns real credit by disclosing the return contents (what ran with timings, gate paths, who is blocking and for how long, what is next). It omits any notes on freshness/pagination, so a 4 rather than 5.

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 the content of the view front-loaded before the usage trigger. Minor friction from the metaphorical 'rendered as its sentence' and the title's 'lit sentence', which add flavor but also decoding overhead.

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 tool is a two-parameter read with annotations covering safety and no output schema; the description fills the resulting gap by explaining what the response contains and when to fetch it. It is complete enough to call correctly, with only minor omissions like whether the view reflects live or cached state.

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 100%, so runId and workspace are already documented in the schema, including the workspace default/override nuance for personal tokens. The description adds no parameter-level meaning beyond that, making the baseline 3 correct.

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+resource — the current state of a Task run — and enumerates what the view contains (timings, gate paths, blockers, upcoming steps). That is far more concrete than a tautology like 'view a task run'. It does not explicitly distinguish itself from close siblings such as workbench_tasks_get or workbench_executions_get, 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?

'Use whenever the user asks where something stands, and after acting on a gate' gives clear situational triggers, and the second clause implicitly routes the agent here after workbench_tasks_act. No when-not conditions or explicit named alternatives are provided, so not a 5.

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