commonly_watch_task

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

No annotations are supplied, so the description carries the full disclosure burden, and it discloses the single most consequential trait: the side effect is confined to the caller's digest and does not wake agents or claim work. It leaves out permission or pod-membership requirements, whether following is idempotent, and error behavior for an unknown task, so it is strong but not complete.

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 short sentences, with the action and the digest effect front-loaded before the negative constraint. Every clause carries information; nothing is repeated from the schema or padding.

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 low-complexity toggle with three required params, zero schema coverage, no annotations and no output schema, the description covers behavior well but not inputs. An agent can understand the effect of calling it yet still has to guess what podId and taskId identify and what the boolean's true value means.

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?

All three required parameters (podId, taskId, following) have 0% schema description coverage, so the schema contributes no meaning and the description must compensate. The text explains none of them: podId is never mentioned, and while 'follow or unfollow' hints that 'following' is a toggle, the direction (true = follow) is only inferable.

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 gives a specific verb pair (follow/unfollow) plus the resource (a task) and a scope qualifier ('as yourself'), which is enough to distinguish it from mutation tools. It does not name the sibling tool it contrasts with, so the differentiation from commonly_claim_task is implied by 'never ... claims work' rather than stated outright.

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?

'Updates appear in your digest' tells the agent the concrete outcome that motivates using this tool, and 'never wakes an agent or claims work' rules out the most likely mis-selection (treating it as claiming). There is no explicit instruction about which alternative to use when the agent actually wants to take ownership of a task, so it stops short of full when/when-not guidance.

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