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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about prerequisites and the integration page, but the sentence 'Returns search volume and competition data' is a behavioral claim that seems inconsistent with listing accounts, reducing transparency about what the tool actually outputs.

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 composed of four sentences and is somewhat verbose. The first sentence is concise, but the later sentence about 'search volume and competition data' is confusing and appears to be irrelevant to the core purpose. The instruction to redirect the user to a URL could be folded more succinctly.

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?

Given the tool's simplicity (no params, no output schema), the description covers the main context: purpose, prerequisites, usage, and alternatives. However, the misleading 'Returns search volume' statement undermines completeness because it suggests the tool returns something it likely does not, leaving the agent unsure about the actual response format.

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?

The tool has 0 parameters, and the schema coverage is 100% (empty properties). Per calibration, 0 params gives a baseline of 4. The description adds no input semantics, but none are needed; it does mention '10-digit customer IDs' which describes the output format, not input parameters.

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 begins with a clear verb+resource: 'List the Google Ads accounts the connected Google user can access, as 10-digit customer IDs.' This distinguishes it from sibling tools like get_google_ads_keyword_ideas. However, the later statement 'Returns search volume and competition data' directly contradicts the account-listing purpose, causing ambiguity about what the tool actually returns.

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 provides explicit usage context: 'Use this to help a user pick which account to select when they have more than one.' It also gives prerequisites ('Requires Google Ads to be connected and an Ads account selected'), directs the user to an integration page, and explicitly points to Google Search Console tools as alternatives for ranking data. This fully addresses when and when-not to use the tool.

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