Skip to main content
Glama

imagen-mcp

Minimal MCP server for OpenAI GPT Image 2.5. Two tools, two models.

Alias

API model

Use

flare (default)

gpt-image-2.5-flare

Fast, general purpose

sunburst

gpt-image-2.5-sunburst

Slower, higher precision

Setup

Install from npm:

npm install -g @falldownthesystem/imagen-mcp

Or build from source:

npm install
npm run build

Set OPENAI_API_KEY in the environment, or put it in a .env file next to package.json.

Optional environment variables:

  • IMAGEN_OUTPUT_DIR: default directory for saved images (default ./output).

  • IMAGEN_DEFAULT_MODEL: flare or sunburst (default flare).

Related MCP server: MCP OpenAI Image Generation Server

Client config

Claude Code (.mcp.json) or Claude Desktop, using the npm package:

{
	"mcpServers": {
		"imagen": {
			"command": "npx",
			"args": ["-y", "@falldownthesystem/imagen-mcp"],
			"env": {
				"OPENAI_API_KEY": "sk-...",
				"IMAGEN_OUTPUT_DIR": "C:/Users/me/Pictures/imagen"
			}
		}
	}
}

Or with a local build, use "command": "node" and "args": ["path/to/imagen-mcp/dist/index.js"].

Claude Code one-liner:

claude mcp add imagen -e OPENAI_API_KEY=sk-... -- npx -y @falldownthesystem/imagen-mcp

Tools

generate_image

Text to image. Required: prompt.

Option

Values

Default

Notes

moderation

auto, low

low

OpenAI content filter strictness. low refuses fewer borderline prompts; OpenAI usage policies still apply. The API default is auto; this tool sends low unless set.

edit_image

Reference images to image. Required: prompt, images. The model regenerates the whole picture guided by the references and the prompt. Without a mask, the prompt alone decides what changes.

Option

Values

Default

Notes

images

1 to 16 file paths

required

png, jpeg, or webp. The first image is the main subject; extra images supply elements to combine, such as a logo or a style reference. Relative paths resolve against the server working directory.

mask

file path

none

PNG with an alpha channel, same width and height as the first image. Fully transparent pixels mark the region the model may repaint; opaque pixels mark what to keep. Use for inpainting one area or filling an extended canvas. It is guidance, not a hard pixel lock.

There is no input_fidelity option. The GPT Image 2.5 models always process reference images at high fidelity, and the API rejects the parameter. Faces, logos, text, and textures from the references are preserved by default.

Shared options

Only the options you set are sent to the API. The default column shows what applies when an option is omitted.

Option

Values

Default

Notes

prompt

text, up to 32000 chars

required

model

flare, sunburst

flare

flare (gpt-image-2.5-flare) is fast and general purpose. sunburst (gpt-image-2.5-sunburst) is slower with higher precision. Same token price. IMAGEN_DEFAULT_MODEL env changes the default.

size

auto, 1024x1024, 1536x1024, 1024x1536, WIDTHxHEIGHT

auto

Custom sizes: multiples of 16, ratio 1:3 to 3:1, long edge up to 3840. Overrides aspect_ratio.

aspect_ratio

1:1, 3:2, 2:3, 4:3, 3:4, 16:9, 9:16, 21:9, 9:21

none

Combined with long_edge to compute a size.

long_edge

256 to 3840

1536

Only used with aspect_ratio.

quality

low, medium, high, xhigh, max, auto

auto

Higher tiers add detail and cost more output tokens. auto lets the model choose and may pick an expensive tier. Set it explicitly to control cost.

background

transparent, opaque, auto

auto

transparent gives an alpha background for stickers, logos, and cut-outs. Needs png or webp.

output_format

png, jpeg, webp

png

Also sets the file extension.

output_compression

0 to 100

100

jpeg and webp only. Works like JPEG quality: lower is smaller with more artifacts.

n

1 to 10

1

Number of separate variations generated from the same prompt in one call. Each costs its own output tokens.

output_dir

directory path

IMAGEN_OUTPUT_DIR env, else ./output

Relative to the server working directory.

file_name

base name without extension

timestamp plus a slug of the prompt

With n greater than 1, a -1, -2 suffix is added.

return_image

boolean

false

Also return each image inline as MCP image content, so the client shows it and the model can inspect it. Adds about 1.4 MB of context per 1024x1024 png. The file is saved to disk either way.

The result lists the saved file paths, the model, the size, and token usage.

Available Tools

2 tools
edit_imageEdit imageA

Edit, restyle, or combine 1-16 reference images with a text prompt using OpenAI GPT Image 2.5. The whole picture is regenerated; without a mask the prompt decides what changes. Saves files to disk and returns paths and token usage.

ParametersJSON Schema
NameRequiredDescriptionDefault
nNoNumber of variations to generate; each costs output tokens. Files get -1, -2 suffixes. Default 1.
maskNoPath of a PNG with alpha, same size as first image. Transparent pixels = region to repaint (guidance, not a hard lock). Default none.
sizeNoauto | 1024x1024 | 1536x1024 | 1024x1536 | WIDTHxHEIGHT (multiples of 16, ratio 1:3..3:1, max edge 3840). Overrides aspect_ratio. Default auto.
modelNoflare = fast, general purpose. sunburst = slower, higher precision. Same price. Default flare.
imagesYesPaths of 1-16 reference images (png/jpeg/webp). First = main subject; others = elements to combine. Relative to server cwd.
promptYesImage description, or the change to make when editing.
qualityNoHigher = more detail, more output tokens. auto lets the model choose (may be costly). Default auto.
file_nameNoBase name without extension. Default timestamp + prompt slug.
long_edgeNoLonger side in px, used with aspect_ratio. Default 1536.
backgroundNotransparent needs png or webp. Default auto.
output_dirNoSave directory. Default IMAGEN_OUTPUT_DIR env or ./output (relative to server cwd).
aspect_ratioNoComputes size together with long_edge. Default none.
return_imageNoAlso return the image inline (base64, ~1.4 MB per 1024x1024 png) so it can be viewed. File is saved either way. Default false.
output_formatNoAlso the file extension. Default png.
input_fidelityNohigh keeps faces, text, logos and unmasked areas faithful; costs more input tokens. Default low.
output_compressionNojpeg/webp quality like JPEG: lower = smaller file, more artifacts. Default 100.

