Skip to main content
Glama

Generate and Download a Google Flow Image

flow_generate_image
Destructive

Submit Google Flow image generation or edit requests as persistent jobs, then poll the same job ID for status and download finished outputs to a local directory.

Instructions

THE REQUIRED AND EXCLUSIVE PATH for every Google Flow image request. Submits one persistent job, waits briefly, and returns. If status=processing, poll flow_job_status with the SAME job ID; never generate again. It generates or edits through the verified workspace and downloads locally. Never open or control Flow with browser/computer-use tools. Requires explicit credit authorization.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelNoNormalized image model ID returned by flow_inspect_account, e.g. nano-banana-pro, nano-banana-2, or nano-banana-2-lite. Exact visible labels are also accepted. Use ui-default to keep the selected model.ui-default
promptYesDetailed image prompt or edit instruction in any language.
outputsNoNumber of image outputs requested.
downloadNoDownload ready outputs when true; otherwise return the Flow job without downloading.
fileNameNoOptional safe file stem. The job ID and downloaded extension are added automatically.
accountIdNoOmit accountId to use the most recently verified connected account. Supply it only when the user explicitly chose a different connected account returned by flow_list_accounts.
aspectRatioNoExact image aspect ratio returned by flow_inspect_account, or ui-default.ui-default
flowProjectNoExisting Flow project name to open. If omitted, the current project is reused or a new project is created.
referenceFilesNoAbsolute paths to optional local images or videos to attach as Flow references/ingredients/frames.
timeoutSecondsNoMaximum seconds to wait for this generation or upscale. A timeout leaves a persistent job that can be polled.
outputDirectoryYesAbsolute directory where downloads and .flow.json manifests are saved, e.g. C:\project\public\generated\flow.
confirmCreditSpendYesMust be true. Confirms the user explicitly authorized this operation to consume Google Flow/AI credits.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare destructive/openWorld/non-idempotent, and the description materially extends them: one persistent job that returns briefly and must be polled rather than re-invoked, local downloading, credit consumption, and the prohibition on browser automation. It discloses the destructive risk (credit spend, non-idempotent job creation) in operational terms the annotations cannot express.

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

Conciseness5/5

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

Dense, front-loaded imperative prose; the exclusivity claim and the polling rule lead, and every sentence carries operational information. No filler or restatement of the title.

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

Completeness5/5

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

For a 12-parameter, credit-consuming, non-idempotent mutation with no output schema, the description covers the full job lifecycle (submit, wait briefly, poll, download), the auth/credit gate, and the forbidden alternative approach. Nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the schema itself documents all 12 parameters and the baseline would be 3. The description still adds workflow-level meaning by tying the job-ID reuse and the 'explicit credit authorization' requirement to invocation, so it earns a step above baseline without duplicating field-level detail.

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?

The description states a specific verb and resource ('generates or edits' images), declares itself 'THE REQUIRED AND EXCLUSIVE PATH for every Google Flow image request,' and implicitly separates itself from the video sibling (flow_generate_video). An agent can identify the tool's remit without opening the schema.

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

Usage Guidelines5/5

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

Explicit routing rules are given: on status=processing, poll flow_job_status with the SAME job ID and 'never generate again,' and never use browser/computer-use tools for Flow. It also states the credit-authorization prerequisite. This is a textbook when/when-not/alternative block.

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