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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered and the description's "Read-only" line is redundant. It does add value beyond the structured fields by disclosing that secondary conversion actions are included in scope, that output is rendered as a visual card, and that the default period is the last 30 days.

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 purpose leads, scope and read-only status follow, and rendering/default notes close — a sensible front-loaded order with no filler sentences. Minor waste comes from "Read-only" and "Default period: last 30 days" restating what annotations and schema already declare.

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?

All seven parameters are optional and fully documented in the schema, and the description explains what is returned (conversions and conversion value per action) plus the secondary-actions scope. With no output schema, one could wish for a note on row limits or how summary truncation affects the card, but nothing critical to a correct call is missing.

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 all seven parameters, including the detail enum's summary-vs-full tradeoff and the account/folder alternative, are already documented. The description adds no parameter meaning beyond restating the default period, which the date_range schema already specifies, 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 states a specific verb and resource: it returns conversions and conversion value per conversion action, with examples (purchase, lead, call) and the scope note that secondary actions are included. That is clear enough to distinguish it from write-oriented siblings such as google_ads_create_conversion_action, but it never contrasts itself with the closest read siblings (google_ads_conversions, google_ads_performance), so the differentiation is only partial.

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?

"Use this to see which conversion actions are being recorded" implies a context of use, and the default 30-day period is stated. However, there is no explicit when-not guidance and no routing to alternatives such as google_ads_conversions or google_ads_performance, so the agent must infer the choice between them.

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