Skip to main content
Glama
plemio

Nano Banana MCP Server

by plemio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Generate or edit images (Multi-Model: Flash & Pro)

generate_image
Read-only

Generate new images or edit existing ones from natural language prompts, with automatic mode detection and support for multiple reference images.

Instructions

Generate new images or edit existing images using natural language instructions.

Supports multiple input modes:

  1. Pure generation: Just provide a prompt to create new images

  2. Editing / fusion: pass input_image_paths — the first image is the one being edited (its scene and subjects are preserved), the rest are references to blend in. Up to 14 images with the 'nb2' and 'pro' tiers, 3 with 'flash'.

  3. File ID editing: Edit previously uploaded images using Files API ID

Automatically detects mode based on parameters or can be explicitly controlled. Input images are read from the local filesystem to avoid massive token usage. Returns both MCP image content blocks and structured JSON with metadata.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nNoRequested image count (model may return fewer).
modeNoOperation mode: 'generate' for new image creation, 'edit' for modifying existing images. Auto-detected based on input parameters if not specified.auto
promptYesClear, detailed image prompt. Include subject, composition, action, location, style, and any text to render. Use the aspect_ratio parameter to pin a specific canvas shape when needed.
file_idNoFiles API file ID to use as input/edit source (e.g., 'files/abc123'). If provided, this takes precedence over input_image_path_* parameters for the primary input.
model_tierNoModel tier: 'flash' (legacy, 1024px), 'nb2' (4K at Flash speed, default), 'pro' (max quality, 4K), or 'auto' (smart selection). Default: 'auto' - automatically selects nb2 or pro based on prompt.auto
resolutionNoOutput resolution: 'high', '4k', '2k', '1k'. 4K and 2K available with 'nb2' and 'pro' models. Default: 'high'.high
output_pathNoOutput path for generated image(s). If a file path with extension (e.g., '/path/image.png'), saves directly to that path. If a directory path (e.g., '/path/to/dir/'), uses default filename in that directory. If None, uses IMAGE_OUTPUT_DIR environment variable or ~/nanobanana-images.
aspect_ratioNoOptional output aspect ratio (e.g., '16:9'). Standard: 1:1, 2:3, 3:2, 3:4, 4:3, 4:5, 5:4, 9:16, 16:9, 21:9. Extreme (nb2 only): 4:1, 1:4, 8:1, 1:8.
thinking_levelNoReasoning depth hint: 'low' (faster), 'high' (better quality). Applied to the 'nb2' model; 'high' also biases auto-selection toward Pro. Default: None (auto).
negative_promptNoThings to avoid (style, objects, text).
enable_groundingNoEnable Google Search grounding for factual accuracy (NB2 and Pro models). Useful for real-world subjects. Default: true.
input_image_pathsNoInput images, in order. The FIRST one is the image being edited (its scene, subjects and faces are preserved); the following ones are references whose subjects, characters or styles get brought into it. Up to 14 with the 'nb2' and 'pro' tiers, 3 with 'flash'. Pass a single path to plainly edit one image, none to generate from scratch.
return_full_imageNoReturn full-resolution images in MCP response instead of thumbnails. Warning: full images can be large (3-7MB each for 4K). Default: uses RETURN_FULL_IMAGE env var, or false if not set.
input_image_path_1NoLegacy single-slot form of input_image_paths[0].
input_image_path_2NoLegacy single-slot form of input_image_paths[1].
input_image_path_3NoLegacy single-slot form of input_image_paths[2].
system_instructionNoOptional system tone/style guidance.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations declare readOnlyHint=true, but the description describes creating and editing image files, saving to output paths, and returning generated content — clearly a write-capable operation. This is a direct contradiction with the annotation. The description does add useful behavioral context (local filesystem reads, full-image size warnings, auto mode detection), but the contradiction forces a score of 1 per the evaluation rules.

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 well-structured and front-loaded: it states the core capability first, then enumerates modes, filesystem behavior, and return types in a scannable numbered/bulleted format. Despite the tool's complexity, every sentence contributes meaningful guidance without excessive redundancy with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 17-parameter tool with no output schema, the description covers the essential aspects: mode selection, editing semantics, tier limits, local filesystem reads, and return format (MCP content blocks plus structured JSON). It does not detail the shape of the structured metadata JSON or error conditions, but it provides enough contextual breadth for correct invocation in most cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though schema coverage is 100%, the description adds substantial semantic meaning beyond the schema: the first input image is the primary edit target while the rest are reference images, file_id takes precedence over input_image_path_* parameters, tier limits are clarified, and output_path behavior is summarized. This materially helps an agent choose and populate parameters correctly.

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 opens with a precise verb+resource statement: 'Generate new images or edit existing images using natural language instructions.' It further distinguishes the tool by enumerating three distinct input modes (pure generation, editing/fusion, file ID editing), making it easy to separate from siblings like upload_file and show_output_stats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives strong context for when to use each mode: pure generation vs editing via input_image_paths, file ID editing, and explicit vs auto-detected mode. It also explains tier-specific limits (14 images with nb2/pro, 3 with flash). It does not explicitly name sibling upload_file as the companion tool for obtaining a Files API ID, but 'File ID editing: Edit previously uploaded images using Files API ID' strongly implies that workflow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools