generate_image

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

With no annotations, the description carries the full burden and does disclose real behavioral traits: output goes to kie/assets/raw/, per-model credit costs (3cr to 100cr), latency (~4s for nano-banana-2-lite), and quality tiers. It stops short of covering auth/permission needs, failure modes, or what happens when a model rejects an aspect_ratio, so it is strong but not exhaustive.

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 purpose and profile_brief tip are correctly front-loaded, but the body becomes a dense catalog of ~15 model IDs and prices in one paragraph, which is hard to scan and near the limit of what belongs in a tool description rather than a referenced resource. Information density is high, but structure suffers.

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 9-parameter, no-output-schema tool this covers most of what an agent needs: output location, model selection guidance, and async handling is already documented in the schema's `wait` parameter. It lacks guidance on parameter interactions (e.g. aspect_ratio validity per model beyond a pointer) but is otherwise complete.

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 description coverage is 100%, so the baseline is 3, but the model guide meaningfully enriches the `model` parameter by mapping use-cases (blueprints, text/logos, anime, upscale, BG removal) to concrete model IDs and their tradeoffs. The remaining parameters get no semantic help in the description, so it does not reach 5.

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 opening sentence gives a specific verb and resource ('Generate an image using kie.ai') and the surrounding model guide makes it immediately distinguishable from siblings like generate_video, grok_image_edit, and seedream_layer_decompose, each of which is explicitly redirected to. An agent can tell what this tool is and is not 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?

Explicit routing rules are given: call profile_brief first for architecture/game-art/advertising/product-UI, use list_models filter="use-case" to explore, and delegating alternatives named for layer splitting, region refine, and editing. When-to-use and when-to-use-something-else are both stated.

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