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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered structurally. The description reinforces this with "Changes nothing" and adds genuinely new context — that runs consume the agency's own assistant plan with no separate AI cost. It does not describe the format or length of what the prompt returns, so it adds value without being rich.

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?

It is a single dense sentence with nested parentheses and interleaved clauses, so it is not front-loaded and the reader must parse the parenthetical to extract the core meaning. The information is relevant but poorly ordered and would benefit from being broken into distinct statements.

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 zero-required-parameter, read-only tool with annotations covering the safety profile and no output schema, the description covers the modes of operation and the client scoping rule adequately. The main omission is any hint of what the returned weekly prompt looks like on a call, but that is a minor gap given the annotation coverage.

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 100%, and the schema description already explains the single client parameter (name for per-client task, leave out for all clients). The description adds the filter qualifier "in shadow or on" but otherwise largely restates the schema, so the baseline 3 applies.

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 defines the tool as the weekly Autopilot prompt plus instructions for running it weekly, which is a concrete resource (the routine prompt). It is distinguishable from siblings like autopilot_run or autopilot_start by its focus on the recurring schedule rather than a one-off execution. It loses crispness by being embedded in a run-on sentence rather than stating a verb+resource directly.

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?

It gives real usage context: run as a scheduled task where the assistant supports connectors, otherwise as a weekly ask, and scope to every client in shadow/on or a single client. However, it does not name or contrast against the adjacent sibling tools (autopilot_run, autopilot_preview, autopilot_start) that an agent must choose between, so the when-to-use decision is only implied.

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