Get LINE coupon redemption stats

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

The description discloses that LINE has no dedicated redemption endpoint and that the tool 'combines signals', including account-dependent behavior ('some accounts include usage inline'). It also prominently warns about the proxy nature of click-audience size, which is critical behavioral context. The description adds value beyond the annotations (readOnly, idempotent) without contradicting them.

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 information-dense but appropriately structured: purpose, mechanism, caveat, and return shape. It is longer than the minimal example but every sentence adds value, including the caveat and return object. A slight reorganization could make it more skimmable, but it remains efficient and front-loaded.

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 tool with no output schema and moderate complexity, the description is very complete. It specifies the return shape ('Returns { coupon_id, raw, click_audience?, estimated_redemptions?, notes[] }'), explains the data source, covers the caveat, and provides an alternative path for exact counts. It also links to line_manage_coupon for coupon_id, making the tool self-contained.

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 only 25% (only click_audience_id has a description). The description adds meaning for coupon_id ('comes from line_manage_coupon') and click_audience_id ('enrich the stats with click-through count'), but it does not explain 'oa' or 'response_format', leaving gaps. Given low schema coverage, the description partially compensates but is not fully sufficient.

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 'Read available stats for a LINE coupon' with a specific verb and resource. It distinguishes from sibling tools like line_get_message_stats by focusing on coupons, and clarifies that it provides available stats rather than true redemptions. The scope ('for a LINE coupon') is precise, and the mention of coupon_id provenance further disambiguates.

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 explicitly explains when to use the tool (to read available coupon stats) and provides a clear when-not: 'click-audience size approximates clickthroughs, NOT actual redemptions'. It offers an alternative for real counts ('build the coupon Flex with a postback action and listen via webhook') and instructs that coupon_id comes from line_manage_coupon. This meets the explicit when/when-not/alternatives criterion.

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