Generates images through Google's Gemini (Nano Banana) image generation API from a text prompt, supporting configurable aspect ratios and custom output filenames, with generated images saved to a local output directory.
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., "@nano-banana Generate a 16:9 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 server for image generation using Nano Banana (Gemini). Use it with Claude Code to generate images directly from your prompts.
Go to Google AI Studio
Create a new API key
Save it securely (you'll use it in step 3)
git clone https://github.com/baiano/mcp-nano-banana.git
cd mcp-nano-banana
npm install
npm run buildAdd the key to your shell profile (~/.zshrc or ~/.bashrc):
echo 'export GEMINI_API_KEY=your_key_here' >> ~/.zshrc
source ~/.zshrcAlternatively, you can set it per-project in the Claude Code MCP config (see below).
Run the following command:
claude mcp add nano-banana -- node /absolute/path/to/mcp-nano-banana/dist/index.jsOr add it manually to ~/.claude/settings.json:
{
"mcpServers": {
"nano-banana": {
"command": "node",
"args": ["/absolute/path/to/mcp-nano-banana/dist/index.js"],
"env": {
"GEMINI_API_KEY": "your_key_here"
}
}
}
}If you set GEMINI_API_KEY in your shell profile, you can omit the env block.
By default, images are saved to ~/Pictures/nano-banana/. Override it with:
{
"env": {
"GEMINI_API_KEY": "your_key_here",
"NANO_BANANA_OUTPUT_DIR": "/path/to/your/folder"
}
}Related MCP server: Gemini Image MCP Server
Once configured, just ask Claude Code to generate images naturally:
"Generate an image of a medieval knight in pixel art style"
"Create a 16:9 landscape of a futuristic city at sunset"
"Draw a cute cartoon cat with a wizard hat, save as wizard-cat.png"
Claude will recognize the intent and call the generate_image tool via MCP.
generate_imageParameter | Required | Description |
| Yes | Detailed description of the image to generate |
| No |
|
| No | Custom filename (e.g. |
npm test # Run tests
npm run build # Compile TypeScriptGenerate an image using Nano Banana (Gemini). Saves the image to disk and returns the file path. Use this tool whenever the user asks to generate, create, draw, or make an image, picture, illustration, photo, artwork, or visual.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model to use for this generation. Available: gemini-2.5-flash-image, gemini-2.0-flash-exp-image-generation, gemini-3-pro-image-preview, gemini-3.1-flash-image-preview. Defaults to the current active model. | |
| prompt | Yes | Detailed description of the image to generate. Be specific about style, content, colors, composition. | |
| filename | No | Optional filename for the output image (e.g. 'my-character.png'). Defaults to auto-generated name with timestamp. | |
| aspect_ratio | No | Aspect ratio for the generated image. | 1:1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the side effect (saves the image to disk) and the return value (file path), which is the most important trait for an agent. However it omits cost/latency of the external API call, permission requirements, and what happens if 'filename' collides with an existing file.
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?
Two sentences, front-loaded with the verb and side effect before the trigger list. Every phrase earns its place and there is no padding or restatement of the tool name.
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?
Since there is no output schema, the description correctly compensates by stating that a file path is returned. Combined with 100% schema coverage on the four parameters, an agent has enough to invoke it correctly; only secondary details (cost, overwrite behavior) are missing.
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 every parameter (model, prompt, filename, aspect_ratio) is already documented in the schema. The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 is 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?
States a specific verb+resource ('Generate an image') and names the underlying model (Nano Banana / Gemini). It also distinguishes itself from the sibling tools (list_models, set_model), which are model-management utilities rather than image producers.
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?
Provides an explicit trigger list ('whenever the user asks to generate, create, draw, or make an image, picture, illustration, photo, artwork, or visual'), which is strong when-to-use guidance. It does not state when NOT to use it or name alternatives, but the sibling tools are unrelated so no ambiguity remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available image generation models for Nano Banana.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and 'List all available' does convey an exhaustive, non-mutating read. However, it says nothing about the shape of a model entry, whether authentication or a specific account/workspace is required, or whether results are catalog-stable, leaving real gaps for a no-annotation tool.
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?
A single front-loaded sentence with no filler; the verb and resource come first and every word earns its place. Nothing could be trimmed without losing meaning.
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 trivial zero-parameter read tool this is nearly adequate, but with no output schema and no annotations the description could usefully say what identifying information a listed model carries (e.g., names/IDs to pass to set_model). As written, an agent knows what happens but not what it will get back or how to act on it.
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 takes zero parameters, so the baseline of 4 applies; there is no parameter whose semantics need explaining. Nothing in the description contradicts or adds confusion on this dimension.
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 pairs a specific verb ('List') with a specific resource ('all available image generation models'), and the word 'List' readily distinguishes it from siblings generate_image and set_model. It stops short of explicitly naming those siblings, but the verb alone is differentiating.
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?
There is no statement of when to use this tool versus set_model or generate_image, and no prerequisites or ordering guidance. The natural 'discover a model, then set it' workflow is left entirely to inference, so an agent gets no real routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change the active image generation model for Nano Banana.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model ID to set as active. Available: gemini-2.5-flash-image, gemini-2.0-flash-exp-image-generation, gemini-3-pro-image-preview, gemini-3.1-flash-image-preview |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says the setting is "active" but never states whether the change persists across sessions, whether it affects in-flight or subsequent generate_image calls, or what permissions are required for a mutating operation.
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?
A single, front-loaded sentence with no wasted words. It is efficient, though its brevity is partly the source of the missing behavioral detail.
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 one-parameter mutation tool with no output schema, the description is minimally adequate. It should at least clarify the persistence/scope of the change and point to list_models for ID discovery, which it does not.
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% and the single "model" parameter already lists every valid model ID, so the description has nothing to add. The baseline of 3 for a fully documented schema 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?
States a specific verb ("Change") and resource ("the active image generation model"), which reads clearly against the sibling verbs generate_image and list_models. It does not explicitly name or contrast those siblings, so it falls short of a 5.
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?
There is no guidance on when to use this versus list_models (to discover valid IDs) or generate_image, and no stated prerequisites. Only the implied reading of "change the active model" suggests usage context.
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.
v1.0.0generate_imagelist_modelsset_modelScored across 3 tools
Each tool has a clearly distinct purpose: generate an image, list available models, and set the active model. There is no overlap or ambiguity between these operations.
All tools follow a consistent snake_case verb_noun pattern: generate_image, list_models, set_model. The convention is predictable and readable.
Three tools is well-scoped for this server's purpose. Each tool earns its place, covering generation and model management without unnecessary bloat.
The core lifecycle (generate image) and model management (list, set) are covered. A minor gap is the absence of an explicit way to query the currently active model, though list_models may implicitly indicate it.
Generate and edit images and create short videos inside Claude. Prepaid credits, no subscription.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
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.
AI image and video generation, talking avatars, consistent characters and photo packs from Claude.
