Which integrations are available for this server?

Provides tools for generating and editing images using OpenAI's gpt-image-2 model, including iterative multi-turn editing sessions.

How do I use gpt-image-2-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gpt-image-2-mcp generate an image of a cat in space" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

gpt-image-2-mcp

by Borys520

Overview Schema Related Servers Score Discussions

TypeScript

Local

gpt-image-2-mcp

An MCP server that exposes OpenAI's gpt-image-2 (released 2026-04-21) to any MCP client — Claude Desktop, Claude Code, Cursor, MCP Inspector, etc.

Six tools:

Tool	What it does
`generate_image`	text → image
`edit_image`	1–8 reference images (+ optional mask) → image
`start_edit_session`	begin an iterative multi-turn edit
`continue_edit_session`	apply another refinement turn — previous output becomes the new input
`end_edit_session`	release a session
`list_edit_sessions`	show active sessions

Every generated image is saved to disk and returned inline so the calling model sees it.

Requirements

Node.js ≥ 20
An OpenAI API key on an org with gpt-image-2 access (Organization Verification may be required)

Related MCP server: Nano Banana MCP

Install

pnpm install
pnpm run build

This produces build/index.js, which is the server entry point.

Configure a client

Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "gpt-image-2": {
      "command": "node",
      "args": ["/absolute/path/to/gpt_image_2_mcp/build/index.js"],
      "env": {
        "OPENAI_API_KEY": "sk-..."
      }
    }
  }
}

Claude Code

Either add to ~/.claude.json under mcpServers with the same shape, or drop an .mcp.json next to your project:

{
  "mcpServers": {
    "gpt-image-2": {
      "command": "node",
      "args": ["/absolute/path/to/gpt_image_2_mcp/build/index.js"],
      "env": { "OPENAI_API_KEY": "sk-..." }
    }
  }
}

MCP Inspector (interactive testing)

pnpm run inspect

Launches the official inspector UI pointed at your local build.

Environment variables

Var	Required	Purpose
`OPENAI_API_KEY`	✅	Auth
`OPENAI_BASE_URL`		Override for proxies / enterprise routes
`OPENAI_ORG_ID`		Forwarded as `organization`
`OPENAI_PROJECT_ID`		Forwarded as `project`
`GPT_IMAGE_2_OUTPUT_DIR`		Global default for where images are saved. Absolute paths used as-is, relative resolved from CWD.
`GPT_IMAGE_2_MCP_DEBUG`		Set to `1` to emit verbose debug logs on stderr.
`GPT_IMAGE_2_SESSION_MAX`		Max concurrent in-memory edit sessions, LRU-evicted beyond this (default 20; `0` = no cap).
`GPT_IMAGE_2_SESSION_TTL_MS`		Idle TTL before an edit session is swept (default 3600000 = 1h; `0` = never expire).
`OPENAI_FORCE_RESPONSES_EDITS`		Set to `1` to pin edits to the Responses-API fallback route instead of `/v1/images/edits`. See Edit routing below.
`OPENAI_RESPONSES_EDIT_MODEL`		Host model used by the Responses-API fallback edit route (default `gpt-4.1-mini`). See Edit routing below.

Where images go

Unless overridden, each tool writes to:

<OS config dir>/gpt-image-2-mcp/output/<project-name>-<hash>/

macOS/Linux: ~/.config/gpt-image-2-mcp/output/<project>-<hash>/
Windows: %APPDATA%\gpt-image-2-mcp\output\<project>-<hash>\

<project>-<hash> is derived from the git root (if any) or the current working directory — each project gets its own folder so generations don't collide.

Per-call override: pass output_dir: "/some/path" to any tool.

Filenames look like image-20260422-150301-a1b2c3.png. If you pass filename_prefix: "hero-banner", it becomes image-20260422-150301-a1b2c3-hero-banner.png.

What the tools return

Every tool result contains:

An inline ImageContent block per generated image (so the LLM sees the image)
A text summary: applied settings, file path, token usage, estimated cost
structuredContent for programmatic consumers:

