Skip to main content
Glama

Start Iterative Edit Session

start_edit_session

Begin a multi-turn image editing session. Provide initial images and a prompt to start iterative refinements, returning a session ID for subsequent edits.

Instructions

Begin a stateful multi-turn edit session. Returns a session_id you then pass to continue_edit_session to iteratively refine the image (each turn uses the previous turn's output as the input). Use end_edit_session when done.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
promptYesImage description. gpt-image-2 handles very detailed prompts; use ALL CAPS or quote literal text you want rendered verbatim.
imagesYes1–8 input images to seed the session (same source formats as edit_image).
maskNoOptional PNG mask — fully transparent pixels mark the editable region. Must match the first input image's dimensions and be <4MB. Accepts the same source types as `images`.
sizeNoOutput dimensions. "auto" (default), one of the presets "1024x1024", "1536x1024", "1024x1536", or a custom "WxH" where both edges are multiples of 16, max edge ≤ 3840px, aspect ratio within 1:3–3:1, and total pixels 655,360–8,294,400. Outputs above 2K are beta.auto
qualityNoEdit quality — same levels as generate.auto
backgroundNoBackground behavior. "opaque" forces a filled background; "auto" lets the model pick. gpt-image-2 does NOT support transparent backgrounds — use a different model for that.auto
output_formatNoFile format. "png" (default, lossless), "jpeg" (smaller, lossy), "webp" (best compression). When omitted on continue_edit_session, the session's current format is kept.
output_compressionNoCompression level 0–100 for jpeg/webp outputs. Ignored for png. Defaults to 100 (minimal compression).
output_dirNoAbsolute or relative directory where generated images should be written. Defaults to $GPT_IMAGE_2_OUTPUT_DIR or a per-project subfolder under the OS config dir. The directory is created if missing.
filename_prefixNoShort label appended to the generated filename so you can find it later (e.g. "hero-banner"). Letters/digits/hyphens only; auto-sanitized.
userNoOptional end-user identifier forwarded to OpenAI for abuse monitoring. Pass a stable hashed user ID, not PII.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelYes
promptYes
requestedYes
appliedYes
imagesYes
usageYes
cost_usd_estimatedYes
routeNoWhich API route served the request (edit tools only): "direct" = /v1/images/edits, "responses" = Responses-API fallback (one image per call, undercounted cost).
notesNoCaveats about how the request was served.
session_idYes
turnYes
Behavior4/5

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

The description discloses the stateful nature and the iterative workflow (each turn uses previous output). Annotations already show it's not read-only, not destructive, not idempotent, and open world. The description adds context about session lifecycle but doesn't detail auth or rate limits, which are acceptable given the annotation coverage.

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?

The description is extremely concise: three short sentences that convey the purpose, usage flow, and termination. Every sentence provides necessary information with no redundancy or irrelevant details.

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?

Given the tool's complexity (11 parameters, 2 required, output schema present), the description adequately covers the session lifecycle and key return value (session_id). It could mention the output schema or behavior on errors, but the presence of an output schema reduces the need for that in the description.

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?

The description does not add parameter-specific meaning beyond what the input schema already provides (schema coverage is 100%). All parameters have individual descriptions in the schema, so the description's role is fulfilled at a baseline level without extra semantic enrichment.

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

Purpose5/5

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

The description explicitly states 'Begin a stateful multi-turn edit session', specifying the verb 'begin' and the resource 'edit session'. It distinguishes itself from siblings like 'edit_image' (single edit) and 'generate_image' by framing it as a multi-turn iterative process.

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

Usage Guidelines5/5

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

The description provides clear when-to-use guidance: it explains that the returned session_id is used with 'continue_edit_session' for iterative refinement and that 'end_edit_session' should be called when done. This contrasts with the sibling 'edit_image' which is for single-turn edits.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Borys520/gpt-image-2-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server