Edit image (WikiVibe)

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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), lowering the burden on the description. The text adds the useful provenance fact that sources are local file paths rather than URLs, but says nothing about whether originals are modified, where results are written, or model/quality defaults.

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 tight sentences, front-loaded with the verb and resource, with the parenthetical examples earning their place. The trailing sentence on local file paths partially duplicates the images schema description, but overall there is no padding.

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?

There is no output schema and the description never says what an edit returns or that output_path controls where the result lands. Combined with four undocumented parameters, an agent lacks enough context to invoke this confidently, especially around output handling.

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 only 43%: n, model, quality, and output_path carry no documentation anywhere. The description partially compensates for images and prompt semantics, but four of seven parameters remain entirely unexplained, so it does not meet the compensation burden for a low-coverage schema.

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?

States a specific verb and resource ('Edit one or more existing images with a prompt') and enumerates the edit modes (inpainting, restyle, object changes). The word 'existing' implicitly distinguishes it from generate_image, but it never names that sibling explicitly, so the differentiation is left for the agent to infer.

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?

Usage is only implied: the tool applies when you already have source images on local disk. Neither generate_image nor list_image_models is named, and there is no statement of when to prefer editing over generating, or of prerequisites such as source image format/size.

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