List flash offers

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds no behavioral context beyond that: nothing about pagination behavior, result caps, how flash-offer availability is determined, or what the response shape is for a read-only listing.

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?

A single sentence with the usage trigger front-loaded via a colon, and no filler. Slightly dense in the trailing clause ('catalogue of one of their projects'), but nothing wasted.

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 read-only query tool with 36 filter parameters, no output schema and no pagination explanation in the description, the definition is thin. The absent output schema means the agent cannot learn from structured data what a result row contains or whether offset/limit pages carry a total count, and the description does not fill that gap.

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?

All 36 parameters carry schema descriptions at 100% coverage, including enums, defaults, ranges and subtle semantics (e.g. 'only `true` applies it; omit it otherwise'). The description adds no parameter guidance of its own, so the baseline of 3 is appropriate when the schema does all the work.

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 a specific verb (lists) and a precise resource (medias on a time-limited flash offer) scoped to one project's catalogue. The 'discounted / flash offer' framing differentiates it conceptually from growwer_search_project_medias or growwer_get_catalogue_media, though it never names those siblings 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?

There is a clear triggering condition — use it when the user is looking for discounted medias — which gives an agent a concrete entry point. It stops short of stating when *not* to use it or which of the many sibling search/catalogue tools to prefer instead.

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