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

Annotations already flag destructiveHint=true and non-idempotency, and the description adds real operational context beyond them: the asset can go public as soon as Google approves it and will replace campaign- or account-level assets of the same type. It does not explain the destructive aspect (how to undo, or that set_ad_group_asset_status exists for pausing), leaving a small gap.

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?

The behavioral warning is front-loaded and the prose is tight, but the Args block largely restates the schema property names and the Returns line duplicates the existing output schema, adding modest redundancy.

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 four-required-param mutation with an output schema and rich annotations, the description covers prerequisite, approval timing, and precedence over other asset levels. Only the destructive/rollback behavior is unaddressed, which keeps it just under fully complete.

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 0%, so the description carries the full burden and does so: customer_id format (numbers only, no hyphens), ad_group_id target, asset_resource_name provenance (from create_*_asset tools), and the full field_type enumeration with a note on the AD_IMAGE account-eligibility constraint. The enum list is especially valuable since the schema declares no enum.

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 first sentence gives a specific verb and resource ('Links an existing asset to an ad group'), and the later note about campaign-/account-level assets implicitly scopes it apart from the campaign- and customer-level linking tools. It stops short of naming those siblings, but an agent can still identify the correct level from the text.

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?

'After creating an asset (sitelink, callout, etc.), use this tool to attach it to an ad group' gives a clear trigger condition and prerequisite, including which upstream tools produce the input. There is no explicit when-not guidance or pointer to link_asset_to_campaign / link_assets_to_customer as alternatives.

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