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

Annotations already establish this as a non-read-only, non-destructive, open-world call; the description adds value beyond them by disclosing the return contract (extension result plus identifier) and the failure modes (validation or platform errors). It does not cover idempotency or what happens when a duplicate promotion already exists, which keeps it from a 5.

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 compact sentences, front-loaded with the action, with the return/error behavior and the attach caveat placed after. No redundant restatement of the title or name.

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?

There is no output schema, and the description does a reasonable job summarizing the return, but with 11 parameters and three enums governing conditional requirements, an agent still needs the schema to know which fields pair with which. Adequate rather than complete for a tool of this complexity.

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?

The description defers entirely to "the supplied fields" and adds no meaning for any of the 11 parameters. Schema coverage is 55% — the conditional fields (details_amount, category_amount, category_percent, details_promo_code) and the date format are documented in the schema, but the required enum fields and conditional pairings are left to the schema alone.

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 ("Create a promotion extension in the account's Google Ads asset library") and scopes it correctly. It also explicitly distinguishes itself from the attach operation, which is the natural sibling confusion point alongside add_extensions_to_native_campaign.

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 closing sentence "Attaching the extension to a campaign is a separate operation" gives a real usage boundary and tells the agent this tool alone will not make the extension live. It stops short of naming the alternative tool or stating prerequisites (e.g., account permission, asset library existence), so not quite a 5.

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