Germey

Posted on Oct 31 Originally published at platform.acedata.cloud

How to Add Image Generation to Gemini CLI with NanoBanana MCP

#ai #api #tutorial #devtools

When an image belongs in a prototype, issue comment, or README, the slow part is often not writing the prompt—it is breaking flow to open another app, move files around, and return to the terminal. A small MCP connection can make image generation available where you already work: inside a Gemini CLI conversation.

This guide shows a minimal, reproducible setup for connecting Gemini CLI to NanoBanana MCP. The result is a terminal assistant that can call a text-to-image tool or an image-editing tool when you ask for it.

What you can do

The NanoBanana MCP server exposes two tools to Gemini CLI:

Tool	Purpose
`nano_banana_generate`	Text-to-image generation using nano-banana, nano-banana 2, or nano-banana pro
`nano_banana_edit`	Image editing

That split is useful in everyday builder workflows. Use generation when a project needs a fresh hero illustration, product placeholder, or concept image. Use editing when there is already an image URL and the task is to change its visual treatment while preserving the subject.

The important idea is that Gemini CLI handles the conversation and tool selection; NanoBanana MCP supplies the image capability over a remote MCP endpoint. You do not need to implement a custom tool adapter in your own shell scripts just to test the workflow.

How the connection works

The server is available at this MCP endpoint:

https://nanobanana.mcp.acedata.cloud/mcp

Authentication is passed as an HTTP header using the Authorization field with a Bearer token. In other words, the connection configuration has three essential pieces:

a server name: nanobanana
an HTTP transport and the MCP URL
Authorization: Bearer yourToken

Keep the token out of source control. For a local experiment, replace yourToken only in your local CLI command or local Gemini settings file. If you share a configuration snippet with a teammate, leave the placeholder in place.

Option 1: Add the server from the terminal

If you prefer an explicit, copyable setup step, run the following command:

gemini mcp add nanobanana \
  --transport http \
  https://nanobanana.mcp.acedata.cloud/mcp \
  --header "Authorization: Bearer yourToken"

This registers a remote server named nanobanana. Start a new gemini session after adding it so the CLI reloads its configured MCP servers.

A quick way to verify the integration is to make the request concrete. For example:

Generate an orange cat in a spacesuit eating a hamburger on the moon with NanoBanana.

The wording matters less than the intent: name the tool when you want to make the call obvious, describe the subject, and include the important visual constraints. This is especially helpful during early testing, because it makes it clear which capability you expect the assistant to use.

Option 2: Commit the shape, not the secret

For teams that manage local tooling through configuration files, Gemini CLI can read the same connection details from ~/.gemini/settings.json:

{
  "mcpServers": {
    "nanobanana": {
      "httpUrl": "https://nanobanana.mcp.acedata.cloud/mcp",
      "headers": {
        "Authorization": "Bearer yourToken"
      }
    }
  }
}

The JSON field names are significant: httpUrl points Gemini CLI at the remote MCP server, while headers carries the authentication header. Use a user-level file for a personal setup, or inject the real token through your team’s normal secret-management practice rather than committing it to a repository.

After saving, open the next Gemini CLI session. At that point the server is available to the assistant as a tool provider, alongside whatever other MCP servers you have configured.

Choose generation versus editing deliberately

A useful habit is to decide whether you are creating pixels from scratch or transforming an existing image before you prompt.

For a new asset, give the assistant a compact brief with subject, lighting, composition, and style. For example:

Generate a product image: a steaming cup of coffee, backlit, on a wooden table, with a film texture.

That is a generation task, so nano_banana_generate is the appropriate tool.

For a source asset you already have, give its link and state the invariant you want to preserve:

Transform this portrait (link xxx) into an ink wash painting while retaining the character's features.

That is an editing task, so nano_banana_edit is the better fit. The preservation instruction is not incidental—it tells the assistant which visual property should survive the transformation.

A practical terminal loop

This setup works well when you treat image work as part of the same feedback loop as code. Draft a landing page in your editor, ask Gemini CLI for a supporting image, inspect the result in context, then refine the request with one change at a time: composition, material, lighting, or style.

Keeping requests focused also makes it easier to tell whether a problem belongs to the prompt or the integration. First prove that the server is reachable with a straightforward generation request. Then try an edit request with an image link. Only after both paths work should you fold the workflow into automation around a larger project.

For the exact endpoint, configuration, and tool list used here, see the NanoBanana MCP documentation. The practical payoff is modest but real: image generation and image editing become terminal-adjacent tools, instead of a separate context switch in the middle of building.

DEV Community