Enables image generation and editing via the Google Gemini API, supporting text-to-image, multi-image input, batch processing at reduced cost, and aspect ratio control.
Click on "Install 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., "@NanoBanana MCP Server generate a photo of a cat wearing a hat, aspect ratio 1:1"
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 connects to the Google Gemini API to generate and edit images using the Nano Banana Pro image generation model.
Text-to-Image Generation — Describe an image and get it generated via the Gemini API.
Image Editing — Provide one or more existing images and a text instruction to edit or transform them.
Multi-Image Input — Send multiple images for blending, style transfer, collages, and more.
Batch Mode — Submit many prompts at once at 50% reduced cost. Jobs run async and results are polled/downloaded automatically.
Aspect Ratio Control — Force output to a specific aspect ratio (1:1, 16:9, 9:16, etc.).
File Output — Save generated images directly to disk with key-based filenames.
Job Tracking — Batch jobs are persisted to data/batch_jobs.json with full state, input JSONL, and output references.
Related MCP server: Gemini Flash Image MCP Server
Node.js >= 18
A Google Gemini API key — get one at Google AI Studio
git clone https://github.com/slackermafia/NanoBanana-MCP-Server.git
cd NanoBanana-MCP-Server
npm installSet your Gemini API key as an environment variable:
export GEMINI_API_KEY="your-api-key-here"Add this to your MCP server configuration:
{
"mcpServers": {
"nanobanana": {
"command": "node",
"args": ["/absolute/path/to/NanoBanana-MCP-Server/src/index.js"],
"env": {
"GEMINI_API_KEY": "your-api-key-here"
}
}
}
}gemini_generate_imageGenerate an image from a text prompt (synchronous, single image).
Parameter | Type | Required | Description |
| string | Yes | Detailed description of the image to create |
| string | No | Output aspect ratio (e.g. |
| string | No | Gemini model ID (default: |
| string | No | File path to save the generated image |
gemini_edit_imageEdit one or more images using a text instruction (synchronous).
Parameter | Type | Required | Description |
| string | Yes | Text instruction describing the edit |
| string | No* | Comma-separated list of file paths to input images |
| string | No* | JSON array of |
| string | No | Output aspect ratio |
| string | No | Gemini model ID |
| string | No | File path to save the edited image |
* You must provide at least one image via image_paths or image_base64_list.
gemini_batch_submitSubmit a batch of image generation requests at 50% reduced cost. Jobs run asynchronously (typically completes within 24 hours).
Parameter | Type | Required | Description |
| string | Yes | JSON array of request objects (see below) |
| string | Yes | Directory where completed images will be saved |
| string | No | Gemini model ID |
| string | No | Human-readable name for the batch job |
Each request object in the requests array:
{
"key": "pink-flamingo",
"prompt": "A neon pink flamingo sign on a dark wall",
"aspect_ratio": "1:1",
"image_paths": "/optional/reference/image.jpg"
}The key is used as the output filename — so "pink-flamingo" produces pink-flamingo.jpg. This is how you match input prompts to output images.
A JSONL input file is saved to data/ for debugging, and the job ID is tracked in data/batch_jobs.json.
gemini_batch_statusCheck the status of pending batch jobs.
Parameter | Type | Required | Description |
| string | No | Specific batch ID (e.g. |
Returns the current state of each job: JOB_STATE_PENDING, JOB_STATE_RUNNING, JOB_STATE_SUCCEEDED, JOB_STATE_FAILED, or JOB_STATE_CANCELLED.
gemini_batch_resultsDownload and save images from completed batch jobs.
Parameter | Type | Required | Description |
| string | No | Specific batch ID. Omit to process all completed jobs. |
| string | No | Override the output directory from submission time. |
Downloads the output JSONL from Gemini, decodes each image, and saves it using the key as the filename. Also saves the raw output JSONL to data/ for debugging.
1. Submit batch → gemini_batch_submit (creates JSONL, uploads, starts job)
2. Wait → Job runs async on Google's side (up to 24h, usually faster)
3. Check status → gemini_batch_status (poll for completion)
4. Download results → gemini_batch_results (saves images to output_dir as {key}.jpg)A Cowork scheduled task (nanobanana-batch-poll) can be set up to automatically poll every hour and download results when jobs complete.
NanoBanana-MCP-Server/
├── src/
│ ├── index.js # MCP server with all 5 tools
│ └── batch.js # Batch API helpers, JSONL builder, job tracking
├── data/
│ ├── batch_jobs.json # Tracked batch jobs (state, IDs, paths)
│ ├── batch_input_*.jsonl # Input JSONL files (for debugging)
│ └── batch_output_*.jsonl # Output JSONL files (for debugging)
├── package.json
└── README.md1:1, 3:2, 2:3, 3:4, 4:3, 4:5, 5:4, 9:16, 16:9, 21:9
MIT
Download and save images from a completed batch job.
Checks the batch status, retrieves the output JSONL from Gemini, decodes each image, and saves them to the specified output directory using the key as the filename.
Args:
batch_name (string, required): The batch ID (e.g. "batches/abc123").
output_dir (string, required): Directory where images will be saved.
Returns:
List of saved image paths (key → file path) and any errors.
| Name | Required | Description | Default |
|---|---|---|---|
| batch_name | Yes | The batch ID (e.g. "batches/abc123") | |
| output_dir | Yes | Directory where images will be saved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the full sequence of operations (checks status, retrieves JSONL, decodes, saves) and returns errors. This adds context beyond annotations (which only indicate not read-only, not idempotent). No contradictions with annotations.
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 well-structured with a lead sentence and clear sections, but the Args block is redundant with the schema, adding unnecessary length. Could be more concise.
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 two parameters and no output schema, the description explains the process and return value (list of paths and errors). It is sufficiently complete, though missing details like file overwrite behavior or error types.
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%, and the description repeats the schema descriptions verbatim without adding new semantic context (e.g., format, constraints). Baseline score of 3 is appropriate as the schema already documents both 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 strong action verbs ('Download and save') and specifies the resource ('images from a completed batch job'). It clearly distinguishes from sibling tools like gemini_batch_status, gemini_batch_submit, and image editing/generation 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 after a batch is complete and details the process (check status, retrieve output, decode, save). However, it does not explicitly state when not to use or suggest alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a batch image generation job.
Args:
batch_name (string, required): The batch ID to check (e.g. "batches/abc123").
Returns:
state: BATCH_STATE_PENDING, BATCH_STATE_RUNNING, BATCH_STATE_SUCCEEDED, BATCH_STATE_FAILED, etc.
output_file: The Gemini Files API reference for downloading results (when succeeded).
stats: Request count and success count.
Timing: create time, end time.
| Name | Required | Description | Default |
|---|---|---|---|
| batch_name | Yes | The batch ID to check (e.g. "batches/abc123") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. The description adds return fields (state, output_file, stats, timing), enriching behavioral understanding beyond annotations.
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?
Front-loaded with purpose, followed by parameter and return details. Bullet points aid readability. Could be more concise but efficient overall.
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?
No output schema, so description carries responsibility. It lists state enum values, output file reference, stats, and timing. Adequate for a status check 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?
Schema coverage is 100% so baseline is 3. The description repeats the parameter info with an example, adding minor value but no significant new meaning.
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?
Clear verb 'Check the status' and specific resource 'batch image generation job'. Distinguished from sibling gemini_batch_results and gemini_batch_submit by focusing on status.
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?
Implied usage: check status after submission. No explicit when-not or alternatives, but sibling names provide context. The description itself lacks usage guidance beyond purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a batch of image generation requests to the Gemini API at 50% reduced cost.
Builds a JSONL file, uploads it to the Gemini Files API, and submits a batch job. The job processes asynchronously (usually completes within minutes). Returns the batch ID — the caller is responsible for tracking it (e.g. in Supabase).
Args:
requests (string, required): JSON array of request objects. Each object must have:
key (string): Unique identifier for this request (used as output filename)
prompt (string): The image generation prompt
aspect_ratio (string, optional): Aspect ratio for this image
image_paths (string, optional): Comma-separated input image paths for editing (slow — base64 encodes each) Example: [{"key":"sunset-cat","prompt":"A cat watching a sunset","aspect_ratio":"16:9"}]
file_uris (string, optional): Comma-separated Gemini Files API URIs of pre-uploaded reference images (e.g. "files/abc123,files/def456"). These are shared across ALL requests in the batch. Use gemini_upload_image first to get URIs. Much faster than image_paths for large batches.
model (string, optional): Gemini model ID. Defaults to "gemini-3.1-flash-image-preview".
image_size (string, optional): Output image resolution. Values: "1K" (1024px), "2K" (2048px), "4K" (4096px). Defaults to "2K".
display_name (string, optional): Human-readable name for the batch job.
Returns:
The batch name/ID, request count, and model used.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Gemini model ID (default: gemini-3.1-flash-image-preview) | gemini-3.1-flash-image-preview |
| requests | Yes | JSON array of {key, prompt, aspect_ratio?, image_paths?} objects | |
| file_uris | No | Comma-separated Gemini file URIs of pre-uploaded reference images shared across all requests (e.g. "files/abc,files/def") | |
| image_size | No | Output image resolution: "1K" (1024px), "2K" (2048px), or "4K" (4096px). Default: "2K" | 2K |
| display_name | No | Human-readable name for the batch job |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses async processing, file upload steps, and return of batch ID. Annotations already indicate a write operation (readOnlyHint=false) and non-destructive behavior. However, it could mention failure handling or rate limits, but overall adds good context beyond annotations.
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 well-structured with clear sections (args, returns) and uses concise language. It is not excessively long, though some redundancy exists (e.g., listing fields already in schema). Overall efficient.
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 5 parameters, no output schema, the description fully covers the return value (batch ID, count, model), async nature, and tracking responsibility. It also relates to sibling tools (gemini_upload_image). Highly complete for an agent to use correctly.
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?
With 100% schema coverage, baseline is 3, but the description greatly enriches understanding: explains that 'requests' requires key, prompt, and optional fields; provides an example; distinguishes file_uris as faster; and clarifies image_size values. This goes well beyond the schema descriptions.
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 starts with 'Submit a batch of image generation requests to the Gemini API at 50% reduced cost,' clearly stating the action and resource. It distinguishes from sibling tools by focusing on submission, while siblings handle results/status.
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 explains when to use this tool (for cost-effective batch generation) and provides guidance on alternatives: recommends using file_uris over image_paths for speed, and notes that the caller is responsible for tracking the batch ID. This effectively sets context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit or transform one or more images using a text instruction, powered by the Google Gemini Nano Banana image model.
Supports single or multiple input images. Provide file paths and/or base64-encoded image data along with a text instruction.
Args:
prompt (string, required): A text instruction describing the edit (e.g. "Remove the background", "Combine these two images").
image_paths (string, optional): Comma-separated list of file paths to input images on disk. Example: "/path/to/img1.png,/path/to/img2.jpg"
image_base64_list (string, optional): JSON array of objects with "data" and "mimeType" fields for base64-encoded images. Example: [{"data":"base64...","mimeType":"image/png"}]
aspect_ratio (string, optional): Aspect ratio for the output image. Supported: 1:1, 3:2, 2:3, 3:4, 4:3, 4:5, 5:4, 9:16, 16:9, 21:9
model (string, optional): Gemini model ID. Defaults to "gemini-3.1-flash-image-preview".
output_path (string, optional): File path to save the edited image.
Returns:
The edited image as an embedded image block (and optionally saved to disk).
Any text the model returns alongside the image.
Examples:
prompt: "Change the car color to red" with one image
prompt: "Combine these two photos into a collage" with two images
prompt: "Apply the style of the first image to the second image" with two images
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Gemini model ID (default: gemini-3.1-flash-image-preview) | gemini-3.1-flash-image-preview |
| prompt | Yes | Text instruction describing the desired image edit | |
| image_size | No | Output image resolution: "1K" (1024px), "2K" (2048px), or "4K" (4096px) | |
| image_paths | No | Comma-separated list of file paths to input images (e.g. '/path/img1.png,/path/img2.jpg') | |
| output_path | No | Optional file path to save the edited image | |
| aspect_ratio | No | Aspect ratio for the output image. Supported: 1:1, 3:2, 2:3, 3:4, 4:3, 4:5, 5:4, 9:16, 16:9, 21:9 | |
| image_base64_list | No | JSON array of objects with "data" and "mimeType" fields for base64-encoded images |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide limited info (openWorldHint, etc.). Description adds significant behavioral context: powered by Gemini Nano Banana model, returns an embedded image block and optional disk save, and any accompanying text. No contradiction with annotations.
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?
Well-structured with clear sections (description, args, returns, examples). Every sentence is informative, no redundancy, and it is appropriately concise for a multi-parameter tool.
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?
Despite missing output schema, the description explains the return format. All 7 parameters are documented in schema and description adds clarifying examples. Annotations provide additional hints. Complete for this complexity level.
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 covers all parameters (100% coverage). Description adds value with examples, format details (e.g., comma-separated paths, JSON array for base64), and supported aspect ratios, enhancing schema documentation.
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 it edits or transforms images using a text instruction. It specifies the resource (images) and action (edit/transform), distinguishing it from sibling tools like gemini_generate_image which creates new images.
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 provides typical usage examples and states support for single or multiple images. It implicitly tells when to use (to edit images) but lacks explicit comparison to alternatives like gemini_generate_image for creation vs editing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an image from a text prompt using the Google Gemini Nano Banana image generation model.
Args:
prompt (string, required): A detailed description of the image to generate.
aspect_ratio (string, optional): Aspect ratio for the output image. Supported: 1:1, 3:2, 2:3, 3:4, 4:3, 4:5, 5:4, 9:16, 16:9, 21:9
model (string, optional): Gemini model ID to use. Defaults to "gemini-3.1-flash-image-preview".
output_path (string, optional): File path to save the generated image.
Returns:
The generated image as an embedded image block (and optionally saved to disk).
Any text the model returns alongside the image.
Examples:
"A photorealistic golden retriever surfing a wave at sunset"
"An isometric pixel-art castle on a floating island"
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Gemini model ID (default: gemini-3.1-flash-image-preview) | gemini-3.1-flash-image-preview |
| prompt | Yes | A detailed text description of the image to generate | |
| image_size | No | Output image resolution: "1K" (1024px), "2K" (2048px), or "4K" (4096px) | |
| output_path | No | Optional file path to save the generated image | |
| aspect_ratio | No | Aspect ratio for the output image. Supported: 1:1, 3:2, 2:3, 3:4, 4:3, 4:5, 5:4, 9:16, 16:9, 21:9 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readOnly and non-destructive. The description adds that the tool returns an embedded image block and optionally saves to disk. However, it does not disclose potential side effects like cost or latency. The mention of 'Gemini Nano Banana' model might be outdated but does not contradict annotations.
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 well-structured with Args, Returns, and Examples sections. Every sentence adds value, and the main purpose is front-loaded. No redundant or unnecessary text.
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?
Despite having 5 parameters and no output schema, the description omits the image_size parameter, leading to incomplete parameter documentation. It also does not explain return values beyond mentioning an embedded image block. For a tool with moderate complexity, this is a notable gap.
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 covers all parameters with descriptions (100% coverage). The description adds value by providing examples and repeating key parameter info in a more readable format. However, it omits the image_size parameter entirely, missing a chance to add context 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?
The description clearly states it generates an image from a text prompt, specifying the model. It implicitly distinguishes from siblings like edit_image or upload_image by focusing on generation, but does not explicitly contrast them, preventing a top score.
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 guidance on when to use this tool vs alternatives like gemini_edit_image. The description only states what it does, not when it is appropriate or 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.
Upload one or more images to the Gemini Files API and return their file URIs.
Use this to pre-upload reference images before calling gemini_batch_submit. Uploaded files persist for 48 hours on Google's servers. Pass the returned URIs to batch_submit via the file_uris field to avoid slow base64 encoding.
Args:
image_paths (string, required): Comma-separated list of local file paths to upload. Example: "/path/to/ref1.jpg,/path/to/ref2.png"
Returns:
A list of file URIs (e.g. "files/abc123") mapped to each input path.
| Name | Required | Description | Default |
|---|---|---|---|
| image_paths | Yes | Comma-separated list of local file paths to upload |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds that files persist for 48 hours and return value is a list of URIs. Annotations don't contradict (readOnlyHint=false matches write operation). No mention of rate limits or failure modes, but context is good.
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?
Very concise: three sentences for purpose/usage, then args/returns in structured format. No superfluous text.
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 single parameter and no nested objects, the description fully explains input, behavior, and output. No output schema needed due to clear description.
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 covers 100% of parameters, and description provides an example of the comma-separated path format, which adds practical guidance 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?
The description clearly states the tool uploads images to Gemini Files API and returns file URIs. It distinguishes from siblings by explicitly mentioning its use before gemini_batch_submit.
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 this to pre-upload reference images before calling gemini_batch_submit' and explains benefit of avoiding base64 encoding. Lacks when-not-to-use or alternatives, but sufficient.
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. Dates show when Glama detected each change.
v1.0.0gemini_batch_resultsgemini_batch_statusgemini_batch_submitgemini_edit_imagegemini_generate_imagegemini_upload_imageEach tool has a clearly distinct purpose: batch submission, status checking, result downloading, single image generation, single image editing, and image upload. No overlap or confusion possible.
All tools use the consistent pattern 'gemini_<verb>_<noun>' with snake_case (e.g., gemini_batch_submit, gemini_edit_image). No deviations or mixed conventions.
6 tools cover both single and batch image operations plus upload and editing, which is well-scoped for the server's purpose. Not too few or too many.
Core workflows (generate, edit, batch submit/status/results, upload) are covered. Minor gaps like deleting batches or listing all batches are missing but not critical for typical usage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI image generation across 5 quality tiers (SDXL to Gemini 3 Pro), 50 free credits on signup.
Generate images, video & speech with Nano Banana, Veo, Omni and Gemini TTS. Pay as you go.
Create images and videos from prompts, with options for image mixing, reference images, and start/…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/slackermafia/NanoBanana-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
