openai-imagegen-mcp

Overview Schema Source Related Servers Discussions Admin

Generate image

generate_image

Generate images from English text prompts and save originals locally while returning downscaled previews and file paths; supports PNG, JPEG, WebP, and animated GIF output.

Instructions

Generate images from a text prompt and save them to local files. Returns downscaled previews and the paths of the originals. Supports raster output and animated GIF. If the result has status "running", call get_image_result with its job_id.

Input Schema

Name	Required	Description
`n`	No	Number of images, at most 4.
`size`	No	"auto" or WIDTHxHEIGHT, such as 1024x1024, 1536x1024 or 1024x1536. Custom sizes use multiples of 16 and an aspect ratio from 1:3 to 3:1.
`model`	No	gpt-image-2.6-flare is the default and suits fast iteration. gpt-image-2.6-sunburst suits work with demanding requirements for detail, layout or edit accuracy.
`prompt`	Yes	Description of the desired image or edit. Must be written in English. Keep text that should appear in the image in its original language, in quotes.
`quality`	No	Rendering quality. Use low for drafts. Compare medium and high for small text or dense information.
`workspace`	No	Your current working directory. Only its last segment is used, to name the folder that groups saved images. Omit it if you do not know the directory; never guess.
`background`	No	Transparent cannot be used with output_format jpeg.
`complexity`	No	How much the model plans before rendering. Defaults to high, which suits dense text and layouts but takes longer. Start with low for targeted edits.
`moderation`	No
`frame_count`	No	GIF only. Number of frames.
`output_format`	No	Defaults to png. Access to gif can depend on the account.
`frame_duration_ms`	No	GIF only. Delay per frame in milliseconds.
`output_compression`	No	Compression level for jpeg or webp output.

Output Schema

Name	Required	Description	Default
`next`	No
`error`	No
`usage`	No
`images`	No
`job_id`	No
`status`	Yes
`elapsed_seconds`	No
`revised_prompts`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 5, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations declare a non-read-only, non-idempotent, open-world write, and the description adds real substance beyond them: images are written to local files, previews are downscaled while originals are returned as paths, and the operation may return a job that is still running. It does not disclose cost, rate limits, or where on disk files land, which keeps it off a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with what the tool produces before the async fallback instruction. "Supports raster output and animated GIF" mildly overlaps the output_format enum but still frames the tool's scope early.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter generative tool with an output schema, the description covers the essentials an agent needs: what is produced, where it is saved, what the return contains, and how to handle a still-running job. Nothing required to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 92%, so the schema already explains prompt, size, model, quality, GIF frame settings, and compression. The description adds no parameter-level meaning of its own, which is the expected baseline when the schema does the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ("Generate images from a text prompt") plus the side effect ("save them to local files") and output modes (raster, GIF). It does not explicitly distinguish itself from edit_image, though the async handoff to get_image_result gives partial sibling routing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"If the result has status 'running', call get_image_result with its job_id" is explicit conditional guidance naming the alternative tool and parameter to pass. It lacks any statement about when to call generate_image versus edit_image, which is the remaining ambiguity among siblings.

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

Deploy Server