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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds the concrete operational consequence (spending and deletion changes) and the approval gate an agent must clear before calling it. 'Claim live only when status is active' hints at an asynchronous outcome state, which is useful context not present in any annotation.

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?

Short and front-loaded with the safety-critical rule first, which is right. But the fragment style ('Claim live only when status is active', 'Fields: soclo://tools/...') is cryptic rather than dense, and the trailing URL pointer is a reference stub rather than information.

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 most important thing - that this mutates live campaigns and requires preview plus owner approval - is covered. Missing for a 10-parameter, nested-payload, destructive tool with no output schema: what 'apply' actually changes per recommendation type, the maxItems:100 batch limit, how to obtain valid resourceNames, and how to poll the outcome via operation_status.

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% across 10 parameters. The description only touches confirm and requestId, and both are already documented in the schema ('True only after owner approval of spending/deletion preview', 'Reuse this request ID for confirmation'). It says nothing about the nested payload.recommendations resourceName array, the expectedCurrency/expectedBudgetAmount matching requirement, or adAccountId versus accountId - leaving the 40% coverage gap unfilled.

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 ('Apply Google Ads recommendations'), which is clear on its own. However it never distinguishes itself from the closely named siblings soclo_ads_list_google_recommendations and soclo_ads_dismiss_google_recommendations, so an agent must infer that this is the one that actually commits changes.

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 gives real procedural guidance for the risky path: spending/deletion changes must be previewed first, then confirmed with confirm:true and the same requestId. What it omits is the entry point - nothing says the recommendation resourceNames come from list_google_recommendations, and no alternative or exclusion is named against dismiss.

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