mcp-imagenate
Generate images from text prompts using multiple AI providers (Google Gemini: nano-banana-2 and nano-banana-pro; OpenAI: gpt-image-2; BFL FLUX: flux-2-klein, flux-2-pro, flux-2-max; Reve: reve-image). Control output resolution (1K, 2K, 4K) and aspect ratio (1:1, 2:3, 3:2, 3:4, 4:3, 9:16, 16:9, 21:9). Optionally include reference images for editing (Google, OpenAI, Reve). For Google models, choose to return images only or with descriptions, and enable model thinking (auto/none). Save generated images to a specified directory with path sandboxing via NANO_BANANA_OUTPUT_DIR. Validate input images (format/size). Prompts support up to 32,000 characters. Returns saved file paths and the model used.
Enables image generation using Google Gemini models (nano-banana-2 and nano-banana-pro) for fast or high-quality outputs.
Enables image generation using OpenAI's gpt-image-2 model.
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-imagenateGenerate a photo of a cat wearing a wizard hat"
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-imagenate
An MCP server for image generation using multiple providers: Google Gemini, OpenAI (gpt-image), BFL FLUX, and Reve — plus short video clips through Google Gemini Omni.
Providers & Models
Google Gemini (Nano Banana)
Name | Model ID | Best for |
|
| Fast, high-volume generation |
|
| Highest quality output |
Google Gemini Omni (video)
Name | Model ID | Best for |
|
| 3–10 s clips with audio, legible on-screen text |
Uses the same GEMINI_API_KEY. Exposed through a separate generate_video tool —
see Tool: generate_video.
OpenAI
Name | Model ID | Best for |
|
| Fast generation, cheap at medium and high. The default here |
|
| Precise edits, slower than Flare |
|
| Previous generation |
These are the only models here that can return a transparent background — see Transparent backgrounds.
BFL FLUX
Name | Model ID | Best for |
|
| Fast, lightweight generation |
|
| Balanced quality and speed |
|
| Maximum quality |
Reve
Name | Version | Best for |
|
| Typography and layout fidelity |
This provider calls Reve's v2/image/create endpoint. latest is the only version
alias v2 exposes, and it is what the response reports back, so there is no dated
build to pin to. Do not confuse it with the v1 endpoints, which still serve the
older reve-create@20250915 model.
Things worth knowing before sending Reve a prompt written for another provider:
resolutionis ignored — Reve has no size parameter and returns its own large output. Exact dimensions vary between requests:16:9came back as both 5408x3072 and 5376x3072, and3:4as 3456x4800.Prompts are capped at 4,000 characters, and this provider rejects longer ones before spending a request.
inputImagesbecome v2references. Reve accepts at most eight; a longer list is rejected before any of the files are read.The saved file's extension follows the format Reve actually returned (PNG, JPEG or WebP), which is detected from the bytes rather than assumed.
A generation costs 150 credits (about $0.20) and typically takes 40-80 seconds. Give any proxy or job runner in front of it a timeout of at least 120 seconds.
Related MCP server: Imagen Tools MCP Server
Requirements
Node.js 20+
At least one provider API key
Installation
npx mcp-imagenateOr install globally:
npm install -g mcp-imagenateSetup
Set API keys for the providers you want to use:
# Google Gemini (at least one)
export GEMINI_API_KEY=your_key_here
# or
export NANO_BANANA_API_KEY=your_key_here
# OpenAI (at least one)
export OPENAI_API_KEY=your_key_here
# or
export GPT_IMAGE_API_KEY=your_key_here
# BFL FLUX
export BFL_API_KEY=your_key_here
# Reve (at least one)
export REVE_API_KEY=your_key_here
# or
export REVE_API_TOKEN=your_key_hereClaude Desktop
Add to your claude_desktop_config.json:
{
"mcpServers": {
"mcp-imagenate": {
"command": "npx",
"args": ["mcp-imagenate"],
"env": {
"GEMINI_API_KEY": "your_key_here",
"NANO_BANANA_OUTPUT_DIR": "/path/to/image/output"
}
}
}
}Environment Variables
Variable | Required | Description |
| * | Google AI Studio API key |
| * | Alternative to |
| * | OpenAI API key |
| * | Alternative to |
| * | BFL FLUX API key |
| * | Reve partner API token (from the API console at api.reve.com) |
| * | Alternative to |
| No | Base directory for saved images. When set, all output and input paths are sandboxed within this directory. Recommended for production. |
* At least one provider API key must be set.
Tool: generate_image
Parameters
Parameter | Type | Default | Description |
|
| - | Text prompt describing the image |
| see Models above |
| Model to use (available models depend on configured API keys) |
|
|
| Output image resolution |
| see below |
| Aspect ratio of the image |
|
|
| Return image only, or image with description (Google models only) |
|
|
| What the image sits on. |
|
|
| Controls model thinking (Google models only) |
|
|
| Directory where images will be saved |
|
| - | File paths of images to send alongside the prompt (Google models, OpenAI gpt-image models via the images.edit endpoint, and Reve via v2 |
Supported aspect ratios
1:1, 2:3, 3:2, 3:4, 4:3, 9:16, 16:9, 21:9
Transparent backgrounds
background: "transparent" saves a PNG with an alpha channel, which is useful for
cutting out a subject to place on a slide or over another image.
Only the OpenAI gpt-image models can do this. Asking any other model
(nano-banana-*, flux-2-*, reve-image) for a transparent background fails
with an error rather than quietly returning an opaque image — the request is
rejected before it is sent, so nothing is spent on it. Writing "transparent
background" into the prompt does not help either: those providers have no
transparency mode at all.
"opaque" forces a filled background on every provider that reads the field, and
"auto" — the default — leaves the choice to the model, which is what this server
has always done.
Response
Returns a JSON object:
{
"model": "gemini-3.1-flash-image-preview",
"savedFiles": ["/path/to/image-1.png"],
"settings": {
"resolution": "1K",
"aspectRatio": "9:16",
"mode": "image",
"background": "auto"
},
"description": "..."
}
descriptionis only present whenmodeis"image_and_text".
Tool: generate_video
Available when a Google key is configured. Generates one clip with audio and saves it as an mp4.
Parameters
Parameter | Type | Default | Description |
|
| - | Subject, motion, camera, and any on-screen text spelled out exactly |
|
|
| Video model to use |
| integer |
| Clip length. Cost scales with the second, and so does generation time (roughly 1 min for 5 s, 2 min for 10 s) |
|
|
| Playback resolution. |
|
|
| Landscape or portrait |
|
|
| Directory where the clip will be saved (same sandboxing as |
|
| - | Reference images sent ahead of the prompt: a first frame to animate, or subjects and styles to keep. Refer to them as |
|
| - |
|
Things worth knowing:
A single request is capped at 10 s by the model. To go longer, pass the returned
interactionIdback aspreviousInteractionId; each extension adds up to 10 s, and the whole clip is returned each time.Text in the prompt is rendered on screen as written, including non-Latin scripts, though Google only documents English as fully supported.
Clips are fetched through Google's file endpoint rather than inlined in the JSON response, as the API documentation recommends above 4 MB. Expect one extra request per generation.
720p costs about $0.10 per second of output; there is no free tier for this model.
Response
{
"model": "gemini-omni-1.1-flash",
"savedFile": "/path/to/1788347054697-491db547.mp4",
"settings": {
"durationSeconds": 5,
"resolution": "720p",
"aspectRatio": "16:9"
},
"interactionId": "v1_...",
"description": "..."
}
descriptionis only present when the model returns text alongside the clip.
Use as a library
Besides the standalone MCP server, this package can be embedded in another host — an app, or another MCP server that wants to expose image generation as its own tool.
import { createRegistry, generateImageToDisk } from "mcp-imagenate";
// Keys are passed in explicitly; nothing here reads process.env.
const registry = createRegistry({ openai: myOpenAIKey, google: myGoogleKey });
if (registry.models.length === 0) {
throw new Error("No image provider is configured");
}
const outcome = await generateImageToDisk({
registry,
prompt: "a calico cat asleep on a warm keyboard",
model: registry.defaultModel!,
aspectRatio: "16:9",
outputDir: "/somewhere/to/write",
// outputBaseDir defaults to null, meaning no path sandboxing. Set it to a
// directory to confine both output and input paths within that directory.
});
console.log(outcome.savedFiles);generateImageToDisk takes the same options as the tool, so background: "transparent" throws for a model that cannot deliver an alpha channel. Check
registry.resolve(model).supportsTransparentBackground first if the model is not
one you chose yourself.
The library entry point never reads process.env, writes to stdio, or exits the
process. To read keys from the conventional environment variables anyway, use the
keysFromEnv() helper. The standalone server is available at mcp-imagenate/server.
Export | Purpose |
| Build a registry of the models available for the given keys |
| Read provider keys from environment variables |
| Generate images and write them to disk |
| Build a registry of the video models available for the given keys |
| Generate a clip and write it to disk |
| Path sandboxing helpers (opt-in) |
Security
Path sandboxing: When
NANO_BANANA_OUTPUT_DIRis set, both output and input image paths are sandboxed within this directory. Symlinks that resolve outside the sandbox are rejected. For library embedders this is opt-in viaoutputBaseDir, since the host usually controls which paths reach the call.Input validation: Input images are validated for format (PNG/JPEG/WEBP/GIF) and size (max 20 MB). Video durations outside the model's range are rejected before any request is sent.
API key validation: The server exits immediately if no API keys are configured. The library reports this as an empty registry instead, leaving the decision to the host.
License
MIT
Available Tools
1 toolgenerate_imageGenerate ImageA
Generate images using multiple providers (Google Gemini, OpenAI, BFL FLUX, Reve). Images are saved to disk and the file paths are returned.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Response mode. image returns only the image; image_and_text also returns a description (Google models only) | image |
| model | No | Model to use. Available models depend on configured API keys | gpt-image-2 |
| prompt | Yes | Text prompt describing the image to generate | |
| thinking | No | Controls model thinking before generation (Google models only). none disables thinking; auto lets the model decide | auto |
| outputDir | No | Directory path where generated images will be saved. If NANO_BANANA_OUTPUT_DIR is set, relative paths are resolved from that base and all paths are sandboxed within it. | . |
| resolution | No | Output image resolution. Higher values may not be supported by all models | 1K |
| aspectRatio | No | Aspect ratio of the generated image | 1:1 |
| inputImages | No | File paths of images to include as input alongside the prompt (supports PNG, JPEG, WEBP, GIF). Supported by Google models, OpenAI gpt-image models (uses the images.edit endpoint) and Reve (sent as v2 references). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure. It covers core behaviors (multiple providers, save to disk, return paths) and notes that mode/thinking apply only to Google models. However, it omits details like file naming, overwrite behavior, and error handling, which are important for a tool that saves files.
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, front-loaded with the main purpose, and contains no unnecessary words. Every sentence provides essential information about what the tool does and its result.
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 8 parameters and no output schema, the description covers the main purpose but lacks details on output specifics (file format, naming, directory behavior beyond parameter description). The schema fills gaps but the description alone is not fully complete for end-to-end understanding.
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 coverage is 100% with detailed descriptions for all 8 parameters. The tool description adds minimal value for parameters, only reiterating the multi-provider aspect. Baseline is 3, and no further improvement is justified.
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 generates images using multiple named providers, saves to disk, and returns file paths. The verb 'generate' and resource 'image' are specific, and the inclusion of provider names adds context. No sibling tools exist, so differentiation is not 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 lacks guidance on when to use this tool versus alternatives. No sibling tools or explicit usage contexts are provided. The description only states what the tool does, not when it should be preferred or avoided.
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
v0.3.1- First observed
generate_image
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion between tools. The single 'generate_image' tool has a clear and distinct purpose.
The tool name follows a clear verb_noun pattern ('generate_image'), which is consistent and descriptive.
Having only one tool feels too few for a general image generation server, even if it supports multiple providers. Users may expect additional capabilities like model listing or image management.
The tool covers the core functionality of generating images from multiple providers and saving them, which is the stated purpose. Minor gaps like model selection or deletion are not critical for basic use.
Maintenance
Related MCP Connectors
MCP server for Flux AI image generation
MCP server for Qwen Image 3 AI image generation
MCP server for Midjourney AI image generation and editing
MCP server for Google Veo AI video generation
Related MCP Servers
- AlicenseAqualityDmaintenanceMCP server for Google Gemini image generation with configurable model support, enabling text-to-image generation, image editing, and iterative refinement.640MIT
- AlicenseNot gradedqualityBmaintenanceAn MCP server for generating and editing images using Google Gemini Imagen via Vertex AI. Supports multiple resolutions and aspect ratios.MIT
- FlicenseAqualityDmaintenanceMCP server for AI image generation supporting text-to-image and image-to-image editing via any OpenAI-compatible service, with configurable models, aspect ratios, and sizes.2-
- AlicenseNot gradedqualityDmaintenanceAn MCP server that provides AI image generation using Google Gemini models with intelligent model selection, aspect ratio control, and support for high-quality outputs up to 4K.MIT