{
  "model": "gpt-image-2",
  "prompt": "…",
  "requested": { "size": "auto", "quality": "auto", "n": 1, "format": "png" },
  "applied":   { "size": "1024x1024", "quality": "high", "background": "opaque", "output_format": "png" },
  "images": [ { "file_path": "…", "filename": "…", "size_bytes": 123456, "mime_type": "image/png" } ],
  "usage":   { "input_tokens": …, "output_tokens": …, "total_tokens": …, "input_tokens_details": { … } },
  "cost_usd_estimated": 0.2112
}

Session tools additionally return session_id and turn.

Sizes

Default is auto (the model picks). You can pass:

A preset: 1024x1024, 1536x1024, 1024x1536
Any custom WxH where:
- Both edges are multiples of 16
- Max edge ≤ 3840px (outputs above 2K are beta)
- Aspect ratio within 1:3 and 3:1
- Total pixels between 655,360 and 8,294,400

Invalid sizes fail before the API call with a clear error — no wasted requests.

background: "transparent" is NOT supported by gpt-image-2. Use a model that supports it if you need alpha.

Iterative editing example

start_edit_session    prompt: "A coastal lighthouse at dawn, photorealistic", images: ["./sketch.png"]
  → session_id: edit-1761149123-a1b2c3d4, turn 1, saved to …/session-…-turn1.png

continue_edit_session session_id: "edit-…-a1b2c3d4", prompt: "Make the sky more orange. Keep everything else the same."
  → turn 2

continue_edit_session session_id: "edit-…-a1b2c3d4", prompt: "Add a small boat on the horizon."
  → turn 3

end_edit_session      session_id: "edit-…-a1b2c3d4"

Sessions are in-memory only and discarded on server restart — this is intentional (keeps the server stateless on the wire) and mirrors the Gemini MCP pattern.

Image inputs for `edit_image` and `start_edit_session`

Accepts any mix of:

Absolute path: /Users/me/photo.png
Relative path: ./photo.png (resolved from CWD)
file:///Users/me/photo.png
https://example.com/photo.png (downloaded, size-capped)
data:image/png;base64,iVBOR…

Up to 8 images per call. Each ≤ 50MB. PNG/WEBP/JPG supported.

Cost guardrails

The server ships no hard spending limits — you should watch your OpenAI usage dashboard. Each tool result includes an estimated cost in USD computed from the token usage returned by the API, plus an approximate pre-flight estimate logged to stderr.

Rough per-image cost at common sizes:

Quality	1024×1024	1024×1536 / 1536×1024
low	~$0.006	~$0.005
medium	~$0.053	~$0.041
high	~$0.211	~$0.165

Custom sizes scale with pixel count. Edit calls additionally tokenize input images at high fidelity — large reference images are expensive.

Edit routing

edit_image, start_edit_session, and continue_edit_session call POST /v1/images/edits directly. This is the canonical endpoint: it supports n > 1, masks, and returns accurate per-call token usage for cost estimation.

History: at launch (2026-04-21) the endpoint rejected gpt-image-2 (and gpt-image-1.5) with 400 Invalid value: 'gpt-image-2'. Value must be 'dall-e-2'. — an OpenAI-side bug. Versions ≤ 0.2.0 of this server therefore routed edits through the Responses API by default. OpenAI fixed the endpoint silently in early May 2026 (verified live 2026-06-11), and since 0.3.0 the direct endpoint is the default again.

The Responses-API workaround is kept as a fallback (src/utils/edit-via-responses.ts):

It engages automatically if the direct endpoint ever returns the launch-era 400 again (matched narrowly; the rejection is remembered for 10 minutes so only the first call in that window pays the failed attempt, then the direct endpoint is re-probed).
Set OPENAI_FORCE_RESPONSES_EDITS=1 to pin it explicitly.
The legacy OPENAI_USE_DIRECT_EDITS toggle from 0.2.0 is deprecated and ignored (its only meaningful setting was 1 — opt into the direct endpoint, which is now the default).

Fallback mechanics: input images are uploaded via the Files API (purpose: "vision"), a cheap host model (default gpt-4.1-mini, override with OPENAI_RESPONSES_EDIT_MODEL) is forced to invoke the image_generation tool, the base64 result is extracted, and uploaded files are deleted afterwards.

Fallback trade-offs versus the direct endpoint (only apply when the fallback is active — the tool result carries route: "responses" and a note when they do):

