Venice Image Edit

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose output format (base64 PNG) and supports x402 wallet auth without a Venice account — useful. However, it doesn't mention rate limits, image size constraints, prompt sensitivity, or whether edits are destructive to the source — for an edit tool these would add meaningful context.

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?

Three concise sentences covering purpose, output, model options, and auth. Front-loaded with the core purpose. The operator-preference and auth details are useful additions that earn their place, though the structure could be slightly tighter.

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?

With no output schema and no annotations, the description provides reasonable context for a moderately complex image-editing tool. It explains output format, model defaults, and auth path, but with 5 parameters and undocumented fields like safe_mode, it leaves gaps that a complete offering would address.

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 40% (model and image_url have descriptions; prompt, safe_mode, aspect_ratio do not). The description adds value by naming model options and the default, but doesn't explain safe_mode semantics or aspect_ratio supported values beyond the schema enum. Partially compensates for the coverage gap but leaves undocumented parameters unexplained.

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 states the tool edits an image with a prompt and returns base64 PNG — a clear verb+resource+output statement. It distinguishes capability from sibling tools like venice_image_generate and venice_image_remove_bg by noting it modifies an existing image, though it doesn't explicitly name a differentiating sibling.

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 mentions operator preferences for models (default firered-image-edit, alternative qwen-image-edit) and highlights x402 wallet auth as an option, providing useful context. However, it doesn't explicitly state when to use this vs venice_image_multi_edit or venice_image_generate, nor any exclusions.

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