Remove an image background

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds material behavior: color is instant and offline, ml relies on a U^2-Net model, and auto falls back to ML only when installed. This reveals performance and dependency traits beyond what JSON schema could convey, though it could note the ML model download requirement more explicitly.

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, zero waste. The core action is front-loaded, and the method guidance is packed efficiently in the second sentence with parenthetical tradeoffs. Every clause earns its place.

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 15-parameter tool with an output schema present, the description covers the central ambiguity — method selection — thoroughly. The presence of an output schema relieves the need to describe return values, and the many decorative parameters (feather, softness, tolerance, background) are fully documented in the schema. The main unstated gap is ML model installation requirements.

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 all 15 parameters are documented structurally. The description adds real semantic value not in the schema by explaining what the method values (color/ml/auto) actually do and their tradeoffs, which the schema merely lists as 'auto, color or ml.' That elevation of the key decision parameter justifies above-baseline.

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 the specific action 'Make the background transparent,' which is a clear verb+resource statement that the title reinforces. Among 14 siblings (resize, crop, rotate, transform, convert, etc.), background removal is a unique purpose, so there is no ambiguity about what this tool does.

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 concrete method-selection guidance: 'color' for flat border product/logo shots (instant, offline), 'ml' for arbitrary backgrounds, and 'auto' picking ML when the model is installed. This is clear when-to-use context for the internal methods, though it doesn't explicitly name sibling exclusions — not strictly needed since the purpose is unique among siblings.

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