Skip to main content
Glama

gflow_generate_image

Generates 1-4 images from a text prompt using Google Flow image models, with configurable aspect ratios and saved asset references. Returns local file paths to the finished images.

Instructions

Generate an image using Google Flow's image models. Produces 1-4 images from a text prompt. Models: nano2 (Nano Banana 2.1, fast; 'nano2.1' also accepted), nano2-lite (Nano Banana 2 Lite), nano-pro (Nano Banana Pro), image4 (Imagen 4, no longer in Flow's menu). Aspects: 1:1, 9:16, 16:9, 4:3, 3:4. The prompt supports @AssetName mentions to tag saved project characters/assets by name (resolves to referenceEntities/referenceImages). Reference a SAVED named asset via @Name; reference an arbitrary one-off image via reference_images. See docs/REFERENCE_STRATEGIES.md. On accounts served from flow.google.com, use an existing project and local reference files. A character attaches there by name (@Name, or reference_entities paired with reference_entity_names); a UUID media reference the local catalog records in that same project is referenced in place (#995), but any other UUID, an entity id without a name, and image4 are not ported to that composer yet and fail before submit; retrying will not clear it. On an agent-only composer (#799) only text-to-image runs, so reference_images and character references fail there too. Returns local file paths to the generated images.

Input Schema

NameRequiredDescriptionDefault
waitNotrue (default): run the generation inside this call and return the finished result. The call stays open for the whole generation, minutes for a video, which can outlast an MCP client's tool timeout; raise that timeout for generation calls. false: only enqueue the job and return {status: 'pending', task_id} at once; the SEP-2663 Tasks extension's tasks/get reads its state by task_id. No gflow command runs the queue worker today, so a wait=false job is never generated: tasks/get reports it as 'working' indefinitely, and tasks/cancel clears it. Use the default.
countNo
modelNonano2
toolsNo
aspectNo1:1
outputNo
promptYes
profileNodefault
projectNo
ui_modeNo
instructionsNo
project_nameNo
reference_imagesNo
reference_entitiesNo
reference_entity_namesNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.90.0
    • addedInput schema / properties / wait / description
      Added value: +"true (default): run the generation inside this call and return the finished result. The call stays open for the whole generation, minutes for a video, which can outlast an MCP client's tool timeout; raise that timeout for generation calls. false: only enqueue the job and return {status: 'pending', task_id} at once; the SEP-2663 Tasks extension's tasks/get reads its state by task_id. No gflow command runs the queue worker today, so a wait=false job is never generated: tasks/get reports it as 'working' indefinitely, and tasks/cancel clears it. Use the default."
  2. Changed1 schema field changedv0.86.0
    • removedInput schema / properties / seed
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "integer"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "title": "Seed"
      -}
  3. First observed

TDQS

A4.2/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so: it discloses that image4 is no longer in Flow's menu, that unported reference types (arbitrary UUIDs, unnamed entity ids) 'fail before submit' and retrying won't help, and that only text-to-image runs on the agent-only composer. It also states the return value ('local file paths to the generated images') and warns origin/composer constraints that determine success.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded in the first two sentences, but the remainder is a dense run-on of parentheticals and bare issue numbers (#995, #799) that assume internal context. Most sentences earn their place, but the composer-mode discussion is heavier and more jargon-laden than an agent needs for a routine call.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-parameter, annotation-free generation tool with an output schema, the description covers the highest-risk failure modes and the reference strategy, which is what an agent most needs. It is still silent on profile selection, ui_mode, tools, and instructions, so an agent cannot confidently set those parameters from this text alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 7% across 15 parameters, so the description must compensate; it does well for prompt (@Name mentions), count (1-4), model (names plus the 'nano2.1' alias), aspect (enumerated ratios), reference_images, reference_entities/reference_entity_names, and project. It leaves tools, profile, ui_mode, instructions, and output undefined in both schema and description, which is a substantial residual gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ('Generate an image using Google Flow's image models') and states the output cardinality ('Produces 1-4 images from a text prompt'), which cleanly separates it from gflow_generate_video and gflow_upscale_image. The model and aspect enumerations further pin down scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete routing rules for the two reference mechanisms ('Reference a SAVED named asset via @Name; reference an arbitrary one-off image via reference_images') and states which account/composer configurations support references at all. It stops short of explicitly naming sibling tools to prefer for related tasks (video, upscale, model listing), so it is clear context rather than full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.