OpenFlow vs Nanobanana MCP Server
A side-by-side look at the OpenFlow and Nanobanana MCP Server MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose OpenFlow for multimedia process work over a hosted endpoint; choose Nanobanana MCP Server for multimedia process as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose OpenFlow when
- You need dedicated capabilities in the Multimedia Process domain.
- You prefer a remote HTTP/SSE transport.
- You want tools like
generate_with_face, generate_image, music_generate.
Choose Nanobanana MCP Server when
- You need dedicated capabilities in the Multimedia Process domain.
- You prefer a local stdio subprocess transport.
- You have the keys it needs:
GEMINI_API_KEY, NANOBANANA_AUTH_METHOD, GCP_PROJECT_ID, GCP_REGION. - You want tools like
generate_image, upload_file, show_output_stats.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Multimedia Process | Multimedia Process |
| Quality signal | 60/100 · Good | 63/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Remote HTTP/SSE | Local subprocess (stdio) |
| Auth | Not declared | Not declared |
| Pricing | Not declared | Not declared |
| Required env vars | None listed | GEMINI_API_KEYNANOBANANA_AUTH_METHODGCP_PROJECT_IDGCP_REGION |
| Verified owner | Community listing | Community listing |
| GitHub stars | 9 | 402 |
| Directory activity | 1 views 0 installs 0 upvotes | 1 views 0 installs 0 upvotes |
| Tools | 51 | 4 |
| Full listing | View OpenFlow | View Nanobanana MCP Server |
Tools & capabilities
OpenFlow tools 51
generate_with_faceGenerate a NEW image of the SAME PERSON/character as an existing photo or portrait — dress them differently, move them somewhere else, make an avatar. This is the tool for "here is my photo, now put me in a suit / in a park", and also the ONLY tool for "generate another picture of <character I already made>". Pass exactly ONE of: character: the name you gave a character via create_character_from_description or create_character_from_photo(..., name=...). Looked up in your own list — see list_characters(). This is the normal way once a character has a name. photo_media_id: a mediaId directly (create_character_from_photo's `portrait_media_id`, or any earlier generate_image media_id) — for a one-off face you haven't registered as a named character. prompt: describe the NEW scene/outfit and say it is the same person, e.g. "the same man, now in a navy suit in a bright office". Why this and not entity_id/character_slot_index: a character's Flow CARD is not what carries resemblance into a NEW scene — the reference image itself does (verified live, repeatedly). Combining entity_id with an image reference in the same call also fails outright (HTTP 500). So this always generates from the reference image alone, never from entity_id — that is deliberate, not a workaround to fix later. project_id: put the result into a project made with create_project instead of the account's default one. photo_media_id itself stays account-bound, as always.generate_imageGenerate an image from a text prompt via Google Flow. model — pass ONE of these exact ids (from GET v1/flow/models, verified 2026-07-25): BELUGA = "Nano Banana 2" — the DEFAULT, ~30s (legacy id NARWHAL is accepted as an alias) GEM_PIX_2 = "Nano Banana Pro" — highest quality, ~40s, has a separate DAILY per-account quota (429 rotates accounts) HARBOR_SEAL = "Nano Banana 2 Lite" — ~40s Anything else is rejected with HTTP 400 — there is no silent fallback, so a wrong id wastes a round trip, not credits. Do NOT guess names like "nano_banana_pro": that is the model FAMILY key from the config, not the id the generate call takes. image_inputs: mediaIds from prior generations, edit-in-place (keeps them pixel-exact). control_images: up to 10 base64 image bytes (no data: prefix) of a locally rendered layout/control image — uploaded first, then prepended to image_inputs so the generator follows an exact spatial layout instead of prose. For whole-scene layout control prefer generate_scene. seed: 1..900000, fixes the generation so the same request returns the same image. Omit for a random seed. Needed to compare two prompts, two models or two control images honestly — without it every run is a fresh roll and the difference you are measuring drowns in noise. Measured 2026-08-09: with an UNCHANGED control image a fixed seed reproduces the frame to ~0.1%; once the control image changes, the seed no longer keeps the character — for that use image_inputs with a reference frame's mediaId. project_id: put the result into a project made with create_project instead of the account's default one — one project per end client keeps their work separate. Omit it and nothing changes from before. include_preview: ON by default since 2026-08-21 — a generated image nobody can see in the chat is half a result. Pass False to get the plain dict back and nothing else (worth doing in a loop of many generations, where the previews would fill the context). When on and the job finished with at least one url, the call returns the usual result dict, a short card naming the parameters actually used, and a small compressed JPEG (long side capped at 768px, ~100-160KB once base64-encoded) as an inline image content block, so a human can actually see the result without leaving the chat. This is deliberately a shrunk preview, never the original — the real Flow image is ~0.5MB (~740KB in base64), enough to burn a whole tool call's worth of a client's context budget on its own. The preview is for EYES ONLY: urls/media_ids stay the authoritative result in both modes, and every downstream call (upscale_image, image_inputs edit-in-place, ...) must keep using media_ids, never the preview bytes. If the preview download/shrink fails for any reason, this silently falls back to the plain (no-preview) result instead of failing the whole call. SAVE THE RESULT INTO THE USER'S PROJECT. A finished job also carries `download_urls` (plain URLs, no auth header needed) and `save_as` (the filenames to use). Unless the user said otherwise, write them to ./media/<save_as> in their working directory and tell them the path. The server keeps its own copy, but only the file in their project is theirs: our copy can be reclaimed when the disk fills, and the URLs expire within the hour. Downloading costs no credits and no quota. Returns {"urls": [...], "media_ids": [...]} when done, or a job_id to poll with check_job if it's not ready within ~60s (rare for images unless the device is cold). With the default include_preview=True and a finished result, returns [that dict, <card>, <inline image>] instead — see include_preview above.music_generateGenerate a full song from a text brief via Google Flow Music (Lyria). prompt — free text: genre, mood, BPM, instruments, and whether you want vocals or an instrumental (e.g. "dreamy synthwave, retro 80s, 110 bpm, instrumental"). The Producer agent turns it into a finished track (usually ~2-3 minutes, and it returns TWO variants). model — "lyria" (Lyria 3.5, the default flagship) or "lyria-pro" (Lyria 3 Pro, legacy). lyrics — optional explicit words to sing; omit for the model to write its own / stay instrumental. SAVE THE RESULT. Each returned clip carries a public `audio_url` (a Google Cloud Storage .m4a, no auth header needed) plus `download_path` on our server. Unless the user said otherwise, download the audio into their project. Fields per clip: clip_id, title, duration (seconds), lyrics, audio_url, wav_url, image_id (cover, feeds music_video), image_url. Returns {"clips": [...], "media": [...], "conversation_id": "..."} when done, or a job_id to poll with check_job if it isn't ready within ~90s. conversation_id — pass the one from an earlier result to keep working on the same track ("same song but 30 seconds shorter"); the Producer remembers what it just made. Omit it for a fresh start. Every result carries one, so a follow-up is always possible.music_chatTalk to the Google Flow Music Producer agent instead of one-shotting a track. Use this when the work is a conversation rather than a single brief: asking what it can do, having it write lyrics first, or editing a track it already made ("drop the vocals", "same song, 30 seconds shorter", "make the chorus bigger"). For a plain "make me a song about X", music_generate is the shorter path. message — what to say. conversation_id — omit on the first message, then pass the one that comes back so the Producer keeps its memory of the track. model — same choices as music_generate. Returns {"conversation_id", "text", "suggested_actions", "clips": [...], "media": [...]}. `text` is the Producer's reply. `suggested_actions` are the follow-ups it offers — show them to the user, they are good prompts for the next turn. `clips` is EMPTY when the Producer only talked, and filled when it decided to actually make audio; treat a filled `clips` exactly like a music_generate result and save the audio. A reply is usually seconds, but a turn that produces a song takes minutes and comes back as a job_id to poll with check_job.music_stemsSplit a track we generated into stems (vocals, instrumental, drums, bass, …). clip_id — the id of a clip returned by music_generate (or music_video's song). Runs on the same account that made the track. Returns {"stems": {name: "/v1/media/..."}, "media": [...]} when done, or a job_id to poll with check_job. Each stem is a downloadable .m4a on our server (public download_path). Save the ones you need into the user's project.music_listList the user's music tracks.music_getGet metadata for a single music track.music_downloadDownload the raw .m4a file of a track to the server.music_creditsCheck remaining flowmusic credits and subscription tier.generate_sceneBuild a location precisely from a scene-layout/v2 map and generate its plate. This is the "exact location building" path: instead of describing the room in prose (which the model reinterprets — furniture drifts, depths change between shots), it renders a control image from the map's boxes (each object a colored block at its true position/size/depth, plus a 1-meter floor grid in true perspective), then asks the generator to REPLACE each block with its real object in the same camera — so the plate follows the geometry pixel-wise. Same room from another camera_id is the same space. scene_layout: a scene-layout/v2 dict — {format, units, room{w,d,h}, objects{...boxes}, cameras{<id>:{pos,look_at,fov_deg,framing?}}, ...}. The camera must carry fov_deg. camera_id: which camera in scene_layout.cameras to render from. aspect: PORTRAIT (9:16), LANDSCAPE (16:9), SQUARE, PORTRAIT_THREE_FOUR (3:4) or LANDSCAPE_FOUR_THREE (4:3). 9:16 and 16:9 from one camera share the vertical FOV, so depths are identical across aspects. style / extra: prepended / appended prose (art style, mood) — geometry comes from the map. A box may carry `rot: [rx, ry, rz]` (degrees around the world X/Y/Z axes) and `pivot: [x, y, z]`, applied as p' = Rx·Ry·Rz·(p − pivot) + pivot, pivot defaulting to the box centre. That is how a POSE is expressed — a raised arm is a box rotated about the shoulder. Measured live 2026-08-09: moving a hand by 2–20 cm is ignored by the generator, rotating the arm by 15–60° comes through. Build motion out of angles. seed / image_inputs: same meaning as in generate_image. For a SEQUENCE of frames of one character, generate a reference frame first, then pass its mediaId as image_inputs on every following frame — that is what keeps the face, clothes and colours identical. A fixed seed alone does not: it only repeats an unchanged control image. depth: render the guide as a plain greyscale depth map instead of the colour hybrid (for an external depth-ControlNet). calibration: add frame markers, a back-wall grid and a 2 m ruler with 10 cm ticks — measured to cut the framing drift roughly fourfold. background: "dark" (default, unchanged) or "light". Use "light" when the plate must be on a white background: the generator sometimes copies the guide's own palette into the result, and a light guide makes that leak land as white rather than as a dark grid. control_png: return the layout guide itself, base64-encoded. OFF by default because it is hundreds of thousands of characters of TEXT — one guide can cost more context than the whole conversation around it. `control_png_kb` always reports its size. Returns {"urls", "media_ids", "legend", "control_png_kb"} — legend maps block colors to objects. Add control_png=True to also get the guide itself for inspection/acceptance.generate_videoGenerate a video from a text prompt via Google Flow (Veo models). video_model_key options: abra_t2v_4s (default, 7 credits), veo_3_1_t2v_lite (10cr, visibly cleaner), veo_3_1_t2v (100cr, "Quality" tier), veo_3_1_t2v_fast (20cr). project_id: put the clip into a project made with create_project instead of the account's default one — one project per end client keeps their work separate. Video generation routinely takes 1-3+ minutes, so this almost always returns a job_id rather than a finished result — call check_job with it, waiting a few seconds between checks, until status is 'done' or 'failed'. beats: how many DISTINCT action phases the prompt describes — "ears flick back", "tail lashes", "strikes the ball", "ball flies off" are four. Give it and the server picks the clip length for you (about two phases per second) and says in the reply what it picked and why. Measured 31.08.2026: the model STRETCHES whatever you describe over whatever length you ask for, so one phase in four seconds comes out as slow motion, and the same text at six seconds instead of four loses 15% of its movement. Adjectives are not phases: "springy cartoon motion" adds nothing. Leave beats out and the length you passed is used unchanged. seed (all video tools): the result always reports the seed it used. Same seed + same prompt + same inputs = the same clip, so a good take can be re-made. A fixed seed does NOT keep the composition when the prompt changes — use edit_video for that.edit_videoRewrite a video from a plain description: "make the sky stormy", "take the passer-by out of the shot", "warmer light", "put the product from the image on the table". Source — ONE of: media_id: id from a previous generate_video* result (OUR OWN generation). Job is pinned to the account that produced it. video_base64: base64-encoded YOUR OWN clip (mp4/mov/avi/3gp, up to 60s/1GB). Worker uploads it via Flow's Scotty resumable upload (reversed via Flow Web Ingredients, 2026-10-14) onto a healthy account, then runs the edit on that account. The upload itself costs no credits. start_sec / end_sec: edit only this piece of the source (both or neither, at most 10 s). The result is ONLY that piece — not the full clip with the piece replaced. reference_images_base64: up to 5 raw base64 images (no data: prefix); the object in the image is put into the clip — say in the prompt what to do with it. 20 credits per edit (abra_edit_360p: 10). Not a mask tool — describe the change and where it goes ("on the left", "in the sky"); mask/style image types are not honored. Prompt template that lands best — fill each part, one or two sentences each: Goal: what changes ("Replace the man on the left with the character from image 1"). Source: "The source video drives camera, motion, timing and lip movement." Reference: what to take from each image ("use only the character's look; ignore the image background"). Scene: describe the room/background in words (helps the model keep it intact). Keep: "Everything else stays exactly as in the source." Timing: "The new character inherits the exact movement and position of the one it replaces, from the first frame to the last." Draft on abra_edit_360p (10 credits) to check the edit lands, then run abra_edit; the seed does not carry an edit take across resolutions, so the final can differ in details. Only edit footage the user owns or is licensed to use; do not put real people's likeness into clips without their consent.- +39 more on the listing page
Nanobanana MCP Server tools 4
generate_imageGenerate 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. Multi-image conditioning: Provide up to 3 input images using input_image_path_1/2/3 parameters 3. File ID editing: Edit previously uploaded images using Files API ID 4. File path editing: Edit local images by providing single input image path 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.upload_fileUpload a local file through the Gemini Files API and return its URI & metadata. Useful when the image is larger than 20MB or reused across prompts.show_output_statsShow statistics about the output directory and recently generated images.maintenancePerform maintenance operations following workflows.md patterns. Available operations: - cleanup_expired: Remove expired Files API entries from database - cleanup_local: Clean old local files based on age/LRU - check_quota: Check Files API storage usage vs. ~20GB budget - database_hygiene: Clean up database inconsistencies - full_cleanup: Run all cleanup operations in sequence
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
OpenFlow
{
"mcpServers": {
"openflow": {
"url": "https://openflowmcp.com/mcp"
}
}
}
Nanobanana MCP Server
{
"mcpServers": {
"nanobanana-mcp-server": {
"command": "uvx",
"args": [
"nanobanana-mcp-server@latest"
],
"env": {
"GEMINI_API_KEY": "YOUR_GEMINI_API_KEY_HERE",
"NANOBANANA_AUTH_METHOD": "YOUR_NANOBANANA_AUTH_METHOD_HERE",
"GCP_PROJECT_ID": "YOUR_GCP_PROJECT_ID_HERE",
"GCP_REGION": "YOUR_GCP_REGION_HERE"
}
}
}
}
Frequently asked questions
OpenFlow is categorized under Multimedia Process and uses a remote HTTP/SSE transport. Nanobanana MCP Server belongs to Multimedia Process and uses a local stdio subprocess. Pick OpenFlow for multimedia process work and Nanobanana MCP Server for multimedia process.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
OpenFlow has no declared pricing — check the project's own site. Nanobanana MCP Server has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add openflow and nanobanana-mcp-server as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, OpenFlow has a quality signal of 60/100 (Good) with 1 views, 0 installs and 9 GitHub stars. Nanobanana MCP Server has 63/100 (Good) with 1 views, 0 installs and 402 GitHub stars.