generate_ai_background

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

No annotations are provided, so the description carries the full disclosure burden and meets it thoroughly: it discloses authentication requirements (MEIGEN_API_TOKEN or saved local config), purchased-credit gating, automatic upload of local files and HTTPS URLs, non-atomic batch behavior, lack of a server-enforced spending cap, exact retry semantics (same requestId, at most one retry after suggested wait), and recovery-action precedence over generic retry advice.

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 core purpose is front-loaded and the opening sentences are tight, but the description becomes a dense wall of operational policy — budget planning, requestId persistence, user-interaction language, and progress ownership — with some redundancy (e.g., asking only for missing material vs. explaining problems to the user). Most sentences carry information, but the length strains conciseness.

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 complex 6-parameter tool with no annotations and no output schema, the description is unusually complete: it covers auth, cost accounting, upload behavior, retry/recovery semantics, and return expectations ('structured status, handles, errors and completed URLs'). The only minor gap is that it doesn't describe the concrete shape of the success/failure return structure, but it says the caller owns presentation, which covers the essentials.

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 baseline is 3, and the description adds real value on top: mode/customPrompt interdependence ('custom=customPrompt required'), ratio and quality being smart/custom-only and ignored in white mode, and nuanced productImage semantics (do not pre-remove background, no credentials/fragments/custom ports, GIF first frame, never invent paths). This exceeds the baseline meaningfully.

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 first sentence states a specific verb and resource — 'Create one product photo with a new background' — and the three modes (white/smart/custom) are clearly enumerated. It distinguishes itself from siblings by explicitly naming remove_background for transparent PNG cutouts, so an agent can differentiate it without opening schemas.

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 explicit when-to-use and when-not-to-use guidance: 'Use remove_background for transparent PNG cutouts', 'Use the dedicated skill directly; skip unrequested prompt enhancement, preference loading and delegation', and 'Use live list_skills prices'. It also directs recovery flows to check_skill and names the sibling for pricing lookups, leaving little to inference.

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