Provides image generation and editing through OpenAI's GPT Image models, including text-to-image generation, image editing/inpainting, multi-image composition, and model listing with automatic model fallback.
Click on "Install 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., "@image-generator-mcp generate a photorealistic product shot of a ceramic mug on a wooden table"
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.
An MCP server that lets Claude generate and edit images with OpenAI's GPT Image models, plus a Claude skill that teaches Claude when and how to use it — which model to pick, how to prompt these models, and where to put the files.
Works with Claude Code, and with any other MCP client that speaks stdio.
Tool | Does |
| Text prompt → one or more images, saved to disk, previewed inline |
| Whole-image edits, inpainting with a mask, multi-image composition |
| Which image models your API key can actually use, and what each is good for |
Claude picks the model itself. Left on auto, the server tries
gpt-image-2 and walks down gpt-image-1.5 → gpt-image-1 → gpt-image-1-mini if
your key lacks access, reporting which ones it skipped. Any model id is accepted
and passed straight through, so models released after this was written keep
working without a code change.
Related MCP server: Gemini Nanobanana MCP
Node.js ≥ 20 (uses built-in fetch, FormData and File)
An OpenAI API key with access to the image models
macOS gets downscaled inline previews via the built-in sips; other platforms
still save every file correctly (see Previews)
git clone https://github.com/ChristophLabestin/image-generator-mcp.git
cd image-generator-mcp
npm installThe server reads the key from a private file, so it never has to be written into an MCP client config that might get synced or shared:
mkdir -p ~/.config/image-generator-mcp
printf 'OPENAI_API_KEY=sk-YOUR-KEY-HERE\n' > ~/.config/image-generator-mcp/.env
chmod 600 ~/.config/image-generator-mcp/.envA plain OPENAI_API_KEY in the environment also works and takes precedence.
Restricted-key permissions. If you scope the key rather than granting full
access, it needs exactly two: Images → Write (generation and edits) and
Models → Read (for list_image_models). Everything else can stay None.
Without Models → Read the image tools still work; only the live model listing
fails.
From inside the cloned directory, so $PWD resolves to it:
claude mcp add image-generator --scope user -- node "$PWD/src/index.js"--scope user makes it available in every project. Use --scope project
instead to limit it to one repo.
Verify:
claude mcp listThen restart Claude Code — a server registered mid-session is not loaded into that session.
Any stdio MCP client works. The equivalent JSON config entry:
{
"mcpServers": {
"image-generator": {
"command": "node",
"args": ["/absolute/path/to/image-generator-mcp/src/index.js"]
}
}
}The MCP server alone lets Claude generate images. The skill is what makes it choose well — model selection, prompt craft, the cheap-draft-then-final workflow, and saving into the project's own asset folder. Install it at user scope so it applies across all projects:
mkdir -p ~/.claude/skills
cp -r skills/image-generation ~/.claude/skills/Claude loads it automatically when a request involves images; you do not invoke it by hand.
npm run smokeThis speaks the MCP handshake to the server and prints the advertised tools. With the key in place it also lists the models your key can reach. It makes no image-generation calls, so it costs nothing.
Just ask in plain language — "make me an icon for X with a transparent background", "change the background in this photo to a beach". Claude selects the tool, the model and the parameters.
Resolution order, first match wins:
output_dir passed on the individual tool call — absolute, or relative to
the server's working directory
The IMAGE_OUTPUT_DIR environment variable
~/Pictures/claude-images
The skill instructs Claude to use option 1 with the project's own asset
directory for anything project-related, so generated images land in the repo
rather than in your Pictures folder. IMAGE_OUTPUT_DIR is the right lever only
if you want a different global default.
Env var | Effect |
| Required. Falls back to |
| Default save directory. Defaults to |
| Point at a proxy or compatible endpoint. Defaults to |
Situation | Model |
Final artwork, text inside the image, 2K/4K, inpainting |
|
Many images, quality still matters, no 4K needed |
|
Cheap drafts, thumbnails, composition roughs |
|
Explicitly asked for DALL·E 3 |
|
Generation is billed per image and quality: "high" costs several times
"low", so the skill has Claude draft cheap, confirm the composition with you,
and only then render the final.
Checked end to end against the live API rather than read off the docs:
Generation, the multipart edit upload, and the error path all behave.
background: "transparent" produces a genuine RGBA alpha channel (corner
pixels at alpha 0) on gpt-image-2, gpt-image-1.5, gpt-image-1 and
gpt-image-1-mini — verified by decoding the PNG alpha channel pixel by
pixel. Drafting transparent assets on the cheap model is therefore a valid
workflow. dall-e-3 has no transparency.
Every image is written to disk. What Claude gets back inline is a downscaled
JPEG (768px max edge) so a 4K render does not flood the context window. That
resize uses macOS sips; on other platforms the original is inlined when it is
small enough and skipped when it is not. The saved file is always the full
original either way — only the preview is affected.
dall-e-3 speaks a different parameter vocabulary (quality: standard|hd,
style, n forced to 1). The server translates automatically.
OpenAI errors come back verbatim with status code and parameter name, so Claude can correct its own call instead of guessing.
No API key is ever stored in the repository or in your MCP client config.
src/index.js MCP server: tool definitions, model fallback, result delivery
src/openai.js OpenAI /v1/images client (generations, edits, models)
src/models.js Curated model catalog + fallback chain
src/output.js Filename building, saving, preview downscaling
src/config.js API key file loading
scripts/smoke.js MCP handshake test
skills/image-generation/SKILL.md The Claude skillMIT — see LICENSE.
Edit existing image(s) with a text instruction. Covers three jobs:
Whole-image edit - pass one image and describe the change.
Inpainting - pass a mask PNG whose transparent areas mark what to replace; everything else is preserved.
Composition / style reference - pass several images and describe how to combine them (e.g. put the product from image 1 into the scene from image 2).
Input images must be png, jpg or webp. dall-e-3 cannot edit; use a gpt-image model.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | ||
| mask | No | Absolute path to a PNG mask with an alpha channel. Transparent pixels are the region the model may repaint; opaque pixels are kept. Must match the first input image's dimensions. | |
| size | No | Output dimensions as "WIDTHxHEIGHT", or "auto". | |
| model | No | Image model id. Omit or pass "auto" to use the best available model (tries gpt-image-2, then falls back if this API key lacks access). Pass an explicit id to control cost/quality: gpt-image-2, gpt-image-1.5, gpt-image-1, gpt-image-1-mini, dall-e-3. Any newer model id is also accepted and passed through unchanged. | |
| images | Yes | Absolute paths to the input image(s). With more than one, they are treated as references to combine. | |
| prompt | Yes | The edit instruction, or a description of the desired final image. | |
| quality | No | Render quality. | |
| filename | No | Base filename without extension. Defaults to a timestamp plus a slug of the prompt. With n > 1 an index is appended. | |
| background | No | ||
| output_dir | No | Directory to write the images into. Pass an absolute path (e.g. the current project's assets folder) when the images belong to a project. Defaults to /root/Pictures/claude-images. | |
| output_format | No | ||
| input_fidelity | No | Use "high" to preserve faces, logos and fine detail from the input. Not configurable on gpt-image-2, which is always high fidelity. | |
| return_preview | No | Return a downscaled copy of each image inline so you can actually look at the result and iterate. Set false to save tokens when the image is not going to be reviewed. | |
| output_compression | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It usefully explains mask transparency semantics (transparent areas are repainted, opaque areas preserved), accepted input formats, and a model limitation. It does not explicitly state that original files are left untouched or describe the exact output flow, but the schema's output_dir and return_preview parameters partially cover that.
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 compact and well-structured: a one-sentence summary followed by numbered modes that map directly to input patterns. There is no filler, and the most decision-relevant information is front-loaded.
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 14-parameter tool with no annotations and no output schema, the description covers the main decision axes: mode selection, image formats, mask usage, and model constraints. Its main gaps are not explicitly routing to generate_image for new images and not describing the output/return behavior, but the rich parameter descriptions fill most of the remaining context.
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 71%, so the baseline is 3, but the description adds meaningful context for the core parameters: prompt+one image means whole edit, prompt+mask means inpainting, and prompt+multiple images means composition. It also adds the file-format restriction and the dall-e-3 constraint, which go beyond the schema.
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 clearly states the tool edits existing image(s) with a text instruction, and enumerates three distinct jobs: whole-image edit, inpainting, and composition/style reference. This differentiates it from sibling tools like generate_image (creating new images) and list_image_models (listing models).
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 gives concrete when-to-use guidance by mapping each of the three modes to a specific input pattern: one image, image+mask, or multiple images. It also warns that dall-e-3 cannot edit and directs agents to a gpt-image model, but it does not explicitly contrast with generate_image for the from-scratch case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate one or more images from a text prompt using OpenAI's GPT Image models, save them to disk, and return the file paths plus an inline preview.
Prompt style: these models follow long, specific prose well. Describe subject, composition, lighting, medium/style, colour palette and mood. Any text that should appear inside the image must be given verbatim in quotes.
Cost control: use quality "low" (or gpt-image-1-mini) while iterating on composition, then re-render the winner at quality "high".
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | How many variations to generate. dall-e-3 supports only 1. | |
| size | No | Image dimensions as "WIDTHxHEIGHT", or "auto". Common: 1024x1024 (square), 1536x1024 (landscape), 1024x1536 (portrait). gpt-image-2 also accepts larger sizes such as 2048x2048 and 3840x2160 (edges must be multiples of 16, aspect ratio under 3:1). | |
| model | No | Image model id. Omit or pass "auto" to use the best available model (tries gpt-image-2, then falls back if this API key lacks access). Pass an explicit id to control cost/quality: gpt-image-2, gpt-image-1.5, gpt-image-1, gpt-image-1-mini, dall-e-3. Any newer model id is also accepted and passed through unchanged. | |
| style | No | dall-e-3 only. Ignored by gpt-image models. | |
| prompt | Yes | What to draw. Be specific and descriptive; long prompts work well. | |
| quality | No | Render quality. "low" is fast and cheap for drafts, "high" is for final output. Defaults to the model default ("auto"). | |
| filename | No | Base filename without extension. Defaults to a timestamp plus a slug of the prompt. With n > 1 an index is appended. | |
| background | No | Use "transparent" for logos, icons, stickers and cut-outs. Requires output_format png or webp. Not supported by dall-e-3. | |
| moderation | No | Content-filter strictness for gpt-image models. Defaults to "auto". | |
| output_dir | No | Directory to write the images into. Pass an absolute path (e.g. the current project's assets folder) when the images belong to a project. Defaults to /root/Pictures/claude-images. | |
| output_format | No | File format. png (default) for graphics/transparency, jpeg/webp for photos. | |
| return_preview | No | Return a downscaled copy of each image inline so you can actually look at the result and iterate. Set false to save tokens when the image is not going to be reviewed. | |
| output_compression | No | Compression level 0-100 for jpeg/webp output. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the burden of disclosing side effects and behavior. It clearly states that images are saved to disk and that the tool returns file paths plus an inline preview. It also reveals model behavior around prompt-following quality. It does not disclose potential rate limits or authentication needs, but the core effects are transparent.
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 tight paragraphs with no filler. The first sentence front-loads the tool's core purpose and side effects, while the subsequent paragraphs add targeted, non-redundant guidance on prompt style and cost control. Every sentence contributes actionable information.
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?
Given the tool's complexity (13 parameters, no output schema), the description covers the essential operational flow: generate, save, preview, and iterate. It also states return values, which matters because there is no output schema. It does not mention defaults like the output directory or naming convention, but these are well documented in the schema, so the description is sufficiently complete for correct tool selection and 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 has 100% coverage for all 13 parameters, so the baseline is 3. The description adds real value beyond the schema by teaching prompt-authoring strategy (subject, composition, lighting, palette, mood, quoted text) and by mapping quality choices to iteration phases. This moves it well above 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 opens with a concrete, multi-part action: generate one or more images from a text prompt, save them to disk, and return file paths plus an inline preview. It names the model family (OpenAI GPT Image models) and clearly distinguishes the behavior from sibling tools like edit_image and list_image_models.
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?
It provides clear practical guidance on how to use the tool effectively: write long, specific prose describing subject, composition, lighting, and mood, and quote in-image text verbatim. It also gives a cost-control workflow (use low quality while iterating, high quality for the final render). It does not explicitly say 'use this instead of edit_image,' but the generation-focused context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the image models this API key can use, with guidance on which to pick. Call this when you are unsure whether a model is available, when a generation failed with a model error, or when the user asks what is possible.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of indicating behavior. 'Show' implies a read-only operation, and 'this API key can use' communicates API-key-scoped results. It does not explicitly state that no generation or editing side effects occur, but that is clear from context.
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 sentences long, front-loads the core purpose, and packs in both the output scope and the relevant invocation conditions. Every sentence earns its place with no repetition or fluff.
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 zero-parameter listing tool with no annotations and no output schema, the description is complete. It tells the agent what will be shown, the scope of the results, and when to invoke it, which is sufficient for correct use.
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 tool has zero parameters, so there is no parameter documentation gap. The description does not need to add parameter-level meaning, and the baseline of 4 applies.
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 specifies a clear verb and resource: 'Show the image models this API key can use.' It also states the tool provides guidance on selection, which makes its purpose distinct from the sibling tools generate_image and edit_image.
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 explicitly lists when to call the tool: when unsure a model is available, after a generation model error, or when the user asks what is possible. This gives an agent concrete decision criteria without needing to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0edit_imagegenerate_imagelist_image_modelsThe three tools have clearly separated concerns: generate_image creates new images, edit_image modifies existing ones, and list_image_models provides model metadata. There is no overlap in purpose or expected inputs.
All tool names follow a consistent verb_noun snake_case pattern: generate_image, edit_image, list_image_models. The slight pluralization in list_image_models is natural and does not create inconsistency.
Three tools is a tight, well-scoped set for an image generation server. Each tool addresses a distinct workflow step without redundancy.
The server covers the core workflow fully: generating images, editing them via text, mask, or reference, and checking available models. No critical gaps exist for the stated domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate and edit images and create short videos inside Claude. Prepaid credits, no subscription.
Generate images with your own ChatGPT subscription (Plus, Pro or Team), without spending API credits
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Generate AI images, videos, music, SFX & speech in any AI assistant. Results appear inline in chat.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ChristophLabestin/image-generator-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
