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

Annotations only declare write/open-world/non-idempotent/not-destructive; the description adds real behavior: the ad is created PAUSED so nothing spends, confirm=false yields a preview, and an existing matching video asset is reused rather than recreated. These are consequential traits an agent cannot infer from the structured fields.

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?

Front-loads purpose before diving into parameter details, and every clause is substantive. Some sentences are long and run-on (the video-format sentence), but there is no filler.

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 not be described, and the description covers the risky/ambiguous inputs (video formats, asset dedup, required business_name/logo, confirm preview). Minor gaps remain for ad_name and final_url, but the tool is callable correctly from this text.

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 across 12 params, the description carries the load well: youtube_video accepted formats (bare id, watch URL, youtu.be, /shorts/), comma-separated headlines/descriptions with char limits (40/90/90), business_name and logo_asset_id requirements with fallback, and the full call_to_action enum. It leaves ad_name, final_url, customer_id, and ad_group_id unexplained, so not a 5.

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+resource (creates the VIDEO ad inside a Demand Gen ad group) and positions it against the ecosystem ('the last step that makes a Demand Gen campaign able to serve'). An agent can distinguish it from create_demand_gen_campaign and the various create_*_ad siblings without reading the schema.

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?

Explains when this tool is the right one ('the only way to run a click-oriented YouTube campaign now that Google moved Video Action campaigns into Demand Gen') and gives a prerequisite path (upload_image_asset if no square logo exists). It does not explicitly say when NOT to use it or contrast directly with create_demand_gen_campaign, so not a full 5.

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