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

Adds substantial behavior beyond the readOnly/non-destructive annotations: redaction of raw chain-of-thought and unrestricted worker logs, the frame types returned, the caveat that text deltas are provisional until the terminal frame, and the access rule that agents only read Tasks they started. These are exactly the non-obvious traits an agent needs.

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?

Pagination contract is front-loaded and each sentence carries new information (pagination, frames, side-effect-free observation, permissions). It is dense and slightly multi-topic, but no sentence is wasted filler.

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?

Given an existing output schema, the description covers everything else an agent needs: paging loop, resume semantics, alternate mode via conversation_id, redaction guarantees, side-effect absence, and access scope. Nothing material is left unstated for a 4-parameter read tool.

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?

With 50% schema description coverage, the description meaningfully explains the two weakest parameters: cursor is the resume token from the previous page, and conversation_id switches to per-response frame reading, returning conversation_id and task. limit and task_id are left to the schema, but both are minor/self-evident.

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 and resource ("Read a Task's progress events") plus ordering ("oldest first") and cursor scoping, which cleanly separates it from task_get (task metadata) and task_list (task listing). An agent can identify this as the paginated progress-event stream without opening the 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 clear operational guidance: page while has_more is true, resume via next_cursor, and use conversation_id when a person wants to read one assistant response as frames. It also bounds scope with "observes existing work and never starts another model call" and a permission constraint. It stops short of naming alternative tools, hence not a 5.

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