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

With no annotations provided, the description carries the full burden and delivers substantial disclosure: flat 2-credit cost, no charge for empty results or failures, free 24h cache hit when cache=true (default always fresh), spend/impression ranges published only for election ads, and the isActive definition (lastShown within 7 UTC days). These all go beyond what the schema states. It stops short of covering rate limits or error behavior, but this is a genuinely informative behavioral disclosure.

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?

Five dense sentences with zero filler; each sentence carries a distinct fact (data availability, isActive rule, cost, billing, caching). The only structural flaw is leading with a caveat instead of the tool's core function, but as a behavioral note it is efficiently packed and every sentence earns its place.

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?

For a 10-parameter tool with no output schema and no annotations, the description is incomplete: it never states the core operation or what the response contains (e.g., ad creatives, nextCursor pagination, default ATC sort order). Rich parameter documentation in the schema and the behavioral notes compensate partially, but the central 'what does this return and what do I do with it' 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 the baseline of 3 applies. The description adds interpretive context — commercial ads omit spend/impression ranges, and isActive depends on lastShown within 7 UTC days — which helps an agent understand why response fields may be empty, but it provides no parameter-level semantics beyond what the schema already documents.

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 never states what the tool does — there is no verb+resource statement like 'lists an advertiser's ads from the Google Ad Library.' A reader must infer the core function from the tool name and the advertiser parameter. It opens with a data-availability caveat rather than a purpose statement, and does not differentiate from siblings such as google_ad_library_ad_details or google_ad_library_advertiser_search.

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 guidance on when to select this tool over its siblings — google_ad_library_ad_details, google_ad_library_advertiser_search, or the facebook_ad_library_* equivalents are never mentioned. The only operational advice is about caching and billing (cache=true, 2 credits), which is cost optimization rather than tool-selection guidance. The schema's advertiser parameter points to advertiser-search, but the description itself does not.

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