openai-imagegen-mcp

Overview Schema Source Related Servers Discussions Admin

Edit image

edit_image

Modify a local image or create a new image from local references, save the result to local files, and return downscaled previews with original paths.

Instructions

Edit local images, or create a new image from local reference images, and save the result to local files. Returns downscaled previews and the paths of the originals. The first image is the one edited; the others serve as references. 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.
`mask`	No	Local path of a mask for the first image, with an alpha channel. Transparent areas mark what to replace. Describe the complete final image in the prompt, not only the change. Cannot be combined with markup.
`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.
`images`	Yes	Local paths of PNG, JPEG or WebP input images.
`markup`	No	Local path of a transparent PNG with annotations showing where to edit, the same dimensions as the first image. Cannot be combined with mask.
`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
`output_format`	No	Defaults to png.
`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

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnly=false, openWorld=true, idempotent=false and destructive=false, and the description adds real context: results are written to local files, previews are downscaled while originals keep full paths, and the call can return an asynchronous "running" status. It omits cost/latency implications, moderation behavior, and what overwriting an existing output path does.

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

Conciseness5/5

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

Four short sentences, front-loaded with the core capability, then the image-ordering rule, then the async follow-up. Nothing is repeated from the title and no sentence is filler.

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

Completeness4/5

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

An output schema exists, so return values need limited explanation, and the description still covers the async continuation path and file outputs. With 14 parameters, the description reasonably leans on the 93%-covered schema, though it could say more about how mask/markup and n interact with the edit target.

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

Parameters4/5

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

Schema coverage is already 93%, so the schema carries most parameter meaning. The description still adds a non-obvious semantic rule for the `images` array ordering (first = target, rest = references) plus the file-write behavior, which the schema does not convey.

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?

States concrete verbs and resources: edit local images or create a new image from local reference images, then save results to local files. This clearly separates it from a pure text-to-image generator like generate_image because it requires local input images, but it never names that sibling explicitly.

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?

Provides actionable routing: the first image is the one edited, the rest are references, and if the returned status is "running" the agent must call get_image_result with the job_id. It does not state when to prefer generate_image over this tool or when editing is inappropriate.

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

Deploy Server