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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the '[read]' prefix merely repeats structured data. The description adds nothing about pagination behavior, default page sizes, or what the listing returns — the burden is low given annotations but the description contributes almost no extra context.

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?

A single efficient sentence with the scope up front. The '[read]' tag is mildly redundant against the annotations, but there is no filler.

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?

No output schema and three completely undocumented parameters; an agent cannot tell what a 'rule type' is or how pagination works. For a list endpoint with zero schema coverage, the description leaves significant gaps.

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 0%, so the description must compensate. It mentions only the ads_rule_type filter and says nothing about page or per_page semantics, defaults (1 and 50), or the accepted values for the rule type string.

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?

Clear verb+resource: 'List ad monitoring rules' distinguishes it from the generic list_rules sibling by specifying the ad-monitoring domain. The optional type filter is named, though it is not differentiated from other ad-domain list tools (list_ads_campaigns, list_ads_alerts) beyond the noun 'rules'.

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?

No statement of when to use this versus alternatives such as list_rules or the other list_ads_* tools. The 'optionally filtered by rule type' phrase implies a filter exists but gives no guidance on which rule type values to pass or when filtering is appropriate.

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