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

Annotations already declare this is a non-readonly, non-idempotent, non-destructive, closed-world write, so the description adds genuine context beyond them: action taxonomy, the API/DSP campaign requirement for bid actions, per-source_id evaluation for placement actions, and that unknown action_params keys are silently dropped. It still says nothing about the response or side effects of a rule firing on live campaigns.

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?

Dense and front-loaded: the rule mechanics come first, then action groupings, then attachment semantics. The dash-separated clause chains are information-rich but slightly run-on, and a short sentence about the return value would have earned its place more than some inline caveats.

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 14-parameter tool with nested condition/ranking/schedule/action_params objects and no output schema, the description covers the non-obvious semantics (action levels, bid requirements, health vs analytics metrics, attachment requirement). Gaps are minor: no mention of what is returned on success nor of default status/tags behavior.

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?

With 57% schema coverage across 14 parameters, the description compensates well: it enumerates the action enum by level, ties bid_step/bid_step_unit/bid_limit and site_list_id to specific actions, and explains that campaign_ids attaches on create. Name, tags, group_id, status, and the pause-on-success flags are left entirely to the schema.

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+resource and explains the mechanism: conditions over campaign metrics, evaluated on a time window, checked every run_every_minutes, firing an action. The note that campaign_ids attaches the rule immediately hints at the separate attach path, but it never names attach_auto_rule or preview_auto_rule, so sibling differentiation is implied rather than stated.

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?

Strong operational guidance on which action types exist (campaign-level vs placement-level), what bid actions require, and the constraint that a rule only runs on attached campaigns. However there is no explicit when-to-use/when-not guidance versus preview_auto_rule, attach_auto_rule, or update_auto_rule, leaving the agent to infer the workflow.

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