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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the description sensibly spends its words on what annotations cannot say: the approval gate before confirming and the requestId reuse contract. 'Claim live only when status is active' hints at a state precondition but is too compressed to be fully actionable, and it never says whether archived forms are recoverable.

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?

It is short and front-loaded with the workflow constraint, but the style is telegraphic: the 'Soclo Ads:' prefix is noise, 'Claim live only when status is active' is opaque jargon, and 'Fields: soclo://tools/...' redirects the reader elsewhere. Brevity here costs comprehension rather than adding it.

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, open-world mutation with six parameters, a nested object and no output schema, the description covers the approval protocol but omits what archiving actually does to the form and its leads, how accountId relates to adAccountId, and what the caller gets back. It is adequate to avoid a wrong call, not complete enough to call with confidence.

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 50%, yet the description only mentions confirm and requestId — both of which the schema already documents in its own descriptions. The undocumented parameters (platform, accountId vs adAccountId, and the nested parameters.formId) get no clarification in the description, so the coverage gap is not compensated.

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 description names a specific verb and resource ('Archive a lead form'), which clearly separates it from siblings like soclo_ads_create_lead_form, soclo_ads_get_lead_form and soclo_ads_list_lead_forms. It does not clarify how archiving differs from deletion or what archiving means for already-collected leads, so it stops short of a 5.

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?

It states a concrete operating procedure — preview the deletion, obtain owner approval, then re-issue with confirm:true and the same requestId — which is exactly the guidance an agent needs before calling a destructive tool. It gives no alternatives or exclusions (e.g., when to leave a form active instead of archiving), so it is clear context rather than full routing.

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