Output Schema

ParametersJSON Schema
NameRequiredDescription
sizeYes
filesYes
modelYes
usageNo

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the annotations, the description discloses important non-obvious behavior: the entire picture is regenerated, and without a mask the prompt determines what changes. It also states the side effects of saving files to disk and returning paths plus token usage, which helps the agent anticipate results beyond the schema.

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 three tightly written sentences with no filler. It front-loads the core purpose, then adds the key behavioral caveat about regeneration and masks, and closes with the output side effect. 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?

For a tool with 16 parameters, the description gives enough high-level orientation to avoid misuse, while the rich schema and output schema carry the remaining parameter-level detail. It could be slightly stronger by explicitly naming the sibling alternative for pure generation, but it is still complete enough for effective invocation.

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 input schema already provides detailed descriptions for all 16 parameters with 100% coverage, so the description does not need to repeat parameter details. It does add a small amount of conceptual glue, such as the relationship between masks, prompts, and regeneration, but this is not substantial enough to raise the score above the high-coverage baseline.

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 states a specific action set (edit, restyle, combine) against a concrete resource (1-16 reference images with a text prompt), and its wording inherently differentiates it from the sibling generate_image, which would not involve reference images. It also clarifies that the output is a regenerated image rather than a targeted patch.

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 makes clear this tool is for reworking or combining existing reference images with a prompt, which gives an agent a solid context for when to choose it over generate_image. It does not explicitly name the alternative or provide a when-not-to-use rule, so it stops short of a 5.

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 images from a text prompt with OpenAI GPT Image 2.5. Saves files to disk and returns paths and token usage.

ParametersJSON Schema
NameRequiredDescriptionDefault
nNoNumber of variations to generate; each costs output tokens. Files get -1, -2 suffixes. Default 1.
sizeNoauto | 1024x1024 | 1536x1024 | 1024x1536 | WIDTHxHEIGHT (multiples of 16, ratio 1:3..3:1, max edge 3840). Overrides aspect_ratio. Default auto.
modelNoflare = fast, general purpose. sunburst = slower, higher precision. Same price. Default flare.
promptYesImage description, or the change to make when editing.
qualityNoHigher = more detail, more output tokens. auto lets the model choose (may be costly). Default auto.
file_nameNoBase name without extension. Default timestamp + prompt slug.
long_edgeNoLonger side in px, used with aspect_ratio. Default 1536.
backgroundNotransparent needs png or webp. Default auto.
moderationNoOpenAI content filter. low refuses fewer borderline prompts. Default low.
output_dirNoSave directory. Default IMAGEN_OUTPUT_DIR env or ./output (relative to server cwd).
aspect_ratioNoComputes size together with long_edge. Default none.
return_imageNoAlso return the image inline (base64, ~1.4 MB per 1024x1024 png) so it can be viewed. File is saved either way. Default false.
output_formatNoAlso the file extension. Default png.
output_compressionNojpeg/webp quality like JPEG: lower = smaller file, more artifacts. Default 100.

Output Schema

ParametersJSON Schema
NameRequiredDescription
sizeYes
filesYes
modelYes
usageNo

TDQS

A3.6/5.0
Behavior4/5

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

The annotations already indicate this is a non-read-only, non-idempotent operation. The description adds useful behavioral detail by disclosing that files are saved to disk and that paths and token usage are returned. It does not cover overwrite behavior or authentication requirements, but it goes beyond the annotations without contradiction.

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 two short sentences with no filler. The core purpose is front-loaded, and the side-effect and return information are stated compactly.

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?

For a complex 14-parameter tool, the description gives the essential context: generation from a prompt, file saving, and return values. With a full input schema and an output schema present, the description is mostly sufficient, though it could add high-level guidance on model/quality tradeoffs or when editing is the better choice.

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 100%, so the input schema already fully documents all 14 parameters. The description adds no parameter-specific semantics beyond the model name, which makes the baseline 3 appropriate.

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 starts with a specific action, 'Generate images from a text prompt with OpenAI GPT Image 2.5', which clearly names the verb and resource. It also states the tool saves files and returns paths and token usage, but it does not explicitly name or differentiate against the sibling edit_image tool.

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

Usage Guidelines2/5

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

The description provides no explicit guidance on when to use this tool versus alternatives such as edit_image. It implies a text-to-image generation context, but does not state when not to use it, mention the editing sibling, or give selection criteria.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.0
    • First observededit_image
    • First observedgenerate_image

TDQS

A4.1/5.0

Scored across 2 tools

Disambiguation5/5

generate_image and edit_image are clearly separated by input and intent: one creates a new image from a prompt, the other modifies or combines existing reference images. There is no meaningful scenario where an agent would confuse which tool to call.

Naming Consistency5/5

Both tool names use the same underscore-separated verb_noun pattern. The naming is consistent and immediately communicates the action and object.

Tool Count4/5

The server exposes only two tools, which is slightly lean relative to the typical 3-15 tool range. However, the count matches the narrow image-generation/editing scope and omits unnecessary extras.

Completeness5/5

The two tools cover the core lifecycle of the domain: creating an image and editing existing images. Outputs are saved and paths returned, so an agent can continue working with the results.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers