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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety bar is pre-covered. The description still adds real value beyond that: it states that confirmed=true and impactConfirmed=true are mandatory before execution, and that ChannelOAuthId is resolved internally from the header — non-obvious gating behaviour an agent must respect.

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?

Padded with boilerplate that earns nothing: 'This is an explicit tool with a fixed endpoint; it is not a generic endpoint caller' and a 'Search terms:' line restating the name. The Purpose/Use when/Input/Output scaffolding is repetitive rather than front-loaded with the one fact that matters — what clearing a variation actually destroys.

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?

An output schema exists and annotations cover the destructive profile, so much is handled elsewhere. Still missing is the substantive semantic: what a 'variation' is here and what the destructive clear actually removes or reverts on the live channel listing — the key thing an agent needs before asking a user to confirm a high-impact action.

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 100% and every property already carries its own description (including the hgr_list_channels provenance for channelOAuthId). The description's parameter line ('Input: rq: ClearVariationsRequest. Main fields: ChannelListingId: int') adds little and slightly mismatches the actual schema, which has a single opaque 'body' wrapper. Baseline 3 applies since the schema does the heavy lifting.

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 the resource and operation (POST api/ChannelListing/ClearOneVariation) and frames it as 'clear one variation in published product creation and optimization.' However, 'clear one variation' is unexplained jargon, and there is a direct sibling hgr_post_channellisting_clearvariations (plural) that the description never distinguishes from this singular variant, so an agent cannot confidently route between them.

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 'Use when' clause is circular ('Use it when a client needs to run the clear one variation operation'), restating the purpose as its own trigger. No when-not conditions, no prerequisites beyond the mechanical confirmed flags, and crucially no guidance on how this differs from the plural clearvariations sibling.

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