imagen-mcp
This MCP server lets you generate and edit images with OpenAI GPT Image 2.5 models (flare/sunburst) and save them locally.
generate_image: Create images from text prompts with controls for size, aspect ratio, quality, background, output format/compression, number of variations (1-10), moderation level, custom output directory/file name, and optional inline image return.edit_image: Edit, restyle, or combine 1-16 reference images (png/jpeg/webp) using a prompt and optional alpha mask for guided inpainting; supports the same generation controls.Choose between
flare(fast, general purpose) andsunburst(slower, higher precision) models, with the default configurable viaIMAGEN_DEFAULT_MODEL.Set dimensions with preset sizes, custom
WIDTHxHEIGHT, aspect ratios (e.g. 16:9, 21:9), andlong_edge.Control cost and output quality via
quality(low to max, or auto), output compression for jpeg/webp, and transparent backgrounds for png/webp.Results report saved file paths, model, size, and detailed token usage.
Save files to the default
IMAGEN_OUTPUT_DIR/./outputor a per-calloutput_dir, with auto-generated or custom file names.
Provides image generation and editing through OpenAI's GPT Image 2.5 models, supporting customizable sizes, aspect ratios, quality tiers, background transparency, inpainting masks, and multiple output formats.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@imagen-mcpGenerate a 3:2 image of a fluffy corgi puppy on a beach, photorealistic"
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.
imagen-mcp
Minimal MCP server for OpenAI GPT Image 2.5. Two tools, two models.
Alias | API model | Use |
|
| Fast, general purpose |
|
| Slower, higher precision |
Setup
Install from npm:
npm install -g @falldownthesystem/imagen-mcpOr build from source:
npm install
npm run buildSet 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:flareorsunburst(defaultflare).
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-mcpTools
generate_image
Text to image. Required: prompt.
Option | Values | Default | Notes |
|
|
| OpenAI content filter strictness. |
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 |
| 1 to 16 file paths | required |
|
| 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 |
| text, up to 32000 chars | required | |
|
|
|
|
|
|
| Custom sizes: multiples of 16, ratio 1:3 to 3:1, long edge up to 3840. Overrides |
|
| none | Combined with |
| 256 to 3840 | 1536 | Only used with |
|
|
| Higher tiers add detail and cost more output tokens. |
|
|
|
|
|
|
| Also sets the file extension. |
| 0 to 100 | 100 |
|
| 1 to 10 | 1 | Number of separate variations generated from the same prompt in one call. Each costs its own output tokens. |
| directory path |
| Relative to the server working directory. |
| base name without extension | timestamp plus a slug of the prompt | With |
| boolean |
| 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 toolsedit_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.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | Number of variations to generate; each costs output tokens. Files get -1, -2 suffixes. Default 1. | |
| mask | No | Path of a PNG with alpha, same size as first image. Transparent pixels = region to repaint (guidance, not a hard lock). Default none. | |
| size | No | auto | 1024x1024 | 1536x1024 | 1024x1536 | WIDTHxHEIGHT (multiples of 16, ratio 1:3..3:1, max edge 3840). Overrides aspect_ratio. Default auto. | |
| model | No | flare = fast, general purpose. sunburst = slower, higher precision. Same price. Default flare. | |
| images | Yes | Paths of 1-16 reference images (png/jpeg/webp). First = main subject; others = elements to combine. Relative to server cwd. | |
| prompt | Yes | Image description, or the change to make when editing. | |
| quality | No | Higher = more detail, more output tokens. auto lets the model choose (may be costly). Default auto. | |
| file_name | No | Base name without extension. Default timestamp + prompt slug. | |
| long_edge | No | Longer side in px, used with aspect_ratio. Default 1536. | |
| background | No | transparent needs png or webp. Default auto. | |
| output_dir | No | Save directory. Default IMAGEN_OUTPUT_DIR env or ./output (relative to server cwd). | |
| aspect_ratio | No | Computes size together with long_edge. Default none. | |
| return_image | No | Also return the image inline (base64, ~1.4 MB per 1024x1024 png) so it can be viewed. File is saved either way. Default false. | |
| output_format | No | Also the file extension. Default png. | |
| input_fidelity | No | high keeps faces, text, logos and unmasked areas faithful; costs more input tokens. Default low. | |
| output_compression | No | jpeg/webp quality like JPEG: lower = smaller file, more artifacts. Default 100. |
Output Schema
| Name | Required | Description |
|---|---|---|
| size | Yes | |
| files | Yes | |
| model | Yes | |
| usage | No |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | Number of variations to generate; each costs output tokens. Files get -1, -2 suffixes. Default 1. | |
| size | No | auto | 1024x1024 | 1536x1024 | 1024x1536 | WIDTHxHEIGHT (multiples of 16, ratio 1:3..3:1, max edge 3840). Overrides aspect_ratio. Default auto. | |
| model | No | flare = fast, general purpose. sunburst = slower, higher precision. Same price. Default flare. | |
| prompt | Yes | Image description, or the change to make when editing. | |
| quality | No | Higher = more detail, more output tokens. auto lets the model choose (may be costly). Default auto. | |
| file_name | No | Base name without extension. Default timestamp + prompt slug. | |
| long_edge | No | Longer side in px, used with aspect_ratio. Default 1536. | |
| background | No | transparent needs png or webp. Default auto. | |
| moderation | No | OpenAI content filter. low refuses fewer borderline prompts. Default low. | |
| output_dir | No | Save directory. Default IMAGEN_OUTPUT_DIR env or ./output (relative to server cwd). | |
| aspect_ratio | No | Computes size together with long_edge. Default none. | |
| return_image | No | Also return the image inline (base64, ~1.4 MB per 1024x1024 png) so it can be viewed. File is saved either way. Default false. | |
| output_format | No | Also the file extension. Default png. | |
| output_compression | No | jpeg/webp quality like JPEG: lower = smaller file, more artifacts. Default 100. |
Output Schema
| Name | Required | Description |
|---|---|---|
| size | Yes | |
| files | Yes | |
| model | Yes | |
| usage | No |
TDQS
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.
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.
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.
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.
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.
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.
2 tool updates
v0.1.0- First observed
edit_image - First observed
generate_image
TDQS
Scored across 2 tools
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.
Both tool names use the same underscore-separated verb_noun pattern. The naming is consistent and immediately communicates the action and object.
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.
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
Related MCP Connectors
Edit images over MCP with object removal, background removal, and guided generative edits.
Create and manage AI image and video generations through Quriov's fixed public MCP tools.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Generate images with any major model — one API key, one prepaid balance, one MCP.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides tools for generating and editing images using OpenAI's gpt-image-1 model via an MCP interface, enabling AI assistants to create and modify images based on text prompts.15Apache 2.0
- AlicenseNot gradedqualityNot gradedmaintenanceEnables AI assistants to generate and edit images through OpenAI's DALL-E models via MCP tools. Supports text-to-image generation and image-to-image editing with configurable parameters for size, quality, and style.-
- AlicenseNot gradedqualityNot gradedmaintenanceEnables image generation, editing, and blending using Gemini 2.5 Flash capabilities, plus text generation for AI-powered creative workflows through MCP tools.-
- AlicenseNot gradedqualityDmaintenanceEnables AI-powered image generation and editing using Gemini and Imagen models, supporting text-to-image, image editing, and multi-image composition through MCP tools.MIT