n > 1 is not supported — the Responses path returns one image per call.
Cost accounting undercounts — usage only reports the host chat model's text tokens; the image tool is billed separately (~$0.04–0.05 extra for a 1024×1536 medium edit).
Masks still work — uploaded and referenced via input_image_mask.file_id.

Troubleshooting

"OPENAI_API_KEY is not set" — add it to the env block of your MCP config.
403 / organization verification — gpt-image-2 may require Organization Verification on your OpenAI org. Check the dashboard.
429 — you hit the IPM (images per minute) cap for your tier. Lower n, or wait.
Image doesn't appear in the client — check the file path in the text block; the image is saved regardless of inline display.
Protocol disconnects silently — something printed to stdout. Check src/**/*.ts — all logs must use utils/logger.ts (stderr). This is the single biggest MCP footgun.

Development

pnpm run dev         # tsx watch
pnpm run typecheck   # tsc --noEmit
pnpm run build       # compile to build/
pnpm run inspect     # launch MCP Inspector

License

MIT

Available Tools

6 tools

continue_edit_sessionContinue Edit SessionA

Apply another edit turn to an existing session. The previous turn's output image is used as the input. Use short, focused prompts like "make the sky more orange" or "add a small boat on the horizon"; include "keep everything else the same" to limit drift. Returns the new image and the updated session.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes	The session id returned by start_edit_session.
`prompt`	Yes	Image description. gpt-image-2 handles very detailed prompts; use ALL CAPS or quote literal text you want rendered verbatim.
`size`	No	Output 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
`quality`	No	Edit quality — same levels as generate.	auto
`background`	No	Background 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_format`	No	File format. "png" (default, lossless), "jpeg" (smaller, lossy), "webp" (best compression). When omitted on continue_edit_session, the session's current format is kept.
`output_compression`	No	Compression level 0–100 for jpeg/webp outputs. Ignored for png. Defaults to 100 (minimal compression).
`filename_prefix`	No	Short label appended to the generated filename so you can find it later (e.g. "hero-banner"). Letters/digits/hyphens only; auto-sanitized.
`user`	No	Optional end-user identifier forwarded to OpenAI for abuse monitoring. Pass a stable hashed user ID, not PII.

Output Schema

ParametersJSON Schema

Name	Required	Description
`model`	Yes
`prompt`	Yes
`requested`	Yes
`applied`	Yes
`images`	Yes
`usage`	Yes
`cost_usd_estimated`	Yes
`route`	No	Which API route served the request (edit tools only): "direct" = /v1/images/edits, "responses" = Responses-API fallback (one image per call, undercounted cost).
`notes`	No	Caveats about how the request was served.
`session_id`	Yes
`turn`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Beyond annotations (which are sparse), the description explains the stateful behavior (each turn uses the previous output) and the return value (new image and updated session). No contradictions; adds value by clarifying the iterative process.

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?

Three sentences front-loaded with purpose, followed by usage guidelines and return value. No extraneous information; every sentence earns its place.

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 output schema exists, the description covers essential stateful behavior and return values. Could mention session expiry or error handling, but overall adequate for a complex tool with 9 parameters.

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 coverage is 100%, so the schema already documents all parameters. The description adds minimal parameter-specific meaning, mostly through usage examples in prompt. Baseline of 3 is appropriate.

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 clearly states the tool applies another edit turn to an existing session, using the previous turn's output as input. It distinguishes itself from sibling tools like start_edit_session and generate_image by specifying session-based iterative editing.

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 concrete advice on prompt style ('short, focused prompts') and includes tips to limit drift ('keep everything else the same'). While it doesn't explicitly state when not to use the tool or name alternatives, the context implies its iterative nature.

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

edit_imageEdit ImageA

Edit or compose images with gpt-image-2. Give 1–8 input images plus a text prompt; optionally include a PNG mask whose transparent regions mark what to change (mask applies to the first image). Great for: swap backgrounds, retouch products, combine multiple reference images into one composition, maintain a character across scenes. gpt-image-2 always processes inputs at high fidelity (no input_fidelity knob needed). The edited image is saved to disk and returned inline.

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	Yes	Image description. gpt-image-2 handles very detailed prompts; use ALL CAPS or quote literal text you want rendered verbatim.
`images`	Yes	Input images. Each entry can be: an absolute file path, a relative path (resolved from CWD), a file:// URL, an http(s):// URL, or a data:image/...;base64,... URL. PNG/WEBP/JPG, up to 50MB each.
`mask`	No	Optional 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`.
`size`	No	Output 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
`quality`	No	Edit quality — same levels as generate.	auto
`n`	No	How many images to generate (1–10). Each counts toward rate limits and cost.
`background`	No	Background 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_format`	No	File format. "png" (default, lossless), "jpeg" (smaller, lossy), "webp" (best compression). When omitted on continue_edit_session, the session's current format is kept.
`output_compression`	No	Compression level 0–100 for jpeg/webp outputs. Ignored for png. Defaults to 100 (minimal compression).
`output_dir`	No	Absolute 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_prefix`	No	Short label appended to the generated filename so you can find it later (e.g. "hero-banner"). Letters/digits/hyphens only; auto-sanitized.
`user`	No	Optional end-user identifier forwarded to OpenAI for abuse monitoring. Pass a stable hashed user ID, not PII.

Output Schema

ParametersJSON Schema

Name	Required	Description
`model`	Yes
`prompt`	Yes
`requested`	Yes
`applied`	Yes
`images`	Yes
`usage`	Yes
`cost_usd_estimated`	Yes
`route`	No	Which API route served the request (edit tools only): "direct" = /v1/images/edits, "responses" = Responses-API fallback (one image per call, undercounted cost).
`notes`	No	Caveats about how the request was served.

TDQS

A4.1/5.0

Behavior4/5

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

Beyond annotations (which show non-destructive, non-readonly), the description adds that inputs are processed at high fidelity and the result is saved to disk and returned inline. It does not cover rate limits or detailed auth needs, but annotations already cover safety profile.

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?

The description is two sentences plus a list of use cases. It is front-loaded and efficient, wasting no words while providing necessary context. Slightly longer than necessary but still concise.

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 12 parameters, full schema coverage, and an output schema, the description adequately covers the core functionality, mask usage, and behavioral notes. It does not mention session tools or rate limits, but the main points are addressed.

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 coverage is 100%, so all parameters are documented in the schema. The description adds minimal extra parameter meaning (e.g., mask applies to first image), which is already in the schema. Baseline 3 is appropriate.

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 clearly states 'Edit or compose images with gpt-image-2' using a specific verb and resource. It lists concrete use cases (swap backgrounds, retouch, combine) and implicitly distinguishes from sibling generate_image by focusing on editing existing images.

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 explicit context: input 1-8 images, text prompt, optional mask. Use cases are listed, giving clear scenarios. However, it does not explicitly state when to use alternatives like generate_image or start_edit_session, though the distinction is inferable.

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

end_edit_sessionEnd Edit SessionA

DestructiveIdempotent

Free an iterative-edit session. Safe to skip — sessions are in-memory only and are discarded on server restart — but calling this frees memory sooner and keeps list_edit_sessions tidy.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes	The session id to end.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ended`	Yes
`session_id`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds valuable context: sessions are in-memory only, discarded on server restart, and calling the tool frees memory sooner. No contradictions found.

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?

Three sentences, all essential. Front-loaded with the main action, then adds usage context and benefits. No filler or redundancy.

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 simplicity (1 param, high schema coverage, output schema exists), the description covers purpose, usage, and side effects. Could mention what happens if session_id is invalid, but the idempotentHint implies safe handling.

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 coverage is 100%. The parameter 'session_id' is well-documented in the schema with minLength and description. The tool description does not add further parameter details, which is acceptable given the schema coverage.

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?

Clearly states the tool ends an iterative-edit session and distinguishes from siblings like start_edit_session by noting it is optional cleanup. The verb 'Free' and resource 'iterative-edit session' are specific.

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?

Explicitly states when to use (to free memory sooner, keep list tidy) and when not to use (safe to skip because sessions are discarded on restart). Provides alternative: not calling the tool.

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

generate_imageGenerate ImageA

Generate an image from a text prompt using OpenAI's gpt-image-2 model. The image is written to disk and also returned inline so you can see it. gpt-image-2 handles photoreal, illustrations, infographics, multilingual text (incl. CJK), and complex structured visuals. It does NOT support transparent backgrounds. Sizes accept presets or any custom "WxH" where edges are multiples of 16, max edge 3840px, aspect ratio within 1:3–3:1, total pixels 655K–8.29M.

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	Yes	Image description. gpt-image-2 handles very detailed prompts; use ALL CAPS or quote literal text you want rendered verbatim.
`size`	No	Output 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
`quality`	No	Generation quality. "low" for fast drafts, "medium" balanced (default when model picks), "high" for dense layouts and text, "auto" lets the model choose.	auto
`n`	No	How many images to generate (1–10). Each counts toward rate limits and cost.
`background`	No	Background 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_format`	No	File format. "png" (default, lossless), "jpeg" (smaller, lossy), "webp" (best compression). When omitted on continue_edit_session, the session's current format is kept.
`output_compression`	No	Compression level 0–100 for jpeg/webp outputs. Ignored for png. Defaults to 100 (minimal compression).
`moderation`	No	Moderation strictness. "auto" (default) applies standard safety filtering; "low" is less restrictive (still subject to OpenAI policy).	auto
`output_dir`	No	Absolute 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_prefix`	No	Short label appended to the generated filename so you can find it later (e.g. "hero-banner"). Letters/digits/hyphens only; auto-sanitized.
`user`	No	Optional end-user identifier forwarded to OpenAI for abuse monitoring. Pass a stable hashed user ID, not PII.

Output Schema

ParametersJSON Schema

Name	Required	Description
`model`	Yes
`prompt`	Yes
`requested`	Yes
`applied`	Yes
`images`	Yes
`usage`	Yes
`cost_usd_estimated`	Yes
`route`	No	Which API route served the request (edit tools only): "direct" = /v1/images/edits, "responses" = Responses-API fallback (one image per call, undercounted cost).
`notes`	No	Caveats about how the request was served.

TDQS

A4.6/5.0

Behavior5/5

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

The description discloses that images are written to disk and returned inline, outlines quality/compression trade-offs, rate limit implications of 'n', and the unsupported transparent backgrounds. This adds substantial context beyond the annotations (readOnlyHint=false, openWorldHint=true).

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?

The description is well-structured with the main purpose first, then capabilities, restrictions, and parameter context. While it is a bit lengthy, every sentence adds value and there is no redundancy.

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?

Given the tool's complexity (11 parameters, output schema present), the description covers core functionality, constraints, default behavior, and side effects (disk write, rate limits). No gaps are apparent.

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?

The input schema already covers 100% of parameters with descriptions. The description adds extra usage guidance (e.g., using ALL CAPS for literal text, size constraints, 'background: opaque' for filled backgrounds), enhancing the schema meaning.

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 clearly states 'Generate an image from a text prompt using OpenAI's gpt-image-2 model.' It lists supported image types and explicitly mentions it does NOT support transparent backgrounds, distinguishing it from sibling editing tools.

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?

The description provides clear context for using the tool (text-to-image generation) and hints at when not to use it (transparent backgrounds). It does not explicitly mention sibling tools as alternatives, but given the sibling set, confusion is unlikely.

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

list_edit_sessionsList Edit SessionsA

Read-onlyIdempotent

List active iterative-edit sessions (in-memory only, discarded on server restart). Useful to recover a session_id after a client reconnect.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`sessions`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Adds critical context beyond annotations: 'in-memory only, discarded on server restart' and 'active' sessions. Annotations already declare read-only, idempotent, non-destructive, but description explains ephemeral nature.

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?

Two sentences, no wasted words. Front-loaded with key purpose and behavior. Every sentence adds value.

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?

Given zero parameters and an output schema, the description fully covers what the agent needs: what the tool returns (list of sessions) and why it exists. No gaps.

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?

No parameters, so schema coverage is 100%. Description adds no parameter info, but none needed. Baseline score of 4 is appropriate.

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?

Description clearly states 'list active iterative-edit sessions', specifying verb, resource, and scope. Distinguishes from sibling tools like start_edit_session or continue_edit_session.

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 explicit use case: 'recover a session_id after a client reconnect'. While it doesn't explicitly exclude other uses, it gives clear context for when this tool is useful.

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

start_edit_sessionStart Iterative Edit SessionA

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.

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	Yes	Image description. gpt-image-2 handles very detailed prompts; use ALL CAPS or quote literal text you want rendered verbatim.
`images`	Yes	1–8 input images to seed the session (same source formats as edit_image).
`mask`	No	Optional 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`.
`size`	No	Output 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
`quality`	No	Edit quality — same levels as generate.	auto
`background`	No	Background 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_format`	No	File format. "png" (default, lossless), "jpeg" (smaller, lossy), "webp" (best compression). When omitted on continue_edit_session, the session's current format is kept.
`output_compression`	No	Compression level 0–100 for jpeg/webp outputs. Ignored for png. Defaults to 100 (minimal compression).
`output_dir`	No	Absolute 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_prefix`	No	Short label appended to the generated filename so you can find it later (e.g. "hero-banner"). Letters/digits/hyphens only; auto-sanitized.
`user`	No	Optional end-user identifier forwarded to OpenAI for abuse monitoring. Pass a stable hashed user ID, not PII.

