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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new context: the check is free (no credits), it evaluates per image and per set, and it emits pass/warn/info lines rather than binary failure. It stops short of saying what happens on invalid or unfinished image sets.

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?

Two sentences, front-loaded with the action and scope, followed by the cost and return shape. Every clause carries information: rule coverage, price, and output format; nothing is filler.

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?

With non-destructive annotations and no output schema, the description adequately covers purpose, cost, and the shape of results (pass/warn/info per image and per set). It lacks only failure-mode behavior and explicit routing against check_marketplace_spec, which leaves a minor gap for a simple single-parameter read tool.

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 0% for the single image_set_id parameter, so the description must compensate. The phrase 'of a set' does convey that the argument identifies an image set, matching the UUID in the schema, but it adds no format, sourcing, or error semantics. With only one self-evident identifier, the gap is small but real.

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 a specific verb ('Checks') and resource ('finished images of a set') and enumerates the rule sources (Amazon main image, sizes, formats, Etsy 1 MB warning, Shopify limits). It does not explicitly name or contrast with the sibling tool check_marketplace_spec, so an agent must infer the split between the two.

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?

'Finished images' implies this runs after generation, which is useful implied context, and 'Free' signals no credit spend. However, there is no explicit when-to-use vs check_marketplace_spec guidance, no preconditions, and no statement about behavior when the set isn't yet complete.

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