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

Beyond the readOnlyHint annotation the description does disclose real behavior: nullability of firstShown and other optional fields, lower/upper impression bounds, best-effort variations that drop unparseable entries, and OCR-based text extraction that may contain errors. But the cost disclosure is self-contradictory ('at least 10 Nexscope credits' vs '1 credit per request', repeated later as '1 credit per request'), which undermines trust in the most decision-relevant behavior the description is meant to add.

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 text reads like scraped page copy: 'Google Ad Library Ad Details API View Pricing Get Google ad details.' duplicates the title, the firstShown caveat appears twice, the OCR caveat appears twice, and the caching paragraph duplicates the schema verbatim. The genuinely useful behavioral notes are buried mid-stream rather than front-loaded.

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 does the necessary work of naming return fields and explaining their shapes (spend bounds, targeting criteria, regionStats bounds, images array on image creatives, variation caveats), which is substantial. It is undermined by the contradictory credit cost and by missing input guidance on the required url, leaving the agent unsure about cost and how to obtain a valid URL.

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 both url and cache_max_age are fully documented in the schema, establishing a baseline of 3. The description adds no meaning beyond that — the closing cache paragraph is a near-verbatim repeat of the cache_max_age schema text, and it says nothing about what a valid ad URL looks like.

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 opening sentence states a specific verb and resource (retrieves detailed information about a specific Google ad) and enumerates the returned fields (advertiserId, creativeId, format, firstShown, lastShown, impressions), so an agent knows exactly what it gets. It references the sibling endpoint /v1/google/company/ads but never names the sibling tool, so 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?

The 'keep the company-list date when this field is null' note implies this tool is used after or alongside a company ads list, which is useful implied routing. However, there is no explicit statement of when to choose this over social_google_company_ads or social_google_ad_library_advertisers_search, and no stated prerequisite for obtaining the required ad URL.

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