Skip to main content
Glama

List Flow image options

flow_get_options

Retrieves the image models, aspect ratios, and image counts currently available in Flow, plus the active selection, so you can pass exact values to image generation.

Instructions

Read the image models, aspect ratios and image counts Flow currently offers this account, plus the current selection. Values are read live from the UI; use them verbatim in flow_generate_images.

Input Schema

NameRequiredDescriptionDefault
projectNoWhich Flow project to use: "default" (a project this server created and reuses), "new", "current" (whatever the Flow tab shows), or a https://flow.google.com/project/<id> URL.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does disclose key traits: values are read live from the UI, are account-specific, and are volatile enough that they must be passed verbatim. It does not mention auth/session requirements or failure behavior if the Flow tab is unavailable, which is the main remaining gap.

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?

Two sentences, zero filler, and the payload contents are front-loaded before the usage instruction. Nothing redundant with the title or schema.

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?

There is no output schema, so the description must convey return contents, and it does by listing the four pieces of data returned. It could go one step further on the shape of the selection field, but an agent has enough to call and use it correctly.

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 100% and the single optional project parameter is fully documented in the schema with its enum-like accepted values (default/new/current/URL). The description adds nothing about project selection, so the baseline of 3 applies.

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?

Names a specific verb (read) and enumerates the exact resource contents: image models, aspect ratios, image counts, and the current selection, all account-scoped. The closing reference to flow_generate_images makes clear it is the companion lookup tool rather than a generator or a status check like flow_status.

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?

"use them verbatim in flow_generate_images" tells the agent this is the pre-flight read before generation and that values must not be constructed by hand. It stops short of explicitly stating it should be called before every generation or what happens if omitted, but the context for use is clear.

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