task_progress

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

With no annotations provided, the description fully discloses behavioral traits. It explicitly states the tool does not interrupt the delegation, that the todo list may not update during work, that the tool-call count is the reliable liveness signal, and what the tool does not answer. This is exactly the kind of contextual behavior an agent needs to correctly interpret results.

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 well-structured: a clear opening statement, followed by a labeled 'HOW TO READ IT' section that earns its length. Every sentence adds practical value, and the key message is front-loaded.

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?

Despite having no output schema, the description fully covers what the tool returns (tool-call count, last tools, todo list) and how to interpret those signals. It also addresses edge cases (stalled todo list) and exclusions (not progress estimation). For a single-param inspection tool, this is complete.

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 for the sole required parameter session_id. However, the description never explains what session_id is, how to obtain it, or how it relates to the 'running delegation' mentioned. The phrase 'running delegation' implies the session context but does not add explicit parameter-level meaning beyond the schema's name.

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 opens with 'Inspect a running delegation without interrupting it', a specific verb+resource that clearly distinguishes this from mutating siblings like abort_task, continue_task, and end_task. It also enumerates the specific data it returns (tool-call count, last tools, todo list), further clarifying its 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?

The description provides explicit guidance on how to interpret the tool's output, clearly stating when it should and should not be used: 'This answers alive vs stalled, never how much is left'. It also tells the user not to abort based on a stalled todo list and recommends an alternative ('git status --short') for ground truth on files. This goes beyond simple clarity.

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