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., "@Nano Banana 2 MCP Server what styles are available for image generation?"
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.
Nano Banana 2 - Nano Banana 2 AI Image Tool
A Model Context Protocol server that exposes the canonical Nano Banana 2 knowledge surface — image generation workflows and styles, pricing, FAQ, official links — to MCP-compatible AI clients such as Claude Desktop, Cursor, Windsurf, and Continue. Read-only, no API keys, no quota, ~50 ms cold start.
Official website: https://nanobanana-2.live
Nano Banana Pro is a web-based content creation platform that brings together image generation, video synthesis, and photo editing tools in a single interface. Powered by models including Google Gemini, Veo 3, Flux Pro, and Seedream, the platform lets users go from a text prompt or reference image to a finished visual asset — still or moving — without switching between separate tools. It supports over 100 languages, offers commercial usage rights on premium tiers, and provides API access for teams that want to integrate generation capabilities into their own workflows. The result is a general-purpose creative studio aimed at people who need production-ready output rather than just experimentation.
Related MCP server: Muse AI Image MCP Server
Multi-model image generation — access to Flux Pro, Flux Kontext, Flux Schnell Lora, Gemini, Qwen, and Seedream from a single prompt interface, with side-by-side model comparison available.
Veo 3 video synthesis — generate video clips up to 4K resolution at 60fps, with typical completion times of 30 to 90 seconds per clip.
Specialized editing tools — a suite of 13+ purpose-built tools covering canvas editing, background removal and replacement, hairstyle modification, product photography, 3D figure creation, and professional portrait enhancement.
Flexible export formats — images export as PNG, JPG, or WebP; videos export as MP4, with resolution scaling to suit web, print, or broadcast requirements.
Batch processing and API access — developers and studios can process multiple assets in parallel and integrate the platform's capabilities directly into external pipelines.
Team and enterprise options — shared workspaces, custom model training, and priority support for organizations with higher volume needs.
A social media manager needs a series of on-brand product images quickly and uses the product photography and background changer tools to generate consistent visuals from a few reference shots.
A digital artist wants to compare how Flux Pro and Gemini interpret the same prompt before committing to a style for a client project, using the side-by-side model evaluation feature.
A small video production team generates short promotional clips with Veo 3 for platforms like Instagram Reels or YouTube Shorts, exporting directly as MP4.
A developer building a content app integrates the platform's API to automate image generation as part of a larger publishing workflow.
A marketer running multilingual campaigns uses the 100+ language support to generate localized visual content and copy variations without maintaining separate tool accounts per region.
Nano Banana Pro is built for people who need reliable, production-quality visual output and want to reach it faster than traditional design or video production allows. The primary users are digital artists, content creators, social media managers, and marketing teams who generate visuals at scale. It also serves developers who want API access to generation models without managing their own model infrastructure. Enterprise teams benefit from the collaboration features and custom training options. The free tier makes it accessible for individuals testing ideas, while the premium plans are structured for professionals and studios with consistent output requirements.
list_stylesReturn the canonical list of image-generation styles or presets the site exposes. (Nano Banana 2)
Input: no parameters. Returns: text/markdown.
get_pricingReturn the canonical pricing entry point for Nano Banana 2.
Input: no parameters. Returns: text/markdown.
get_official_linksReturn the canonical list of official links for Nano Banana 2 (website, support, docs when available).
Input: no parameters. Returns: text/markdown.
site://nanobanana-2/styles — Supported image-generation styles and presets.
site://nanobanana-2/pricing — Canonical pricing entry point.
site://nanobanana-2/faq — Short FAQ generated from public site metadata.
site://nanobanana-2/links — Canonical URLs to share with users.
tell_me_about_nanobanana_2Summarize what the site is, who it's for, and how it works. — Nano Banana 2
try_image_style_nanobanana_2Recommend a starting image-generation style for a stated goal. — Nano Banana 2
npx -y @smithery/cli install nanobanana-2-mcp --client claude(Replace claude with cursor, windsurf, or continue for those clients.)
git clone https://github.com/rocnubie/nanobanana-2-mcp.git
cd nanobanana-2-mcp
pnpm installThen add to your MCP client config (claude_desktop_config.json for Claude Desktop, mcp.json for Cursor / Windsurf / Continue):
{
"mcpServers": {
"nanobanana-2-mcp": {
"command": "node",
"args": [
"/absolute/path/to/nanobanana-2-mcp/src/index.mjs"
]
}
}
}npx @modelcontextprotocol/inspector node src/index.mjsWebsite: https://nanobanana-2.live
Pricing: https://nanobanana-2.live/pricing
Support: support@nanobanana-2.live
pnpm install
pnpm start # run the server over stdioMIT
Return the canonical list of official links for Nano Banana 2 (website, support, docs when available).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It states 'return the canonical list' but does not disclose caching, freshness, or error behavior. Adequate for a simple retrieval 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?
Single sentence, no wasted words, front-loaded verb and resource.
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 parameters and no output schema, description sufficiently conveys what the tool returns. Could be more detailed about list format, but still complete enough to use.
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, so baseline is 4. Description adds no param info, but none needed.
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?
Describes specifically returning the canonical list of official links for Nano Banana 2, covering website, support, and docs. Clearly distinguishes from sibling tools list_styles and get_pricing.
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?
Usage is implied: when official links are needed. No explicit when-not-to or alternatives, but context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the canonical pricing entry point for Nano Banana 2.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It only says 'Return', lacking details on read-only nature, idempotency, authentication requirements, side effects, or output format.
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, focused sentence with no extraneous information. It is appropriately sized for a zero-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?
Given the tool's simplicity (no parameters, no output schema) and the context of sibling tools, the description sufficiently identifies the purpose. However, adding a note about what the entry point contains or its typical use 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 tool has zero parameters and schema coverage is 100%, so the description does not need to add parameter details. Baseline 4 applies as no value can be added 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 verb 'Return' and the specific resource 'canonical pricing entry point for Nano Banana 2', distinguishing it from siblings like 'list_styles' and 'get_official_links'. However, 'canonical pricing entry point' could be more explicit about what exactly is returned.
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 guidelines provided on when to use this tool versus its siblings. The description only states what it does, not when it should be preferred or avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the canonical list of image-generation styles or presets the site exposes. (Nano Banana 2)
| 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 only states the tool returns a list, without disclosing behavioral traits such as caching, rate limits, or whether the list is static/dynamic. The phrase '(Nano Banana 2)' adds no transparency.
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?
Single sentence that front-loads the action and resource. No wasted words; the version parenthetical is minor but doesn't detract.
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?
Tool is simple with no parameters or output schema. Description explains the purpose but leaves ambiguity about the structure of the returned list (e.g., includes ids, names, etc.). Adequate for a straightforward list retrieval but could be more precise.
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. Schema description coverage is 100% (empty), so the description need not add parameter info. 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 tool returns the canonical list of image-generation styles or presets, using a specific verb ('Return') and resource ('list of image-generation styles'). It is distinct from sibling tools get_pricing and get_official_links.
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 versus alternatives. While siblings are unrelated, the description lacks any contextual hints about appropriate use cases or prerequisites.
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.
v0.1.0get_official_linksget_pricinglist_stylesEach tool has a clearly distinct purpose: list_styles for image styles, get_pricing for pricing info, and get_official_links for official references. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern (list_styles, get_pricing, get_official_links), making it predictable for the agent.
With 3 tools, the count is on the lower end but still reasonable for a simple informational server serving static data. It is well-scoped to its purpose.
The tool set covers the essential static information (styles, pricing, links) for the server's domain. A minor gap might be the lack of a 'features' or 'about' tool, but agents can still function with the existing tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for NanoBanana AI image generation and editing
Public read-only MCP for SubcueAI: live pricing, latest desktop version, overview and FAQ.
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rocnubie/nanobanana-2-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
