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

Annotations establish idempotent=true, destructive=false, readOnly=false; the description adds real behavioral context beyond that: a running briq applies the new window from now, a sleeping briq keeps sleeping until next use, and an over-large window is 'refused with the longest you may send'. Remaining gaps: it doesn't say what the success response looks like or whether changes are auditable, but with annotations covering the safety profile this is solidly above baseline.

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 core effect is front-loaded in the first clause, with consequences and refusal behavior following in logical order. It is dense with parentheticals ('a worker; a command started with briq_exec async is seen') and the wake/sleep-timing material partly restates the `sleep` schema description, but no sentence is truly expendable.

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 three-parameter mutator with no output schema, the description covers the main behavioral questions: what changes, when it takes effect, and what happens when the requested window exceeds limits. It omits error-shape detail and any plan gating (which the `sleep` schema mentions for 'never'), but nothing critical to calling it correctly is missing.

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 coverage is 67%, and the description compensates for the undocumented `briq` param by naming the resource throughout. It also adds semantics the schema doesn't state as crisply — that async commands count as use, and why a longer window may be needed for work the briq cannot see. Format guidance ('30m', '3h', '7d', 'never', never a number) lives in the schema, so the description correctly doesn't repeat it.

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?

Opens with a specific verb and resource: 'Change when a briq goes to sleep', and immediately defines the effect ('a longer window before work briq cannot see... a shorter one, or "never"'). An agent can tell this is a sleep-timeout setter, distinct from briq_exec/briq_up which are cross-referenced. No sibling does anything similar, so the lack of explicit 'use X instead' naming against siblings is a minor gap.

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?

Explicitly states when the tool is NOT needed: 'You do not need this for ordinary work: every call on it and every visit to its URL already pushes its sleep back.' It then names the cases that do require it (workers, bots making only outgoing connections). This is a clear when/when-not split with no inference required.

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