ad_asset_performance

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

Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context: it is scoped specifically to responsive search ads, returns Google's own performance_label, and exposes per-headline/per-description data rather than a single aggregate. It also explains the relationship between ad_strength and this underlying signal. This goes beyond what annotations alone convey.

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 description is concise and front-loaded with the core purpose, followed by a clear explanation of why it matters relative to the aggregate ad_strength label. Both sentences earn their place, though the phrase 'Google's own' is slightly redundant and could be trimmed. Overall structure is strong and easy to parse.

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?

The description explains the tool's conceptual purpose well and there is an output schema to clarify return structure. However, it gives no operational context for parameters such as campaign_id or date ranges, and does not mention the filtering behavior implied by the optional inputs. For a read-only reporting tool with defaults, this is adequate but not fully complete.

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%, and the description provides no guidance on any of the six parameters: customer_id, campaign_id, date fields, limit, or date_range. The agent must rely solely on parameter names and defaults, which is insufficient for correctly constructing calls. The description does not compensate for the total absence of schema descriptions.

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 exactly what the tool returns: per-asset performance for responsive search ads, broken out by individual headline and description with Google's performance_label values. It clearly distinguishes itself from the sibling-level ad_strength metric and explains why this tool is more useful than the aggregate label. The resource and granularity are unambiguous.

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?

The description explicitly frames when this tool is useful: when you need to know which specific line is dragging the ad down before replacing it with add_rsa, instead of guessing from the aggregate ad_strength label. It does not explicitly name sibling alternatives or state when not to use it, but the contextual contrast with ad_strength provides clear practical guidance.

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