Skip to main content
Glama

mcp-imagenate

An MCP server for image generation using multiple providers: Google Gemini, OpenAI (gpt-image), BFL FLUX, and Reve.

Providers & Models

Google Gemini (Nano Banana)

Name

Model ID

Best for

nano-banana-2

gemini-3.1-flash-image-preview

Fast, high-volume generation

nano-banana-pro

gemini-3-pro-image-preview

Highest quality output

OpenAI

Name

Model ID

Best for

gpt-image-2

gpt-image-2

Latest generation, improved detail

BFL FLUX

Name

Model ID

Best for

flux-2-klein

klein-4b

Fast, lightweight generation

flux-2-pro

pro-preview

Balanced quality and speed

flux-2-max

max

Maximum quality

Reve

Name

Version

Best for

reve-image

latest

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:

  • resolution is ignored — Reve has no size parameter and returns its own large output. Exact dimensions vary between requests: 16:9 came back as both 5408x3072 and 5376x3072, and 3:4 as 3456x4800.

  • Prompts are capped at 4,000 characters, and this provider rejects longer ones before spending a request.

  • inputImages become v2 references. 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-imagenate

Or install globally:

npm install -g mcp-imagenate

Setup

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_here

Claude 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

GEMINI_API_KEY

*

Google AI Studio API key

NANO_BANANA_API_KEY

*

Alternative to GEMINI_API_KEY (takes precedence)

OPENAI_API_KEY

*

OpenAI API key

GPT_IMAGE_API_KEY

*

Alternative to OPENAI_API_KEY (takes precedence)

BFL_API_KEY

*

BFL FLUX API key

REVE_API_KEY

*

Reve partner API token (from the API console at api.reve.com)

REVE_API_TOKEN

*

Alternative to REVE_API_KEY (REVE_API_KEY takes precedence)

NANO_BANANA_OUTPUT_DIR

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

prompt

string (1-32,000 chars)

-

Text prompt describing the image

model

see Models above

"gpt-image-2"

Model to use (available models depend on configured API keys)

resolution

"1K" | "2K" | "4K"

"1K"

Output image resolution

aspectRatio

see below

"1:1"

Aspect ratio of the image

mode

"image" | "image_and_text"

"image"

Return image only, or image with description (Google models only)

thinking

"none" | "auto"

"auto"

Controls model thinking (Google models only)

outputDir

string

"."

Directory where images will be saved

inputImages

string[]

-

File paths of images to send alongside the prompt (Google models, OpenAI gpt-image models via the images.edit endpoint, and Reve via v2 references)

Supported aspect ratios

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

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"
  },
  "description": "..."
}

description is only present when mode is "image_and_text".

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);

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

createRegistry(keys)

Build a registry of the models available for the given keys

keysFromEnv(env?)

Read provider keys from environment variables

generateImageToDisk(options)

Generate images and write them to disk

resolveOutputDir / resolveInputImagePath

Path sandboxing helpers (opt-in)

Security

  • Path sandboxing: When NANO_BANANA_OUTPUT_DIR is 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 via outputBaseDir, 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).

  • 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 tool
generate_imageGenerate ImageA

Generate images using multiple providers (Google Gemini, OpenAI, BFL FLUX, Reve). Images are saved to disk and the file paths are returned.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNoResponse mode. image returns only the image; image_and_text also returns a description (Google models only)image
modelNoModel to use. Available models depend on configured API keysgpt-image-2
promptYesText prompt describing the image to generate
thinkingNoControls model thinking before generation (Google models only). none disables thinking; auto lets the model decideauto
outputDirNoDirectory 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..
resolutionNoOutput image resolution. Higher values may not be supported by all models1K
aspectRatioNoAspect ratio of the generated image1:1
inputImagesNoFile 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

A3.5/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

TDQS

A3.6/5.0
Disambiguation5/5

With only one tool, there is no possibility of confusion between tools. The single 'generate_image' tool has a clear and distinct purpose.

Naming Consistency5/5

The tool name follows a clear verb_noun pattern ('generate_image'), which is consistent and descriptive.

Tool Count2/5

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.

Completeness4/5

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

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mimo-3/mcp-imagenate'

If you have feedback or need assistance with the MCP directory API, please join our Discord server