affiliate_kwanko_generate_tracking_link

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does add useful context: it returns a 'TrackingLink' and implies a creation operation ('Generate'). However, it does not clearly state whether this operation is safe (e.g., non-destructive), what side effects occur (if any), or whether authentication/permissions are required. The lack of safety hints is less critical for a 'generate' tool than for a mutation tool, but the description still leaves gaps for an agent to infer behavior.

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 two sentences long, front-loaded with the core action, and each sentence earns its place: the first states what the tool does, the second explains when to use it and what it returns. No redundant or filler content.

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 simplicity (2 params, no output schema, no annotations), the description covers the essential aspects: purpose, usage scenario, parameters, return type, and a workflow hint. It does not detail error conditions or the structure of a TrackingLink, but for a link-generation tool, the provided information is likely sufficient for an agent to invoke it correctly. Slightly more detail on the return value (e.g., that it is a URL string) would push it to a 5.

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%, so the description must compensate. It does: it explains that the tool works 'for a given programme and destination URL' and explicitly instructs to pair with list_programmes to confirm programmeId. This gives practical semantic meaning to both parameters. It does not provide format or encoding details, but the explanations are sufficient for an agent to understand what to pass.

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 uses the specific verb 'Generate' and clearly identifies the resource: 'tracking link on Kwanko'. It explicitly names the two required inputs ('given programme and destination URL') and states the use case ('share an affiliate link to a specific product or page'). This distinguishes it from sibling tools for other networks by including 'on Kwanko' and noting the target use case.

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 gives an explicit when-to-use scenario: 'when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also provides a prerequisite/companion action: 'pair with list_programmes to confirm the programmeId before calling.' However, it does not explicitly state when not to use this tool or mention alternatives (e.g., other networks' tracking link tools), so it falls short of a 5.

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