Enables native image generation, editing, and composition using Google Gemini 2.0 Flash API, supporting text-to-image creation, iterative image editing, multi-image composition (up to 14 images), and Google Search grounding for real-time information-based generation with customizable aspect ratios and resolutions up to 4K.
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 Pro MCP Server generate a modern app icon with gradient blue background and clean typography"
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 (Model Context Protocol) server that brings Google Gemini 2.0 Flash native image generation capabilities directly into Claude Code and other MCP-compatible AI assistants.
Generate, edit, and compose images using natural language - all without leaving your coding environment.
Generate Images: Create high-quality images from text prompts (up to 4K resolution)
Edit Images: Modify existing images with text instructions
Continue Editing: Iteratively refine the last generated image
Compose Images: Combine up to 14 reference images into new compositions
Google Search Grounding: Generate images based on real-time information
Multiple Aspect Ratios: Support for 1:1, 16:9, 9:16, 4:3, 3:4, and more
High Resolution: Output at 1K, 2K, or 4K resolution
Related MCP server: Gemini Nanobanana MCP
Docker Desktop installed and running
Gemini API key from Google AI Studio
cd nano-banana-pro-mcp
docker build -t nano-banana-pro-mcp .mkdir -p output inputAdd the MCP server to Claude Code using one of these methods:
claude mcp add nano-banana-pro \
--transport stdio \
-- docker run -i --rm \
-e GEMINI_API_KEY=$GEMINI_API_KEY \
-v $(pwd)/output:/output \
-v $(pwd)/input:/input:ro \
nano-banana-pro-mcpAdd to your Claude Code MCP configuration file (~/.claude/claude_desktop_config.json or similar):
{
"mcpServers": {
"nano-banana-pro": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "GEMINI_API_KEY",
"-v", "/path/to/output:/output",
"-v", "/path/to/input:/input:ro",
"nano-banana-pro-mcp"
],
"env": {
"GEMINI_API_KEY": "your-api-key-here"
}
}
}
}generate_imageGenerate a new image from a text prompt.
Parameters:
prompt (required): Text description of the image to create
aspectRatio (optional): 1:1, 2:3, 3:2, 3:4, 4:3, 4:5, 5:4, 9:16, 16:9, 21:9
resolution (optional): 1K, 2K, or 4K
useGoogleSearch (optional): Enable real-time information grounding
Example:
Generate a professional hero image for a tech startup website, showing a
modern office with developers collaborating, 16:9 aspect ratio, 2K resolutionedit_imageEdit an existing image with text instructions.
Parameters:
imagePath (required): Path to the image file
prompt (required): Description of the modifications
referenceImages (optional): Array of reference image paths
aspectRatio (optional): Output aspect ratio
resolution (optional): Output resolution
Example:
Edit /input/logo.png - Change the background color to gradient blue and
add a subtle glow effect around the textcontinue_editingContinue editing the last generated/edited image.
Parameters:
prompt (required): Description of additional modifications
referenceImages (optional): Reference images for style transfer, etc.
aspectRatio (optional): Output aspect ratio
resolution (optional): Output resolution
Example:
Make the colors more vibrant and add a subtle drop shadowcompose_imagesCombine multiple images into a new composition.
Parameters:
images (required): Array of image paths (up to 14)
prompt (required): How to combine the images
aspectRatio (optional): Output aspect ratio
resolution (optional): Output resolution
Example:
Compose these product photos into a professional catalog layout
with consistent lighting and white backgroundget_last_image_infoGet information about the last generated image.
get_configuration_statusCheck if the API key is configured.
Be Descriptive: The more detail in your prompt, the better the result
Use Photography Terms: For realistic images, mention camera angles, lens types, lighting
Iterate: Use continue_editing to refine images step by step
Reference Images: Use up to 14 reference images for character consistency or style transfer
Google Search: Enable for real-time data like weather, news, or current events
Generated images are saved to the /output directory (mounted from ./output on your host).
Make sure your API key is set in your environment:
export GEMINI_API_KEY="your-key-here"Check the ./output directory on your host machine. Ensure the volume mount is correct.
On Linux, you may need to run:
sudo chown -R $USER:$USER outputTo run locally without Docker:
npm install
npm run build
GEMINI_API_KEY=your-key OUTPUT_DIR=./output npm startContributions are welcome! Please feel free to submit a Pull Request.
MIT
Google Gemini for the image generation API
Model Context Protocol by Anthropic
Claude Code for the amazing AI coding assistant
Combine multiple images into a new composition. Perfect for product mockups, character consistency, and creative collages. Supports up to 14 reference images.
| Name | Required | Description | Default |
|---|---|---|---|
| images | Yes | Array of file paths to images to combine (up to 14 images). | |
| prompt | Yes | Text describing how to combine the images and what to create. | |
| aspectRatio | No | Aspect ratio for the output image. | |
| resolution | No | Output resolution. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only mentions the image limit (up to 14) but does not disclose whether the tool is read-only, destructive, modifies originals, or has any side effects. This is insufficient for an agent to understand the tool's behavior.
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 extremely concise with only two sentences, no redundant information, and front-loaded with the core action. Every word serves a purpose.
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 no output schema and no annotations, the description covers the basic purpose and a limit, but omits details about return values, error conditions, or any behavioral side effects. For a tool with 4 parameters, it is adequate but not fully complete.
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 parameter descriptions in the schema are self-explanatory. The description adds minimal value beyond the schema, such as the 14-image limit, but does not explain parameter interactions or provide additional context for the 'prompt' or 'aspectRatio' fields.
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 action ('combine multiple images'), the resource ('images into a new composition'), and provides specific use cases (product mockups, character consistency, creative collages). It also notes the limit of 14 images, distinguishing it from sibling tools like edit_image or generate_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 implies usage for composition tasks via examples ('Perfect for product mockups...'), but does not explicitly state when to use this tool over alternatives or mention any prerequisites. There is no guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Continue editing the last generated/edited image in this session. Use for iterative improvements without specifying the file path.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Text describing the modifications to make to the last image. | |
| referenceImages | No | Optional array of file paths to reference images. | |
| aspectRatio | No | Aspect ratio for the output image. | |
| resolution | No | Output resolution. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Describes stateful behavior (operates on last image) but lacks details on whether it overwrites or creates new, what happens if no image exists, or other side effects.
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 action ('Continue editing...'), no unnecessary words. Every phrase earns its place.
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?
Adequate for a simple tool with good schema coverage, but lacks behavioral details (e.g., error states, mutability) and does not reference sibling tools for when-not-to-use. With no output schema or annotations, additional context would be helpful.
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 descriptions. The description adds value by clarifying the 'without specifying file path' aspect, which explains why there is no file path parameter and emphasizes the stateful context.
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?
Clearly states verb 'continue editing' and resource 'last generated/edited image in this session'. Distinguishes from sibling tools by mentioning no file path needed, implying it's for iterative improvements on the most recent 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?
Explicitly says 'use for iterative improvements without specifying the file path', giving clear context for when to use. However, no explicit when-not-to-use or alternative tool references, though sibling names suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit an existing image file using text instructions. Can add/remove elements, change styles, transfer styles from reference images, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| imagePath | Yes | Full file path to the image to edit. | |
| prompt | Yes | Text describing the modifications to make to the image. | |
| referenceImages | No | Optional array of file paths to reference images (for style transfer, adding elements, etc.). Up to 14 images supported. | |
| aspectRatio | No | Aspect ratio for the output image. | |
| resolution | No | Output resolution. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided so description must fully disclose behavior. Mentions editing but does not explain whether original file is overwritten, what happens on failure, or any other side effects.
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?
Efficient single sentence with bullet-like examples. Clear and front-loaded, but could be slightly more structured (e.g., separate actions from uses).
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?
Description covers what the tool does but omits output specification (e.g., where edited image is saved) and behavioral details. Missing completeness for a mutation tool with no output schema.
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 clear parameter descriptions. Description adds little beyond listing capabilities, providing no extra semantic detail for parameters.
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?
Description clearly states action (edit), resource (existing image file), and lists specific capabilities (add/remove elements, change styles, style transfer). Distinguishes from siblings like compose_images and generate_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?
No explicit guidance on when to use this tool vs siblings. Lacks context like prerequisites (e.g., image must exist) or when to prefer continue_editing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a NEW image from text prompt using Gemini 3 Pro. Use this for creating completely new images from scratch. Supports high-resolution output (1K, 2K, 4K) and various aspect ratios.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Text prompt describing the image to create. Be descriptive and specific for best results. | |
| aspectRatio | No | Aspect ratio for the generated image. Default is 1:1. | |
| resolution | No | Output resolution. Default is 1K. Higher resolutions take longer. | |
| useGoogleSearch | No | Enable Google Search grounding for real-time information (weather, news, etc.). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the model (Gemini 3 Pro), support for resolutions and aspect ratios, and that higher resolutions take longer. However, it lacks details on output format, potential failures, or any destructive effects.
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, no unnecessary words. Every sentence adds value: first states primary function and model, second explains use case and highlights key features.
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 straightforward image generation tool with no output schema and no annotations, the description covers purpose, supported options, and a usage hint. It could mention cost, rate limits, or maximum resolution, but is sufficient for basic operations.
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% so baseline is 3. The description adds marginal context ('be descriptive and specific for best results' for prompt, 'Higher resolutions take longer' for resolution), which is helpful but not substantial 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?
Description explicitly states 'Generate a NEW image from text prompt' and 'Use this for creating completely new images from scratch,' which clearly identifies the action and distinguishes it from sibling tools like edit_image or continue_editing.
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 clearly indicates when to use this tool ('creating completely new images from scratch'), but does not explicitly provide when-not-to-use scenarios or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if the Gemini API key is configured and ready to use.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a non-modifying check operation, which is consistent with its purpose. While no annotations are provided, the behavioral disclosure is sufficient for a zero-parameter, read-only 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?
The description is a single, concise sentence that front-loads the purpose without any superfluous details.
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 simple configuration check with no parameters and no output schema, the description provides all necessary context to understand the tool's function.
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?
No parameters exist, and schema coverage is 100%. The description adds no parameter information, which is acceptable given the absence of parameters.
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 uses a specific verb ('check') and identifies the resource ('Gemini API key configuration'), clearly distinguishing from image-related sibling tools.
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 implies usage context (checking configuration) but does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the last generated/edited image in this session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states a read operation but does not disclose what happens if no image exists, what information is returned, or any side effects. This leaves significant unknowns for an agent.
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 a single clear sentence, front-loading the essential purpose with no extraneous content. It is appropriately sized for its simplicity.
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?
With no output schema and no annotations, the description lacks details on what information is returned. It mentions the context of the session but leaves the agent without knowledge of the return structure, which is important for a 'get' tool.
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?
There are no parameters, and schema coverage is 100%. The description does not need to add parameter details, but it could have elaborated on the return format; however, for zero parameters, a baseline of 4 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?
The description clearly states the verb 'Get information' and the specific resource 'last generated/edited image in this session', which distinguishes it from sibling tools like edit_image or generate_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 implies usage when needing information about the last image in the current session, but does not provide explicit when-not or alternative tool guidance. The sibling tools cover distinct actions, so context is clear but no exclusions are given.
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.0compose_imagescontinue_editingedit_imagegenerate_imageget_configuration_statusget_last_image_infoScored across 6 tools
Each tool has a clearly distinct purpose: composing multiple images, continuing edits on the last image, editing a specified image, generating new images, checking API configuration, and retrieving info about the last image. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., compose_images, generate_image, get_configuration_status). The naming is predictable and clear.
With 6 tools, the server is well-scoped for image generation and editing tasks. Each tool serves a necessary function without redundancy or excessive complexity.
The tool set covers the core image lifecycle: create (generate_image), edit (edit_image), composite (compose_images), iterative refinement (continue_editing), status check, and information retrieval. No obvious gaps for the intended purpose.
Generate and edit images and create short videos inside Claude. Prepaid credits, no subscription.
AI image and video generation, talking avatars, consistent characters and photo packs from Claude.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
LLM chat, text tools, image generation, editing, batch image jobs, and asynchronous video generation
