Edit image(s) (img2img)

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

With no annotations, the description carries the burden. It discloses that it returns edited image URLs and metadata, optionally saves locally, uses a configured API, and supports masks for region regeneration. It does not mention error handling, rate limits, or failure modes, but it does not contradict any annotations (none exist). The disclosure is adequate but not exhaustive, leaving some behavioral ambiguity.

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 description is a single, dense sentence that front-loads the core purpose and packs in essential details like image formats, mask, return behavior, and config dependency. It is concise with no fluff, though it is somewhat lengthy. The structure is logical and all information is relevant, earning a high score.

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?

Given 9 parameters, no output schema, and no annotations, the description leaves significant gaps. It explains some parameters (images, mask, save, model) but omits n, size, quality, and include_preview. It also gives a vague return description (URL(s) and metadata) without detailing the structure or error states. The tool is complex, and the description is not complete enough for an agent to use it fully correctly without further inference.

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 0%, so the description must compensate. It clarifies the format for images (path, URL, data: URI, or base64), explains the mask parameter, mentions save as optional, and notes that model defaults come from config. However, it does not address n, size, quality, or include_preview, leaving several parameters unexplained. With 9 parameters and minimal compensation, this is insufficient.

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 clearly states the tool edits, transforms, combines, or extends images via img2img, which distinguishes it from the sibling generate_image. It specifies the resource (images) and the action (edit) with concrete verbs, and references the OpenAI-compatible API. This is unambiguous and sets it apart from generation tools.

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 implies it is for editing existing images rather than generating new ones, and it explicitly notes that endpoint, key, and default model come from config, hinting at how to prepare. It does not explicitly name generate_image as the alternative for text-to-image, but the use of 'img2img' and the focus on editing provides clear context. No explicit exclusions are given, but the guidance is sufficient for an agent to select it appropriately.

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