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

Annotations only supply the generic safety profile (not read-only, not idempotent, not destructive), while the description adds substantial behavior: the two bid-validation rules, the allow_high_bid escape hatch, the meaning of context_hints, the default paused state, and dry-run via confirm=false. This is rich disclosure well beyond what the structured fields provide.

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?

Purpose is front-loaded and follow-on sentences are dense with decision-relevant detail rather than filler. It is longer than typical, but each sentence adds binding rules or defaults, so the length is mostly earned.

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?

An output schema exists so return values need no explanation, and the description covers the risky mechanics (bidding, dry-run, activation default) for this mutation tool. Remaining gaps are the undescribed name/account/campaign_id params and the parenthetical treatment of billing_event.

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 0% schema description coverage, the description must carry parameter meaning, and it does so for the non-obvious ones: max_bid (currency, per-click vs per-impression), billing_event behavior, context_hints (natural-language, up to 2000, not keyword match), allow_high_bid, activate, and confirm. It leaves name, account, and campaign_id undefined, but those are largely self-evident.

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?

Opens with a specific verb + resource ("Creates an ad group under a ChatGPT Ads campaign") and locates it in the campaign hierarchy, which distinguishes it from create_chatgpt_ads_campaign and create_chatgpt_ads_ad. It also names the two things it configures (max bid and context hints), so an agent knows exactly what this call produces.

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?

Usage is implied through operational notes ("Created paused unless `activate=true`", "confirm=false returns a dry run"), which tells the agent how to invoke safely but not when to prefer this tool over siblings like create_ad_group or update_chatgpt_ads_ad_group. No explicit when-to-use/when-not or alternative routing is given.

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