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

Annotations only declare readOnly=false, destructive=false, openWorld=true; the description adds the genuinely important behavioral fact that the ad is created PAUSED and therefore will not serve until reviewed and enabled. That is exactly the kind of context annotations cannot convey. It stops short of noting dry_run availability (left to the schema) or any auth/account requirements.

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?

Two short sentences with zero filler, and the two facts that matter most (what is created, and that it is paused) are 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?

For a creation mutation with no output schema, the description covers the single most consequential behavior (created paused) and so avoids the worst failure mode. But it leaves the assist-constrained fields (headline/description counts, final URL, path fields) entirely to an under-described schema, so an agent still lacks guidance on how to build a valid call.

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?

With 8 parameters and only 25% schema description coverage, the description carries a heavy burden but says nothing about ad_group_id, final_url, headlines (3–15 items), descriptions (2–4 items), or path1/path2. Only account and dry_run are documented, and that documentation lives in the schema, not the description, so little meaning is added.

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?

States a specific verb and resource ("Add a responsive search ad to an ad group"), which separates it from google_ads_add_display_ad and google_ads_update_ad in the sibling list. It does not explicitly name those alternatives, but the ad-type specificity in the title plus the description makes the target operation 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?

"to an ad group" implies the prerequisite of an existing ad group, and the PAUSED note hints at a review-then-launch workflow. However, there is no explicit when-to-use versus update_ad/add_display_ad guidance and no statement of what to do after creation (e.g., enable via google_ads_set_status).

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