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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety bar is lowered, and the description still adds meaningful process context: a preview-before-confirm gate, confirmation tied to a reused requestId, and the rule that the claim is live only at active status. It does not say what specifically can be destroyed by a bad attach or how failures surface, which keeps it below 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 short clauses, front-loaded with the verb and immediately followed by the risk/confirmation rule — there is no padding. The telegraphic style and the unresolved URI reference cost it a point, since the reader has to decode rather than simply read.

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 10-parameter, destructive, nested-payload mutation with no output schema, the description is too thin: it never enumerates the attachable asset types, whether attaching is additive or replacing, per-platform constraints, or what the caller gets back to track the operation. The pointer to an external field reference defers the substance rather than supplying it.

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 60%, so the schema carries most of the weight; the description reinforces confirm and requestId semantics in prose. The nested payload properties (images, callouts, sitelinks, structuredSnippets) have no descriptions in either the schema or the description, and the only help offered is an opaque pointer, "Fields: soclo://tools/soclo_ads_attach_campaign_assets."

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?

"Attach campaign assets" states a specific verb and resource, and the verb distinguishes it from soclo_ads_remove_campaign_assets and soclo_ads_update_campaign_assets. However, the sentence is essentially a restatement of the title with no scope detail: it never says what kinds of assets (images, callouts, sitelinks, structured snippets) or at what level (campaign vs ad group) they are attached.

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 description does give a real workflow: preview first, then call again with owner-approved confirm:true and the same requestId, and treat the claim as live only once status is active. What it omits is which tool provides the preview and which one returns status — presumably soclo_ads_operation_status — so the agent must infer the routing rather than being told.

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