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

Annotations already declare destructiveHint=true, openWorldHint=true, and non-idempotent, so the safety profile is covered. The description adds genuinely useful context beyond those: turning On sends real applications without per-item approval, and the action is 'Held with a summary first,' disclosing a confirmation gate. The confirmation-flow wording is terse ('A ready-to-read summary is in `say`') but does convey behavior the annotations cannot.

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?

Three short sentences with the core purpose and the 'On' semantics front-loaded. The closing 'A ready-to-read summary is in `say`' is terse and slightly disjointed (it references a field with no output schema), but the overall size is well controlled with minimal 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 destructive, non-idempotent mutation with no output schema, the description covers the essential safety gist but leaves the held-answer/confirmation round-trip ambiguous (it references a `say` summary that appears nowhere in the schema). An agent can form a rough plan but may not execute the two-step flow confidently.

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 100%, so both `state` and `confirmation_token` are already documented in the schema itself, including the 'same other inputs' rule for the token. The description adds nothing about parameter formats or valid values beyond the schema (it never enumerates on/off/paused as discrete values). Baseline 3 is appropriate.

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 states a specific verb+resource ('Turn Autopilot on, off or paused') and clarifies what 'On' actually means (real applications sent in the person's name without per-item confirmation). It distinguishes the action from the sibling read/preference tools (autopilot_status, autopilot_settings) implicitly, though it never names them. Purpose is clear but sibling differentiation is not explicit.

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?

There is partial guidance: 'On ... is meant for their explicit instruction,' which hints that this should only be used on the user's say-so. However, there is no explicit when-to-use vs. autopilot_settings/autopilot_status, no stated prerequisites for the held-answer flow, and no exclusions. Usage is implied rather than spelled out.

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