ultimate-gemini-mcp
Allows generating images using Google's Gemini 3.1 Flash Image model with features like high-resolution output (up to 4K), Google Search grounding, Google Image Search for visual references, up to 14 reference images, and configurable thinking levels.
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., "@ultimate-gemini-mcpgenerate a 4K image of a cyberpunk city at night"
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.

Ultimate Gemini MCP
MCP server for Google's Gemini 3.1 Flash Image — fast image generation with advanced reasoning, 512px–4K resolution, up to 14 reference images, Google Search grounding, and automatic thinking mode.
Setup
Claude Desktop
Add to your mcp config (mcp.json / .claude.json):
{
"mcpServers": {
"ultimate-gemini": {
"command": "uvx",
"args": ["ultimate-gemini-mcp@latest"],
"env": {
"GEMINI_API_KEY": "your-api-key-here"
}
}
}
}All generated images include invisible SynthID watermarks for authenticity and provenance tracking.
Related MCP server: Nano Banana 2 Polza MCP Server
Features
Gemini 3.1 Flash Image
High-Resolution Output: 512px, 1K, 2K, and 4K resolution
Advanced Text Rendering: Legible, stylized text in infographics, menus, diagrams, and logos
Up to 14 Reference Images: Up to 10 objects + 4 characters for style/character consistency
Google Search Grounding: Real-time data (weather, stocks, events, maps)
Google Image Search: Visual context from web images — the model can FIND real images of anything
Thinking Mode: Configurable reasoning - "minimal" (fast) or "high" (best quality)
Transparent Backgrounds: Flip one flag → ready-to-use transparent PNG/WebP cut-outs with a real alpha channel, recovered by a two-pass difference matte (generate on white → edit to black → solve for alpha). True soft edges/glow/glass, no color halo. Pillow only — no extra dependencies. Costs a second model call (~2x).
Dedicated App-Icon / Logo Tool:
generate_app_iconforces a square, transparent, 1024px PNG every time — no way to get a non-square or opaque-background icon
This model is different. Unlike traditional image generators that rely solely on training data, Gemini 3.1 Flash has live access to Google Search and Image Search. It can find actual references for products, people, events, or anything that exists online. "Way of Wade 12" → generates the REAL shoe. "Tony Hawk" → finds real photos. Don't over-prompt — let the model cook.
Server Features
Batch Processing: Generate multiple images in parallel (up to 8 concurrent)
26 Expert Prompt Templates: MCP slash commands for photography, cinematics, storyboards, and more
Flexible Aspect Ratios: 14 options — 1:1, 1:4, 1:8, 2:3, 3:2, 3:4, 4:1, 4:3, 4:5, 5:4, 8:1, 9:16, 16:9, 21:9
Configurable via Environment Variables: Output directory, default size, timeouts, and more
Showcase
Photorealistic Capabilities
Jensen Huang — GPU Surfing

Elon Musk — Mars Chess Match

Jensen Huang — GPU Kitchen

Elon Musk — Cybertruck Symphony

Jensen Huang — Underwater Data Center

Elon Musk — SpaceX Skateboarding

Google Search Grounding
Current Weather in San Francisco

Google Image Search
Butterfly on Flower

Different Resolutions
512px (fastest)

1K

2K

