Generate image (GPT-image)

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the external API dependency, config-based endpoint/key/model resolution, per-call overrides, and the return value (image URL plus local path under save conditions). This is solid coverage, though it could also mention rate limits, errors, or data-sent-to-third-party implications.

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 three focused sentences with no filler. The primary purpose is front-loaded, and each sentence contributes: what it does, how configuration works, and what it returns.

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?

The description captures the core flow, configuration dependency, and return contract, but there is no output schema and no annotations. Missing details such as accepted size/quality values, what include_preview does, save_dir mechanics, and error behavior leave meaningful gaps for an agent invoking this tool correctly in varied cases.

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, and it does add meaning for n ('one or more'), model (per-call override), and save (triggers local path). However, it does not explain size, quality, include_preview, or valid value formats, leaving several parameters dependent on their self-explanatory names only.

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 opens with a specific action and resource: 'Generate one or more images from a text prompt.' This clearly identifies the tool's purpose and naturally distinguishes it from the sibling edit_image, which would modify existing images rather than generate new ones.

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 provides useful context by pointing to get_config / set_config and explaining that per-call arguments override defaults, implying the tool relies on prior configuration. However, it does not explicitly state when to choose generate_image over edit_image or list_image_models, so usage guidance remains implicit rather than explicit.

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