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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, but the description adds material context the annotations cannot convey: a mandatory preview/approval gate before execution and requestId reuse for confirmation and outcome recovery. It still does not say what deletion actually does to the underlying video asset or whether it is reversible.

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?

Four short clauses, purpose first, then the gating workflow, then the status rule, then a reference pointer. No filler sentences and nothing is buried.

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?

The critical safety workflow is covered, but with no output schema and half the parameters undocumented, an agent still lacks what the deletion returns and how to verify it — the sibling soclo_ads_operation_status is the obvious recovery path and is never referenced. Adequate but with clear gaps for a destructive, open-world tool.

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 50%: confirm, requestId and adAccountId are documented in the schema, and the description mostly restates the confirm/requestId contract rather than extending it. The undocumented parameters (accountId, platform, and the nested required videoId) get no explanation in either place, which is the main gap for a 6-parameter destructive tool.

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: 'Delete an ad video', which separates it from the many sibling deletes (delete_ad, delete_ad_creative, delete_ad_catalog) and from upload_ad_video / list_ad_videos. It does not explicitly name a sibling it is not, so the differentiation is inferable rather than spelled out.

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 a concrete operating procedure: preview first, then an owner-approved confirm:true reusing the same requestId, and only claim the deletion is live when status is active. It stops short of naming alternatives or exclusions (e.g., when to use delete_ad vs delete_ad_video), and 'Claim live only when status is active' is terse enough to require interpretation.

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