Quick Start
Prerequisites
Python 3.11+
Google Gemini API key (free tier available)
Installation
Using uvx (recommended — no install needed):
uvx ultimate-gemini-mcp@latestNote: Use
@latestto ensure uv always fetches the newest version from PyPI. Without it, uv may use a cached environment.
Using pip:
pip install ultimate-gemini-mcpFrom source:
git clone https://github.com/anand-92/ultimate-image-gen-mcp
cd ultimate-image-gen-mcp
uv syncConfig file locations:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
macOS
spawn uvx ENOENTerror: Use the full path — find it withwhich uvx, then set"command": "/Users/you/.local/bin/uvx".
Claude Code
claude mcp add ultimate-gemini \
--env GEMINI_API_KEY=your-api-key \
-- uvx ultimate-gemini-mcp@latestCursor
Add to .cursor/mcp.json:
{
"mcpServers": {
"ultimate-gemini": {
"command": "uvx",
"args": ["ultimate-gemini-mcp@latest"],
"env": {
"GEMINI_API_KEY": "your-api-key-here"
}
}
}
}Images are saved to ~/gemini_images by default. Add "OUTPUT_DIR": "/your/path" to customize.
Tools
generate_image
Generate an image with Gemini 3.1 Flash Image.
Parameter | Type | Default | Description |
| string | required | Text description. Less is more — "Tony Hawk kickflip" beats a long description. The model with search can find references automatically. |
| string |
| One of: |
| string |
|
|
| string |
|
|
| list |
| Up to 14 local image paths (10 objects + 4 characters) |
| bool |
| USE THIS for products, people, events — anything that exists now. The model searches Google for real info. |
| bool |
| USE THIS for visual references. The model finds actual images to work from. This is huge — it can reference real photos of anyone/anything. |
| string |
|
|
| list |
|
|
| bool |
| Produce a transparent PNG/WebP cut-out via the two-pass difference matte (~2x cost; see below) |
| bool |
| Also keep the pass-1 (white-background) image, not just the cut-out |
| string |
| Alpha-capable output format: |
Image size guide:
512px— fastest, lowest cost (0.5K)1K— fast, good for testing (~1-2 MB)2K— recommended for most use cases (~3-5 MB)4K— maximum quality for production assets (~8-15 MB)
Transparent backgrounds — set one flag, get a real alpha cut-out
Just set transparent_background=true. You get back a ready-to-use transparent PNG/WebP (real alpha channel) at transparent_path — no manual masking, no second tool, no follow-up steps.
Generating an app icon or logo? Use the dedicated
generate_app_icontool instead — it forces square + transparent + 1024px PNG so the icon constraints can't be set wrong.
Under the hood this is a two-pass difference matte. The subject is rendered once on a pure white (#FFFFFF) background, that image is edited to a pure black (#000000) background, and the two frames are combined to solve for alpha per pixel: since obs_white − obs_black = (1−α)·255 on every channel, α = 1 − mean(obs_white − obs_black)/255, and the foreground colour is un-premultiplied from the black frame. Because there's no colour key, there's no green spill/halo; alpha is fractional, so soft edges, glow, glass, and faint shadows all survive. Pillow-only, zero ML downloads — but it costs a second model call (~2x tokens/latency).
The technique assumes the edit pass changed only the background. If the model drifts the subject between passes, the matte degrades — the result still returns (aligned/alignment_error flag it, with a loud post_processing_warnings entry) so you can decide whether to regenerate.
Each returned image gains: transparent_path, background_removed, background_removal_mode ("difference_matte"), aligned, alignment_error, alpha_output_format, and post_processing_warnings. By default the pass-1 (white-background) original is preserved alongside the cut-out (preserve_original=true).
// generate_image(prompt="a friendly robot mascot", transparent_background=true)
{
"images": [{
"path": "/path/to/a-friendly-robot-mascot-...png", // pass-1 (white bg)
"transparent_path": "/path/to/a-friendly-robot-mascot-...-transparent.png",
"background_removed": true,
"background_removal_mode": "difference_matte",
"aligned": true,
"alignment_error": 0.004,
"alpha_output_format": "png",
"post_processing_warnings": []
}]
}It nails crisp-edged subjects and soft glow/glass. The one failure mode is the edit pass drifting the subject (flagged via aligned: false) — regenerate if edges look ghosted.
generate_app_icon
Purpose-built for app icons and logos. Square, transparent, and 1024px are forced — there is no aspect_ratio, image_size, output_format, or transparent_background knob to get wrong. Every result is a real alpha-channel PNG at transparent_path, ready to drop into a .iconset directory and convert with iconutil -c icns.
Parameter | Type | Default | Description |
| string | required | Describe the icon/logo mark only — framing & transparency are handled |
| str | list |
| Brand/style reference image path(s), up to 14 |
| bool |
| Ground design in real web references |
| bool |
| Use Google Image Search for visual context |
| string |
|
|
| bool |
| Escape hatch — bypass the prompt guard only when a word like "logo" is genuinely part of the subject |
The
promptmust describe ONLY the subject, never the deliverable. This tool already turns whatever you describe into an icon, so framing words like "app icon", "logo", "favicon", or "squircle" in the prompt are rejected (setallow_icon_words_in_prompt=trueonly if such a word is literally part of the depicted subject). Right:"a glowing electric-blue magnifying glass over a network graph". Wrong:"an app icon of a magnifying glass".
// generate_app_icon(prompt="a glowing electric-blue magnifying glass over a network graph")
{
"images": [{
"transparent_path": "/path/to/...-transparent.png", // square, 1024px, alpha
"background_removed": true,
"alpha_output_format": "png"
}]
}batch_generate
Generate multiple images in parallel.
Parameter | Type | Default | Description |
| list | required | List of prompt strings (max 8) |
| string |
| Aspect ratio applied to all images |
| string |
| Resolution for all images |
| string |
| Format for all images |
| list |
| Modalities for all images |
| int |
| Max concurrent requests |
| bool |
| Use Google Image Search for visual context |
| string |
|
|
| bool |
| Apply the two-pass difference matte to every image (each costs a second model call) |
| bool |
| Keep the pass-1 (white-background) images too |
| string |
| Transparent output format: |
MCP Prompt Templates
26 expert prompt templates are available as MCP slash commands in Claude Code (type / to browse). Each template returns a crafted prompt and recommended parameters ready to pass directly to generate_image or batch_generate. For app icons and logos, use the dedicated generate_app_icon tool instead.
Command | Description | Default aspect ratio |
| Photorealistic shot with lens/lighting specs | 16:9 |
| Film still with cinematography language | 21:9 |
| Commercial e-commerce photography | 1:1 or 4:5 |
| Multi-scene storyboard → calls | 16:9 |
| Extreme macro with micro-snoot lighting | 1:1 |
| Editorial fashion with gobo shadow patterns | 4:5 |
| Stephen Biesty-style cutaway diagram | 3:2, 4K, IMAGE only |
| Overhead knolling photography | 1:1 |
| High-speed strobe with motion blur background | 16:9 |
| Moody night street with practical light sources | 16:9 |
| Straight-down golden hour aerial | 4:5, 4K, IMAGE only |
| UE5-style render with subsurface scattering | 1:1, IMAGE only |
| Scanning electron microscope false-color | 1:1, IMAGE only |
| Silhouette-blended double exposure | 2:3, IMAGE only |
| Ray-traced architectural visualization | 3:2, 4K |
| Orthographic isometric 3D illustration | 1:1, IMAGE only |
| High-end backlit food photography | 4:5 |
| Rear-curtain sync slow shutter sequence | 16:9 |
| Text embedded in physical environment | 16:9, 4K, IMAGE only |
| 1970s cassette-futurism analog sci-fi | 4:3, IMAGE only |
| Surrealist impossible physics scene | 1:1, IMAGE only |
| Video game character concept art sheet | 3:2, 4K, IMAGE only |
| Seamless PBR texture map with raking light | 1:1, IMAGE only |
| Period-accurate photography with film emulation | 4:5 |
| Long-exposure bioluminescence macro | 1:1 |
| Cinematic pure-black silhouette master shot | 21:9, 4K |
Configuration
Variable | Default | Description |
| — | Required. Google Gemini API key |
|
| Directory where images are saved |
|
| Default resolution ( |
|
| Default model |
|
| Auto-enhance prompts by default |
|
| Enable Google Search grounding by default |
|
| API timeout in seconds |
|
| Max parallel requests in batch mode |
|
| Logging level |
Troubleshooting
spawn uvx ENOENT — Claude Desktop can't find uvx. Use the full path:
"command": "/Users/yourusername/.local/bin/uvx"Find it with: which uvx
GEMINI_API_KEY not found — Set the key in your MCP config env block or in a .env file. Get a free key at Google AI Studio.
Content blocked by safety filters — Rephrase the prompt to avoid sensitive content.
Rate limit exceeded — Wait and retry, or upgrade your API quota.
Images not saving — Check OUTPUT_DIR exists and is writable: mkdir -p /your/output/path.
License
MIT — see LICENSE for details.
Links
Google AI Studio — Get your API key
Available Tools
3 toolsbatch_generateA
Generate multiple images from a list of prompts efficiently.
Processes prompts in parallel batches for optimal performance. All images share the same generation settings.
| Name | Required | Description | Default |
|---|---|---|---|
| prompts | Yes | List of text descriptions for image generation | |
| batch_size | No | Parallel batch size (default: from config) | |
| image_size | No | Image resolution for all images (default: 2K) | 2K |
| aspect_ratio | No | Aspect ratio for all images (default: 1:1) | 1:1 |
| output_format | No | Image format for all images (default: png) | png |
| thinking_level | No | Thinking level - "minimal" or "high" | minimal |
| preserve_original | No | ||
| alpha_output_format | No | png | |
| enable_image_search | No | Enable Google Image Search | |
| response_modalities | No | Response types (TEXT, IMAGE) | |
| enable_google_search | No | Enable Google Web Search grounding | |
| reference_image_paths | No | Shared reference image path(s), up to 14. | |
| transparent_background | No | Set True to get ready-to-use transparent PNG/WebP cut-outs for EVERY prompt via the two-pass difference matte (each prompt costs a second edit-to-black model call). The alpha file for each image is returned as "transparent_path"; pick the alpha format with alpha_output_format ("png"/"webp"). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must bear full responsibility for behavioral disclosure. It mentions parallel processing and shared settings but lacks details on failure modes, rate limits, memory usage, or specific model behaviors. The transparent_background parameter includes some cost context, but the main description is insufficient.
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 contains three concise sentences that front-load the purpose and key feature (parallel processing). No extraneous information is present.
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 the tool's complexity (13 parameters, batch processing), the description provides a high-level overview but lacks details on output structure, error handling, or limitations. The presence of an output schema partially compensates, but more context about batch behavior and performance trade-offs would improve completeness.
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 schema already covers 85% of parameters with descriptions. The main description adds no extra semantic value beyond stating that all images share the same settings. The parameter descriptions themselves are detailed, particularly for transparent_background, so the description does not significantly enhance understanding.
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's function: generating multiple images from a list of prompts efficiently in parallel batches. It explicitly differentiates from siblings like generate_image and generate_app_icon by emphasizing batch processing and shared settings.
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 batch generation with shared settings but does not explicitly state when to use this tool versus alternatives or when not to use it. The sibling names provide some context, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_app_iconA
═══════════════════════════════════════════════════════════════════════════════ 🍏 APP ICON & LOGO GENERATOR (square · transparent · ready for .iconset) ═══════════════════════════════════════════════════════════════════════════════
Use THIS tool — not generate_image — whenever the user asks for an app icon, application icon, .icns, .iconset, macOS/iOS/Android icon, favicon, logo, logomark, or brand mark. It is purpose-built for that job and removes every way to get it wrong.
🔒 WHAT IS FORCED (you cannot override these — by design): ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ • TRANSPARENT background — ALWAYS. Every result is a real alpha-channel PNG cut-out. There is no opaque-background option, because an icon or logo with a baked-in rectangle behind it is wrong. The transparent file path comes back as "transparent_path". • 1:1 SQUARE — ALWAYS. Every app icon is square; there is no aspect-ratio knob to get wrong. • 1K (1024px) — ALWAYS. This is the master size every .iconset slice and store listing is downscaled from. • PNG — ALWAYS. The lossless alpha format icons ship in. • CUT-OUT ONLY — ALWAYS. Only the transparent PNG is written; the pass-1 (white-background) original is never kept.
⛔ HOW TO WRITE THE PROMPT (READ THIS — the tool enforces it):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
This tool IS the app-icon maker. Your prompt must describe ONLY the
subject/artwork — NOTHING about the deliverable. Do NOT write "app icon",
"application icon", "make an icon of", "logo of", "squircle", or anything
about output/format/shape. The tool turns your subject INTO the icon.
WRONG: "an app icon of a blue magnifying glass over a network" RIGHT: "a glowing electric-blue magnifying glass over a network graph"
If your prompt contains "app icon", "logo", "favicon", "squircle" (or similar framing), the tool will REJECT the call and make you rewrite it. Just describe the picture.
The ONLY exception is when one of those words is genuinely PART OF THE SUBJECT you are depicting — e.g. a neon sign that literally reads "LOGO", or a picture OF a favicon. In that rare case, set allow_icon_words_in_prompt=True to bypass the check. Do NOT use it just to sneak deliverable-framing past the guard.
📋 PARAMETERS (what you DO control): ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ► prompt (required, str): Describe ONLY the subject/artwork itself — see the rule above. Don't ask for a background, a rectangle, a drop shadow, or a presentation surface. A bold, simple, single focal form reads best at small sizes.
► reference_image_paths (optional, str | list[str]): Brand/style reference image path(s), up to 14 (e.g. an existing logomark or palette to stay consistent with).
► enable_google_search / enable_image_search (optional, bool): Ground the design in real brand/product references found on the web.
► thinking_level (optional, str, default: "high"): "minimal" or "high". Defaults to "high" — icons reward the extra composition reasoning.
► allow_icon_words_in_prompt (optional, bool, default: False): Escape hatch for the prompt guard. Leave False. Set True ONLY when a word like "logo"/"favicon" is literally part of the subject you are depicting (e.g. a neon sign reading "LOGO"), not framing of the deliverable. Misusing this to bypass the guard defeats the point.
📤 RESULT / NEXT STEPS:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Use result["images"][0]["transparent_path"] — that is the square,
transparent 1024px PNG. Tell the user the exact path and open it in the
native OS viewer (macOS: open "<path>"). To ship a macOS app, drop it
into a .iconset directory and run iconutil -c icns <name>.iconset.
For an iOS App Store upload, flatten onto an opaque background first
(Apple rejects icons that contain an alpha channel).
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| thinking_level | No | high | |
| enable_image_search | No | ||
| enable_google_search | No | ||
| reference_image_paths | No | ||
| allow_icon_words_in_prompt | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It thoroughly explains forced behaviors: transparent background, square aspect ratio, 1K resolution, PNG format, and cut-out only. It also describes the prompt guard and its exception. However, it lacks mention of authentication, rate limits, or side effects beyond file creation. For a generation tool, the disclosed traits are comprehensive, earning a 4.
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 sections, emojis, and clear formatting. It front-loads the purpose and forced settings. However, it is quite verbose and could be trimmed; some information is repeated (e.g., the prompt rule is emphasized multiple times). Still, the organization aids readability and earns a 4.
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 the tool's complexity (6 parameters, 1 required, output schema exists), the description covers all aspects: purpose, usage guidelines, prompt rules, parameter details, result format, and next steps (open in viewer, convert to .icns, etc.). It leaves little ambiguity, making it highly 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 0%, so the description must fully explain parameters. It does so with a dedicated '📋 PARAMETERS' section that details each parameter's purpose, constraints, and defaults (e.g., prompt must avoid icon-related words, reference_image_paths up to 14, thinking_level options). This adds significant meaning beyond the bare 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's purpose: generating app icons and logos. It explicitly distinguishes from the sibling tool generate_image by saying 'Use THIS tool — not generate_image — whenever the user asks for an app icon, application icon, .icns, etc.' This provides a specific verb+resource and sets it apart from alternatives.
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 gives explicit guidance on when to use this tool vs generate_image, including a list of use cases. It also provides clear rules for writing prompts (what to include and avoid), and explains when to use the escape hatch for allow_icon_words_in_prompt. This covers both when to use and when not to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_imageA
═══════════════════════════════════════════════════════════════════════════════ 🎨 GEMINI 3.1 FLASH IMAGE GENERATION ═══════════════════════════════════════════════════════════════════════════════
Supports: • Gemini 3.1 Flash Image (Nano Banana 2) - Fast, high-volume, 512px-4K
🌟 KEY CAPABILITIES: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ✓ High-Resolution Output: 512px, 1K, 2K, 4K ✓ Advanced Text Rendering: Legible text in infographics, diagrams, menus ✓ Reference Images: Up to 14 images (10 objects, 4 characters) ✓ Grounding: Google Web Search & Image Search ✓ Thinking Mode: Configurable reasoning (minimal or high) ✓ Transparent Backgrounds: one flag → ready-to-use alpha PNG/WebP cut-outs. See below — it just works. ✓ SynthID Watermarking: Invisible watermark on all images
🚀 WHY GEMINI 3.1 FLASH IS DIFFERENT: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ This isn't your old image generator. Gemini 3.1 Flash has LIVE ACCESS to Google Search and Image Search - it can find actual references for ANYTHING.
Examples: • "Way of Wade 12 latest colorway" → model finds the real shoe online • "Tony Hawk doing a kickflip" → model finds actual Tony Hawk photos • "iPhone 16 Pro Max" → generates the REAL device, not a guess • "Taylor Swift at the 2024 VMAs" → finds real reference images
Don't over-prompt! Simple descriptions work best. The model COOKS.
📋 PARAMETERS: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
► prompt (required, str): The text description. Be descriptive and specific. TIP: Less is more. "Tony Hawk kickflip" > "A man with long blonde hair wearing a skateboarding helmet doing a trick on a skateboard"
► enable_google_search (optional, bool, default: False): Enable Google Web Search for real-time data grounding. USE THIS FOR: Products, people, events, places, anything that exists NOW. The model will search for current info and generate ACCURATELY.
► enable_image_search (optional, bool, default: False): Enable Google Image Search for visual context. USE THIS FOR: Any visual reference - the model finds real images to work from. This is the "secret sauce" - it can reference actual photos of people, products, art, anything on the web.
► aspect_ratio (optional, str, default: "1:1"): OPTIONS: "1:1", "1:4", "1:8", "2:3", "3:2", "3:4", "4:1", "4:3", "4:5", "5:4", "8:1", "9:16", "16:9", "21:9"
► image_size (optional, str, default: "2K"): OPTIONS: "512px", "1K", "2K", "4K" • "512px": Fastest, lowest cost (0.5K) • "2K": Recommended balance
► output_format: "png" (default), "jpeg", "webp"
► reference_image_paths (optional, str | list[str]): Path(s) to up to 14 reference images (10 objects + 4 characters). Accepts either a single path string (e.g. "/path/to/ref.png") or a list of path strings (e.g. ["/a.png", "/b.png"]).
► thinking_level (optional, str, default: "minimal"): Controls reasoning effort: "minimal" (fast) or "high" (best quality, slower). PRO TIP: Use "high" when using Google/Image search for best results.
🧠 THINKING MODE: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Gemini 3.1 Flash uses reasoning to refine composition before generating. Use thinking_level to balance quality vs latency: • minimal: Fastest, basic prompts • high: Best quality for complex prompts, slower PRO TIP: Use "high" thinking when using Google/Image search for best results.
🪟 TRANSPARENT BACKGROUNDS — JUST SET transparent_background=True: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ✅ THIS WORKS GREAT. Set transparent_background=True and you get back a ready-to-use transparent PNG/WebP with a real alpha channel — no extra tools, no manual masking, no follow-up steps. Use it directly.
Behind the scenes this uses a TWO-PASS DIFFERENCE MATTE: the subject is rendered once on a pure WHITE background, then that image is edited to a pure BLACK background, and the two frames are combined to recover a true (fractional) alpha channel. This costs a second model call (≈2x tokens/latency) but gives materially better edges than color-keying — clean soft edges, glow, glass, and shadows, with no green halo. You don't prompt for transparency; you just ask for it.
► transparent_background (bool, default: False): Flip to True to get the transparent cut-out. That's the whole API.
► alpha_output_format (str, default: "png"): Alpha output format: "png" (default) or "webp".
► preserve_original (bool, default: True): Also keeps the pass-1 (white-background) image next to the cut-out; set False for just the transparent file.
Each image returns transparent_path (your alpha file) plus background_removed, aligned, alignment_error and post_processing_warnings so you can confirm the cut succeeded. It nails crisp-edged subjects and soft glow/glass; the one failure mode is the edit pass drifting the subject (flagged via aligned=false) — regenerate if the edges look ghosted.
📤 RESPONSE FORMAT: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Returns JSON with: { "success": true, "images": [ { "path": "/path/to/image.png", "size": 12345 } ], "metadata": { "thinking_level": "minimal", "grounding_metadata": {...} } }
⚠️ IMPORTANT - AI ASSISTANT INSTRUCTIONS: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Parse JSON to get file path: result["images"][0]["path"] (when transparent_background=True, use result["images"][0]["transparent_path"]).
Inform user of the EXACT file path.
Open image in native OS viewer using Bash:
macOS:
open "/path/to/image.png"Linux:
xdg-open "/path/to/image.png"Windows:
start "" "/path/to/image.png"
💡 Need a transparent cut-out? Don't hand-mask or reach for another tool — just call this tool with transparent_background=True and use the returned transparent_path. It's built for exactly that.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| image_size | No | 2K | |
| aspect_ratio | No | 1:1 | |
| output_format | No | png | |
| thinking_level | No | minimal | |
| preserve_original | No | ||
| alpha_output_format | No | png | |
| enable_image_search | No | ||
| response_modalities | No | ||
| enable_google_search | No | ||
| reference_image_paths | No | ||
| transparent_background | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: discloses thinking modes, transparent background mechanism with failure mode, watermarking, and cost implications. Very detailed and honest about behaviors.
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 very long and uses decorative elements. While all sentences add value, it is not concise. It is front-loaded but the length may hinder quick scanning.
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 the complexity (12 parameters, output schema), the description is complete: covers all parameters, behavior, return format, and even assistant instructions. The presence of output schema reduces need for return value detail.
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 0%, so description must compensate. It adds extensive meaning: tips for prompt, use cases for search parameters, detailed explanation of transparent_background with underlying process, and lists options for aspect_ratio, image_size, etc.
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 is a Gemini 3.1 Flash Image Generation tool, with specific capabilities listed. It distinguishes itself from siblings by focusing on single image generation with advanced features like search and transparency.
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 extensive when-to-use guidance, such as using simple prompts, when to enable Google/Image search, and using high thinking level for best results. Lacks explicit when-not-to-use guidance but is still very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v6.0.19- First observed
batch_generate - First observed
generate_app_icon - First observed
generate_image
TDQS
Scored across 3 tools
The three tools have distinct purposes: batch_generate handles multiple prompts, generate_app_icon is specialized for app icons with forced constraints, and generate_image is general-purpose. However, generate_image can also produce transparent backgrounds and resize, creating some overlap with generate_app_icon, though extensive descriptions and guardrails mitigate confusion.
All tool names follow a consistent verb_noun pattern: batch_generate, generate_app_icon, generate_image. This makes it predictable for an agent to understand the action and target resource.
With 3 tools, the set is well-scoped for image generation: a general generator, a specialized icon generator, and a batch variant. No excessive bloat or deficiency.
The tools cover core image generation needs: single, batch, and icon-specific. Missing features like image editing, variation, or style transfer are minor gaps that do not severely hinder the domain, but agents might need workarounds.
Maintenance
Related MCP Connectors
MCP server for Qwen Image 3 AI image generation
MCP server for Google Veo AI video generation
MCP server for MiniMax H3 multimodal video generation
MCP server for Grok Imagine AI video generation
Related MCP Servers
- AlicenseAqualityFmaintenanceProduction-grade MCP server for image and video understanding and generation across Gemini, OpenAI, and Grok.5564 PyPI4Apache 2.0
- AlicenseCqualityDmaintenanceMCP server for generating and editing images through Polza AI using Google Gemini models (Nano Banana 2, Pro, Flash). It supports conditioning with up to three reference images and provides structured metadata with reproducibility hints.51MIT
- AlicenseAqualityDmaintenanceMCP server for Google Gemini image generation with configurable model support, enabling text-to-image generation, image editing, and iterative refinement.640MIT
- FlicenseBqualityDmaintenanceA production-ready MCP server that enables Claude and other LLMs to generate images and videos using Google's Gemini AI models (Gemini 2.0 Flash and Veo 2.0).32-