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

With no annotations, the description carries the full burden, and it does disclose one valuable trait: 2K/4K are server-side upscales that 'can take a few minutes,' warning the agent about latency. It says nothing about where files are written, overwrite behavior, or failure modes, and notably omits what the call actually returns.

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

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

Two sentences, front-loaded with the operation, then the subordinate detail about size semantics. Nothing is padded and nothing is buried.

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

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

Parameters are well covered between schema and description, but this is a file-producing tool with no output schema, and the description never says what comes back (paths? file objects?) or how multiple media_ids are handled. A short return-value sentence would make it complete.

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

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

Schema coverage is 75% and the schema already explains project, media_ids, and output_dir, but the description adds genuine meaning for the size enum: 1K is the original file while 2K/4K are Flow-generated upscales. That distinguishes the values in a way the bare enum cannot.

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

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

The description states a specific verb and resource ('Download images from a Flow project by media id'), which cleanly separates it from the generate-oriented sibling flow_generate_images. It stops short of naming the siblings explicitly, but the operation is unambiguous.

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

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

Usage is only implied: the description's media-id reference plus the schema note that ids come from flow_generate_images hint at the generate-then-download workflow, but the description itself never says when to call this versus flow_status or flow_get_options, nor any preconditions.

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

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

With no annotations, the description carries the burden and mostly does: it discloses that the call is long-blocking ('wait until the images finish'), returns media ids, can download as a side effect, and self-aborts on credit cost. It omits prerequisites (Flow tab/session, auth) and what happens on timeout, which matters for a browser-driven mutation.

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

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

Three sentences, front-loaded with the action, followed by the return value and the two notable side effects. No filler; only the opening setting list slightly overlaps the later mentions.

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

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

For a 10-parameter, long-running generation tool with no output schema, the description covers workflow, return value, download side effect, and the credit guard. Gaps are the failure/timeout behavior and the fact that settings persist to the Flow session, but nothing essential to calling it correctly is missing.

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

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

Schema description coverage is 90%, so the schema already explains count, model, aspect_ratio, download_size, max_credits and dry_run. The description repeats the same fields (aspect ratio, model, count, download_size, max_credits) without adding syntax or semantics, and leaves timeout_sec and project entirely to the schema. Baseline 3 is appropriate.

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

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

Opens with a specific verb-plus-resource ('Set aspect ratio, model and number of images in Google Flow, submit the prompt, and wait until the images finish') and states the return value ('new media ids'). It is clearly distinct from flow_status and flow_get_options, though it doesn't explain its relationship to flow_download_images despite exposing an inline download option.

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

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

It gives two useful conditional hints: pass download_size to fetch results in the same call, and the tool refuses to run above max_credits. But it never routes the agent to alternatives — e.g. when to prefer dry_run, flow_get_options for previewing settings, or flow_download_images instead of the inline download.

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

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries the full burden and does disclose the key hidden behavior: it launches a Chrome window as a side effect on first use and depends on a Google sign-in in that window. It does not cover failure modes (Chrome missing, connection timeout) or whether the call blocks while the window opens, which keeps it short of a 5.

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

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

Two sentences with no waste: the side effect (window launch) is front-loaded, then the sequencing and conditional instruction. Every clause earns its place.

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

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

For a zero-parameter, no-output-schema status check, the description supplies the essentials an agent needs: the side effect of launching Chrome, the ordering constraint, and the meaning of the signedIn result with the follow-up action. Nothing critical for correct invocation is missing.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to add. The mention of the signedIn result field is a small bonus rather than parameter guidance.

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

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

States specific verbs and resources: it connects to the Flow Chrome window, launching it on first use, and reports sign-in status. That is clearly distinct from the sibling tools (get options, generate images, download images), so an agent can tell it is the prerequisite/setup check without opening any schema.

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

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

Explicitly says "Call this first", which establishes ordering relative to the siblings, and adds a branching instruction: if signedIn is false, ask the user to sign into Google in the Chrome window that opened. Both when to use it and what to do with the result are spelled out rather than inferred.

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