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

No annotations are provided, so this description carries the full responsibility. It discloses mode 'notify' vs 'auto_act', the guardrails (spend floor, per-entity cooldown, learning phase skip), and the meaning of 'acted', 'would_have_acted', and 'skipped' with reasons. It also surfaces the account-wide execute switch as a cause of non-action, which goes well beyond annotation-level info.

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 list action is front-loaded, followed by dense but relevant details on output contents and evaluation statuses. The final sentence is an agent-facing presentation directive that adds value, but the paragraph is long enough that it could be structured more tersely.

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?

With no output schema, the description effectively substitutes by enumerating returned fields, guardrails, and evalution status meanings. It leaves enabled_only and activity_limit semantics to the schema, but those parameters are simple and have defaults and ranges, so the gap is not crippling.

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 describes only account_id (25% coverage), so the description must compensate. It does add real meaning for include_activity by explaining the returned evaluation semantics. However enabled_only and activity_limit are never described in prose; their meaning is left to inference from their names and schema defaults. That partial compensation deserves a middle score.

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?

Description opens with a concrete verb 'List' and resource 'automation rules on one ad account', then details exactly what each rule contains (conditions, mode, guardrails). The read-only listing intent is unambiguous and clearly distinct from the sibling manage_automation_rule, which implies mutation.

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 clearly conveys when it is appropriate: when you need to inspect automation rules or explain their behavior and guardrails, optionally including recent evaluations. It does not explicitly name an alternative or state when-not to use it, so it stops short of a 5.

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