mcp-image-gen
Integrates with the OpenAI Images API to generate images from text prompts and create reference-guided image edits, with configurable image model, format/size, quality, and variants.
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., "@mcp-image-gengenerate a landscape image of a futuristic city at sunset"
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.
mcp-image-gen
This is a small Node.js MCP server that gives an AI coding agent (Claude Code or any MCP client) one tool, generate_image.
I generate a lot of images from Claude Code sessions, and I run ComfyUI with Qwen-Image 2.1 on my own GPU. Cloud image quotas run out, and when the one I relied on did, my image work stopped. So this server tries the OpenAI Images API first (when it's configured) and falls back automatically to Qwen-Image 2.1 on a local ComfyUI server when the cloud is rate-limited or unavailable.
No npm dependencies, just Node.js built-ins (fetch, FormData, node:test).

Sample output of the local route, requested over MCP stdio with the prompt "a small red fox sitting in a snowy forest, soft morning light" (Qwen-Image 2.1 on ComfyUI, 1024x1024, 35 s).
How it works
flowchart LR
C["MCP client (e.g. Claude Code)"] <-->|"stdio, JSON-RPC 2.0"| S["server.mjs"]
S --> V["validate input"]
V --> G{"backend"}
G -->|"auto / openai"| O["OpenAI Images API<br/>/images/generations, /images/edits"]
O -->|"429: pause cloud 15 min<br/>network, 401/403/404, 5xx"| Q
O -->|"400 refusal: error, no fallback"| E["tool error"]
G -->|"comfyui, or cloud skipped"| Q["ComfyUI: Qwen-Image 2.1<br/>/upload/image, /prompt, /history, /view"]
O --> F["PNG files + file:/// links"]
Q --> FRelated MCP server: 2Xapi.com GPT-image MCP Server
Quickstart
You need Node.js 20.11+. The local backend also needs a ComfyUI server with the Qwen-Image 2.1 nodes (TextEncodeQwenImage21, QwenImage21Cache) and the model files; the cloud backend needs an OpenAI API key.
git clone <this repo> && cd mcp-image-gen
npm test
# register with Claude Code (the key is read from your environment, not stored in the MCP config)
export OPENAI_API_KEY=... # optional
claude mcp add image-gen -e COMFYUI_URL=http://127.0.0.1:8188 -- node /path/to/mcp-image-gen/src/server.mjsEverything is configured through environment variables (see .env.example). These are the main ones:
Variable | Default | Meaning |
| (none) | Turns on the cloud backend. Without it, |
|
| The model sent to the Images API. OpenAI's guide now lists newer GPT Image models, so set this to a current one. |
|
| The ComfyUI server. |
| the Qwen-Image 2.1 file names | Model files in your ComfyUI install. |
|
| Where images go when the call doesn't name a path. |
The tool
generate_image { prompt, output?, references?, format?, quality?, variants?, backend? }
references: up to 10 image paths (PNG/JPEG/WebP, max 20 MB each) to keep a character, place or style. OpenAI gets them asimage[]parts of/images/edits; ComfyUI gets them as uploads wired into the Qwen-Image 2.1 encoder.format:portrait(default; 1024x1536 on OpenAI, 768x1376 on ComfyUI),square,landscape.backend:auto(default),openaiorcomfyui.The result names the backend, the real pixel size read from the PNG header, the time, and the saved paths with a
file:///link for each, plus a note when it fell back.
Tests and CI
npm test # node --test: 23 tests, offlineThe tests start local fake servers (a fake OpenAI and a fake ComfyUI, built on node:http), and every HTTP call goes to them, so there are no real API calls. test/server.test.mjs runs the real server process over stdio, end to end. .github/workflows/ci.yml runs the suite on Ubuntu and Windows with Node 20 and 22.
Security
These are the security rules I set for the server:
Transport is stdio only. The server opens no network port, talks only to the MCP client that started it, and makes outbound requests only to the configured OpenAI and ComfyUI URLs.
Inputs are validated before any request goes out: the prompt is required and at most 4,000 characters;
format,qualityandbackendare enums;variantsis an integer from 1 to 4; there are at most 10 references, each an existing regular file with an image extension and at most 20 MB;outputmust be a non-empty path without NUL bytes. The schema rejects unknown arguments (additionalProperties: false).No secrets are logged, because nothing is logged: stdout carries only protocol messages. The API key is read from the environment, sent only in the
Authorizationheader, and redacted from any upstream error text before it reaches the client (some APIs echo the key back in auth errors; a test checks the redaction).Refusals are never routed around silently. A cloud refusal (HTTP 400, e.g. a content policy rejection) comes back as an error. It isn't retried on the local model unless the caller explicitly asks for
backend: "comfyui".The server writes images wherever the client asks (
output). It trusts its MCP client, like any local tool with file access.
Design decisions
Classify cloud errors, then decide.
rate-limited(429, quota) -> fall back and skip the cloud for 15 minutes, so the next calls don't wait on a known failure;unavailable(network, 401/403/404, 5xx) -> fall back for this call;refused-> error.The local workflow is built in code.
buildWorkflowgenerates the ComfyUI graph (API format). That way references are padded to the encoder's three inputs (repeating the last one), extra references get their own nodes, and an explicitEmptyLatentImagefixes the canvas size (without it, the canvas follows the first reference). One job per variant, with consecutive seeds.Real size in the result. The reported size is read from the saved PNG header, not from the request.
The tool stays visible.
_meta["anthropic/alwaysLoad"]keeps it in the model's base tool list, so the model calls it instead of answering "I created the image" without calling anything.Zero dependencies, so the server starts instantly and has no supply-chain surface beyond Node.js.
Limitations
I haven't verified the OpenAI request/response shape against the live API in this version (see below), and the default model name may need changing for your account.
The ComfyUI backend needs the Qwen-Image 2.1 nodes and models; other models need another workflow. It polls
/historyevery 2 seconds instead of using the WebSocket API.No streaming or partial images, and no cancellation of a running ComfyUI job when the client disconnects.
Variants on ComfyUI run one after another.
How I built it
I built this with AI coding agents (Claude Code), which wrote most of the code. My part was the architecture (the backend order, the error classes and when to fall back, the security rules), the review gates and the verification.
I don't take an agent's "done" at face value, so this is what I checked, and how:
This repository:
npm testruns 23 offline tests and they pass (fake OpenAI and ComfyUI servers; the stdio server is tested as a real child process). I also checked each critical rule by injecting a deliberate bug and confirming that a test fails: no fallback on refusal, key redaction, the rate-limit pause, reference padding, consecutive seeds, and the 401 classification.The private predecessor of this server is the version I use every day (same tool, same fallback rules, a different cloud route). I verified it with a stdio test client, no model involved: real cloud text-to-image and reference-guided generations, a real local Qwen-Image 2.1 generation (21 s), and a fake cloud endpoint answering 429, after which the server switched to Qwen and the next request skipped the cloud. Then a real Claude Code session found the tool on its own and returned the
file:///link. That's also how I found out thealwaysLoadflag was necessary. The ComfyUI workflow graph (nodes, parameters, theEmptyLatentImagecanvas fix, padding references to three) comes from my production setup.Local route, verified on a real server (29.10.2026): I started this server as a stdio child process with no OpenAI key, and it answered
initialize,tools/listand agenerate_imagecall. Withauto, it fell back to ComfyUI with the note "OpenAI not configured", and Qwen-Image 2.1 returned a 1024x1024 PNG in 35 s (the sample above).Cloud route, not run yet: in this repo the predecessor's cloud route is replaced by the official OpenAI Images API, which has never been called with a real OpenAI account. Only the mocked tests cover it. I checked the request shape against OpenAI's image-generation guide on 29.10.2026 (repeated
image[]parts, the three sizes,data[].b64_json). My assumptions about the OpenAI API:POST /v1/images/generations(JSON) andPOST /v1/images/edits(multipart, repeatedimage[]parts), fieldsmodel,prompt,n,size(1024x1536,1024x1024,1536x1024), optionalquality(low/medium/high), responsedata[].b64_json, errors as{ error: { message, code } }, default modelgpt-image-1.CI: GitHub Actions runs
npm teston Ubuntu and Windows with Node 20 and 22. The first run passed on 29.10.2026.
License
MIT, see LICENSE.
Available Tools
1 toolgenerate_imageA
Generates a PNG image and saves it to disk. Tries the OpenAI Images API first (when OPENAI_API_KEY is set); when it is rate-limited or unavailable, falls back automatically to Qwen-Image 2.1 on the local ComfyUI server. Returns the file paths and the backend used.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | portrait (default): 1024x1536 on OpenAI, 768x1376 on ComfyUI. square: 1:1. landscape: the portrait sizes rotated. | |
| output | No | Folder or .png file to save to. Default: the image folder, in a subfolder per day. | |
| prompt | Yes | What the image must contain. English works best. | |
| backend | No | auto (default): OpenAI, then ComfyUI when OpenAI is rate-limited or unavailable. openai / comfyui: only that backend. | |
| quality | No | OpenAI only. Default: the model default. | |
| variants | No | How many variants (default 1). | |
| references | No | Paths to reference images (character, place, style); with them the image is made by editing. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses backend fallback ordering, the OPENAI_API_KEY prerequisite, rate-limit/unavailability triggers, and that results are written to disk. It doesn't cover what happens when both backends fail, or any cost/latency tradeoffs.
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?
Three dense sentences, front-loaded with the action and output, followed by routing behavior and return shape. No filler; each sentence adds 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?
For a multi-backend generation tool with no output schema, the description usefully states the return value ('file paths and the backend used') and the fallback behavior. The only gap is failure behavior when both backends are unavailable.
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 all seven parameters including enums and limits are already documented. The description only echoes the backend fallback already stated in the 'backend' field and adds no new parameter-level meaning.
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?
States a specific verb and resource ('Generates a PNG image and saves it to disk') plus the multi-backend routing, so an agent knows exactly what the call produces. No sibling tools exist, so no differentiation is needed.
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 explains the default backend-selection logic (OpenAI first, ComfyUI on rate-limit/unavailability), which is useful context, but it never says when to call this tool versus not calling it, nor when an agent should override the 'auto' default.
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 tool update
v1.0.0- First observed
generate_image
TDQS
Scored across 1 tool
With a single tool there is no possibility of misselection or overlap. An agent's only choice is whether to call it at all, and the description makes the trigger conditions (generate a PNG from a prompt, with automatic backend fallback) unambiguous.
The single name follows a clean verb_noun snake_case convention (generate_image) that would scale predictably if more tools were added. No style mixing is possible with one tool.
One tool is thin even for a narrowly scoped server; the rubric treats 1-2 tools as borderline. It earns its place, but the surface feels underbuilt for a server whose apparent remit is image generation and management.
Generation is well covered, including a fallback backend, but there is no way to list, inspect, delete, or re-run previously generated images, and no way to check backend/API status. These are notable gaps an agent would hit when managing outputs, though core generation works.
Maintenance
Related MCP Connectors
Generate images from Claude, ChatGPT, Cursor and Codex with 12 top AI image models. Up to 4 images per call, SVG vectorization, background removal, upscaling and image-to-video. Remote MCP with OAuth, no API keys.
Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.
Generate images from Claude, ChatGPT, Cursor and Codex with 12 top AI image models and 10 tools: up to 4 images per call, SVG vectorization, editing and more. Remote MCP with OAuth, no API keys. Pay per image, no subscription.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Related MCP Servers
- AlicenseAqualityCmaintenanceExposes OpenAI's gpt-image-2 and gpt-image-1.5 to Claude Code as a single tool for generating, editing, or composing images with automatic model selection.138 PyPI2MIT
- AlicenseAqualityAmaintenanceWraps OpenAI-compatible text-to-image APIs as MCP tools, enabling image generation directly from conversations in Claude Code, Codex, Cursor, or Claude Desktop using the user's own API key.61Apache 2.0
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to generate images and videos through natural language by exposing ComfyUI workflows as parameter-configurable MCP tools.10MIT
- AlicenseNot gradedqualityCmaintenanceEnables MCP clients to generate and edit images through any OpenAI-compatible image API, saving results as local files and returning absolute paths for immediate use.18 npmMIT