Output Schema

ParametersJSON Schema

Name	Required	Description
`model`	Yes
`prompt`	Yes
`requested`	Yes
`applied`	Yes
`images`	Yes
`usage`	Yes
`cost_usd_estimated`	Yes
`route`	No	Which API route served the request (edit tools only): "direct" = /v1/images/edits, "responses" = Responses-API fallback (one image per call, undercounted cost).
`notes`	No	Caveats about how the request was served.
`session_id`	Yes
`turn`	Yes

TDQS

A4.4/5.0

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.5/5.0

Disambiguation5/5

Each tool has a distinct purpose: generate_image for single generation, edit_image for one-shot edits, start/continue/end_edit_session for iterative multi-turn editing, and list_edit_sessions for session management. There is no overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., edit_image, generate_image, start_edit_session). The naming is predictable and follows the same convention throughout.

Tool Count5/5

With 6 tools, the server is well-scoped for image generation and editing. It covers the core functionality without being excessive or insufficient.

Completeness5/5

The tool surface covers the full lifecycle: single generation, one-shot edit, iterative editing sessions (start, continue, end), and session listing. No obvious gaps for the domain.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

OpenAI Tools MCP Server B
ai.com.mcp
Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.
Image & Video Processing Audio Processing Multimedia Processing
927
Claude Imagine AOAuth
com.claudeimagine
Generate AI images and videos from any compatible MCP client.
AI & Machine Learning Image & Video Processing
42
mcp-qwen-image
io.github.AceDataCloud
MCP server for Qwen Image 3 AI image generation
AI & Machine Learning Image & Video Processing
1
clipkit A
dev.clipkit
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
Multimedia Processing Image & Video Processing
15212

Related MCP Servers

imagegen-mcp
AI & Machine Learning Image & Video Processing
spartanz51
A
license
Not graded
quality
D
maintenance
MCP server that wraps OpenAI's image generation and editing APIs, enabling text-to-image and image-to-image operations via tools.
Updated a year ago (2025-05-02 08:47 UTC)
249
38
ISC
Nano Banana MCP
AI & Machine Learning Image & Video Processing
jiwon86
F
license
A
quality
D
maintenance
Wraps Google Gemini's image generation API as an MCP server, enabling text-to-image, image editing, and grounded search workflows from any MCP client.
Updated 5 months ago (2026-03-25 06:17 UTC)
2
OpenAI Image MCP Server
Image & Video Processing AI & Machine Learning
aleslanger
A
license
B
quality
C
maintenance
A Model Context Protocol server that enables generating, editing, and multi-turn editing of images using OpenAI's gpt-image models directly from Claude or any MCP client.
Updated 2 months ago (2026-07-14 19:33 UTC)
4
1
MIT
OpenAI Image MCP
AI & Machine Learning Image & Video Processing
hi275
F
license
Not graded
quality
C
maintenance
A lightweight remote MCP server for generating images using OpenAI's image models, exposing a generate_image tool.
Updated a month ago (2026-07-29 08:06 UTC)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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

gpt-image-2-mcp

Requirements

Install

Configure a client

Claude Desktop

Claude Code

MCP Inspector (interactive testing)

Environment variables

Where images go

What the tools return

Sizes

Iterative editing example

Image inputs for edit_image and start_edit_session

Cost guardrails

Edit routing

Troubleshooting

Development

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Image inputs for `edit_image` and `start_edit_session`