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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the write/safety profile is covered. The description adds genuinely new context beyond that: approval gating, operation-kind and state-drift verification before sending, and the no-replay reconciliation rule. It stops short of describing what a partial failure leaves behind or the response shape, so not 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?

Three tight sentences with no filler; the precondition leads and the verification/reconciliation behavior follows. Every clause carries operational weight.

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 destructive confirm tool with no output schema, the description covers approval, input provenance, pre-send validation, and the uncertain-outcome rule. It omits what success returns or how a rejected draft surfaces, which keeps it short of 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 coverage is only 33%, with customer_id described and draft_id and connection_context bare. The description compensates for draft_id by defining it as a draft produced by the prepare tool, but adds nothing about connection_context or the customer id format beyond the schema. Partial compensation justifies the mid baseline.

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 ('link an existing asset to a Performance Max asset group') and names the sibling that produces its required input (google_ads_asset_group_link_prepare). An agent can distinguish it from google_ads_asset_link_confirm and the unlink variants without opening any 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?

Gives an explicit precondition ('After explicit approval'), restricts valid input to a matching draft from the prepare tool, and prescribes behavior for the uncertain-outcome case ('reconciled without replay'). When-to-use, prerequisite, and failure-path guidance are all present.

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