affiliate_webgains-advertiser_list_clicks

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

With no annotations provided, the description carries the burden of behavioral disclosure. It mentions 'Returns Click records' and 'recent', but does not disclose pagination behavior (despite limit/cursor/offset params), auth requirements, or the exact meaning of 'recent'. It also does not explicitly state that brand is required, which is a potential behavioral gap.

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 description is concise, with three sentences each serving a purpose: action+scope, use cases, and return type+pairing suggestion. It is front-loaded and contains no filler, earning a top score.

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?

Given the tool's complexity (7 params, no output schema, no annotations), the description is moderately complete. It explains the tool's purpose and return type but misses details on required parameters, pagination behavior, and date format. The sibling context is large, but the description adequately differentiates Webgains from other networks.

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 description coverage is 0%, yet the description only partially compensates. It mentions 'optionally filtered by programme and date' (programmeId, from/to), but does not explain the required 'brand' parameter, nor the pagination parameters (limit, cursor, offset). With 7 parameters and 1 required, a stronger description is needed to clarify parameter roles.

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 clearly states the tool lists recent affiliate clicks on Webgains (advertiser), identifying both the platform and the advertiser scope. It also distinguishes from siblings by mentioning optional filtering by programme and date, and by naming the Webgains network explicitly.

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 provides explicit use cases for traffic-side debugging with concrete examples ('are my links being clicked at all?', 'where is traffic going on Webgains?'). It also suggests pairing with list_transactions to compare clicks vs conversions, which implies an alternative/complement. However, it does not explicitly state when not to use this tool versus other list_clicks variants.

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