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

Annotations already declare readOnly/openWorld=false, so safety needs no restating. The description instead adds genuinely useful behavior the annotations cannot: newest-first ordering, the empty-page-with-has_more quirk, and visibility scoping for linked agents. The trailing 'Person only.' is a meaningful but cryptic constraint — it implies an identity restriction without saying what happens if an agent calls it.

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?

Four short sentences, each carrying new information (scope, ordering, pagination rule, sibling pointer) with the core purpose front-loaded. The dangling 'Person only.' fragment at the end is terse to the point of ambiguity and reads as an afterthought.

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?

An output schema exists, so has_more/next_cursor needn't be explained as return values; the description still supplies the non-obvious pagination rule that the schema can't convey. For a three-param read tool this is nearly sufficient, with the 'Person only' identity constraint left under-explained.

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 33%: cursor is documented, but limit (default 50, max 100) and status have no textual description beyond the enum. The description only glosses status ('optionally by status') and says nothing about limit's effect or whether status accepts one value or many. With self-explanatory enum values this is adequate, but it doesn't 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?

A specific verb plus resource ('list your queued, running and past Tasks') with scope (account owner), ordering (newest first) and an optional filter (status). It also distinguishes itself from task_get by explaining that linked agents read individual Task IDs returned to their launches via task_get.

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 concrete operational guidance: a filtered page can be empty while has_more is true, so keep paging while has_more is true — exactly the kind of instruction that prevents premature termination. Names task_get as the alternative for fetching one Task. It does not mention task_list_events or task_cancel, so the sibling set isn't fully routed.

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