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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds real value beyond them: it discloses the spending-impact approval gate, the requestId reuse pattern for confirmation and outcome recovery, and that 'live' status must be verified via status check. That is meaningful mutation-safety context. It stops short of describing what happens on a failed or duplicated confirmation.

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?

The safety workflow is front-loaded and the prose is compact with no filler sentences. The trailing 'Fields: soclo://tools/soclo_ads_create_bid_strategy' line is opaque boilerplate that consumes space without informing the agent.

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, nested-payload creation tool with no output schema and 10 parameters, the description covers the confirmation workflow adequately but omits how to populate the payload for each bid strategy type and what the preview step returns. An agent could execute the approval flow correctly yet still choose wrong field combinations.

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 only touches confirm and requestId, which the schema already documents. The non-obvious parameters — expectedCurrency, expectedBudgetType, expectedBudgetAmount, and the payload's type-dependent requirements (targetCpa vs targetRoas vs targetImpressionShare) — are left unexplained, and 'Fields: soclo://tools/...' is a pointer, not an explanation.

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 ('Create portfolio bid strategy') under a namespaced prefix, which clearly separates it from sibling tools like soclo_ads_update_bid_strategy and soclo_ads_list_bid_strategies. It does not explicitly name those siblings, so differentiation is implied by the name 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?

The description explains the required preview-then-owner-approved-confirm workflow with the same requestId, which is useful procedural guidance. However, it never says when to create a new strategy versus update an existing one, nor what prerequisites (account selection, platform) are needed before calling.

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