clean_product_image_white_bg

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

With no annotations, the description carries the full behavioral burden and largely delivers: it discloses what gets altered (watermarks, overlays, background, lighting), what is preserved (shape, colors, features), and the output form (high-res WebP with AI review). It could additionally disclose whether the input is overwritten or how the result is delivered, but this is well above the minimum for a no-annotation tool.

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?

Five short sentences, each earning its place: core transformation, e-commerce context, preservation guarantees, aspect-ratio support, and output format. The most important operation is front-loaded, and there is no fluff or repetition of schema content; only minor tightening would be possible.

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 3-parameter transformation tool with no annotations and no output schema, the description covers the operation, target platforms, preservation behavior, aspect-ratio defaults, and output format. The remaining gap is how the high-res WebP is returned to the caller (path/URL), which the agent would need for downstream pipeline steps.

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 100%, so the schema fully documents input_path, aspect_ratio (enum values, output dimensions, and default), and additional_instructions. The description's 'default 1:1' mention merely restates the schema's aspect_ratio default, adding no new meaning, so the baseline 3 applies.

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 opens with a precise operation pair — 'Remove watermarks/overlays and replace background with pure white (#FFFFFF)' — including an exact color value, studio lighting, and preservation guarantees. This clearly differentiates it from the generic sibling clean_product_image and the generate_* tools, which create rather than transform. An agent can route correctly without opening the schema.

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?

'E-commerce ready for Amazon/eBay/Shopify' provides a clear use-case context: use this when preparing product listing images that need a white background. It stops short of a 5 because it does not explicitly name the generic clean_product_image alternative or state when-not-to-use conditions.

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