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

Annotations already declare destructiveHint=true and idempotentHint=false, so safety is partly covered; the description adds genuinely new context on the two-phase preview/confirm workflow and the requestId-reuse recovery semantics. 'Claim live only when status is active' is a useful caveat about result interpretation. It stops short of describing side effects on budgets or what preview returns.

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?

Front-loads purpose in the first sentence and keeps the confirmation rule tight. The trailing 'Fields: soclo://tools/soclo_ads_create_ad_set.' is an opaque pointer that adds no actionable meaning and weakens the ending slightly.

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?

Covers the destructive-confirmation loop and status caveat, which is the highest-risk behavior for a 10-parameter mutation with no output schema. However, target-entity construction (payload fields) and the expected-value verification params go underexplained, leaving gaps an agent must fill from the schema alone.

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 60% and the description adds almost nothing about the 10 parameters beyond restating the confirm/requestId pairing that the schema already documents. It never mentions the nested payload fields (campaignId, name, maxCpc, status) or the expectedCurrency/expectedBudget* verification params, so the baseline 3 applies.

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?

Names a specific verb and resource ('Create a standalone ad group'), with 'standalone' acting as a qualifier that separates it from soclo_ads_create_ad_campaign and soclo_ads_create_standalone_ad. It does not explicitly state the difference from those siblings, so the differentiation is implied 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?

Lays out a concrete procedural gate: run a preview, then re-issue with confirm:true and the same requestId for owner-approved spending/deletion. It also tells the agent not to claim the entity is live unless status is ACTIVE. No explicit routing to alternative create-tools is given, but the operational context is clear.

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