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

No annotations are provided, so the description bears the full disclosure burden. It establishes that this is a read-from-Flow/write-to-disk operation by naming out_file as required, but says nothing about overwrite behavior, error cases (missing media id), latency, or that 4k upscaling is paid — those details live only in the schema property text.

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?

A single front-loaded sentence with no filler; the core action and its optional behavior are both stated before any detail. Nothing superfluous is present.

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?

With six parameters, no annotations, and no output schema, the description is somewhat thin: it never states that the result is written to out_file on disk or what a successful call returns. The schema compensates for parameter-level meaning, but the absence of any behavioral disclosure leaves the definition only minimally 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 description coverage is 83%, so the schema already documents media_id, size, out_file, upscale, and background thoroughly. The description only adds the framing that cropping is 'optional' and targets an 'exact size', which slightly reinforces size/fit semantics but does not meaningfully extend what the schema says.

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 names a specific verb (download) and resource (an image that already exists in Flow) and scopes it to lookup by media id, which implicitly distinguishes it from generate_image. It does not name the sibling upscale_image, even though the schema exposes an 'upscale' parameter, leaving some ambiguity about which tool to pick for upscaling.

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?

"already exists in Flow by its media id" implies the image must be produced first (e.g. via generate_image) and that media_id is the selector, which is useful usage context. However, there is no explicit when-to-use/when-not statement and no guidance on choosing between this tool's 'upscale' option and the separate upscale_image sibling.

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 of behavioral disclosure. It reveals that the tool checks connection-related details and implies a read-only operation, but it does not describe side effects, error handling, or return format. It adds some context beyond a bare 'check status' but lacks deeper behavioral specifics.

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?

The description is concise: one sentence specifying the check and one giving usage guidance. It is front-loaded with the action and scope, with no redundant wording or unnecessary details.

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?

Given the simplicity (no params, no annotations) and lack of output schema, the description is somewhat complete but misses return value information. It tells the agent what is checked and when to call it, but it does not explain what the tool returns or how to interpret the result, which would be valuable since there is no output schema.

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 has zero parameters, and the input schema is empty. The baseline for 0 params is 4, and the description does not need to explain parameter semantics. It appropriately focuses on the tool's purpose rather than parameters.

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 clearly states the tool checks a connection to the Google Flow Chrome window, detailing specific aspects (signed-in session, account, open project, credit balance). This specific verb-resource combination distinguishes it from sibling tools like generate_image and download_image, which serve entirely different purposes.

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?

The description provides explicit guidance: 'Call this first when something fails.' This tells the agent when to use the tool, but it does not mention when not to use it or suggest alternative tools. Still, the clear directive covers a key usage scenario.

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 meaningful work: it discloses the queuing model, that all jobs share one Flow tab, that no extra tabs open, the 8-job ceiling, and that upscale applies globally. It leaves open what happens if one job fails mid-batch and whether partial results are returned, which matters for a batch 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?

Four short sentences, front-loaded with the core purpose, then the queuing mechanics, then limits. No filler; the capitalized DIFFERENT and SAME efficiently carry the key constraints.

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's note that 'everything is collected at the end' is doing necessary work, but it does not say what the return looks like (paths, per-job status, filenames). For a tool with a global option and per-job overrides, that is a modest gap rather than a fatal one.

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%, so the schema already documents every parameter including fit, format, out_dir, background and the per-job fields. The description adds one genuinely useful cross-parameter fact, that 'upscale applies to all' jobs rather than per job, and notes per-job independence for size, filename and reference images; otherwise it restates the schema.

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 a specific verb and resource (generate multiple prompts) and adds a distinguishing qualifier: 'several DIFFERENT prompts in one call' versus the single-prompt sibling. It never names generate_image explicitly, so the contrast with the sibling is inferred rather than stated.

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?

Gives clear context for when this tool is appropriate: multiple different prompts that should share one Flow tab and be queued rather than run sequentially. It stops short of explicit exclusions such as 'use generate_image for a single prompt' or guidance on when upscale_image should be called separately instead.

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 two valuable traits: images cost no credits and exact-size requests are achieved by native-ratio generation plus cropping. It omits important behavior for a write-to-disk tool: authentication requirements, whether existing files are overwritten, generation latency, failure modes, and what the tool 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?

Three short sentences, front-loaded with what the tool does and what it produces, followed by the most decision-relevant caveat (the crop behavior). No filler or repetition of schema content.

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 twelve-parameter tool with no output schema and no annotations, the description is thin at the edges: it does not say what is returned (file paths, a confirmation, a count), how out_dir/FLOW_OUTPUT_DIR behaves when missing, or how reference_images interact with prompt length limits. The core workflow is explained adequately, but an agent still has open questions before calling it.

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 already 100%, so the baseline is 3, but the description adds genuine cross-parameter meaning the schema does not: the interaction between size and aspect (closest native ratio is chosen automatically, then cropped). That is real interpretive value beyond the per-field descriptions, though it covers only two of twelve parameters.

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 a specific verb and resource ("Generate one or more images with Google Flow") plus the side effect ("save them to disk"), which clearly separates it from siblings like generate_video, upscale_image, and download_image. It stops short of naming any sibling explicitly, so differentiation is inferred rather than stated.

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 useful conditional guidance for the size parameter ("ask for an exact pixel size... generates at the closest native aspect ratio and crops") and a cost note. However, it never says when to prefer this over generate_batch, upscale_image, or download_image, and no prerequisites or exclusions are given.

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?

No annotations are supplied, so the description carries the full burden, and it does disclose the most consequential behavior: video consumes credits and a cost ceiling gates execution with a pre-generation refusal. It omits other traits an agent would want for a video job — expected latency/async behavior, what the response returns, and error handling after the quote passes.

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 short sentences, front-loaded with the purpose, then the credit risk, then the input shape — no filler. Capitalized emphasis on COSTS CREDITS and FLOW_MAX_COST is the only styling and it correctly flags the blocking information.

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?

With no annotations and no output schema, the description does the heavy lifting on the one risk that matters (credit spend and the refusal gate) and states the input modality and format choice. For a paid long-running generation tool, a note on where the result lands or that the call may be slow is the remaining gap.

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 100%, so the schema already documents all five parameters including the aspect enum, and the description only restates 'pick an aspect (16:9 or 9:16)'. It adds no meaning for out_dir, basename, or out_file, notably not how the extension in out_file interacts with format selection.

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?

Sentence one gives a specific verb (generate) plus resource (video) plus destination behavior (save to disk) and names the provider (Google Flow/Veo). Sentence three further narrows scope to text-to-video with an aspect choice, and the 'UNLIKE images' clause separates it from the sibling generate_image without the agent needing to open another 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?

It states a concrete precondition for invocation: the tool only runs when FLOW_MAX_COST is raised above the quoted cost, and otherwise refuses before generating — that is real when-to-use/when-it-will-fail guidance. It also implicitly routes image work elsewhere, though it never names generate_image or explains when a still image is preferable.

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?

No annotations are supplied, so the description must carry the behavioral load; "List" implies a safe read, which is the main trait disclosed. It does not mention pagination, result ordering, permissions, or size limits — meaningful gaps for a library listing that could be large.

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?

A single sentence with zero waste, front-loading the verb and resource before parenthetical clarifications of each category. Nothing is repeated or padded.

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 one-optional-parameter list tool with no output schema, the description covers what is returned and how each category is consumed downstream. The remaining gap is return-shape and pagination behavior, which is minor given the tool's simplicity.

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 enum parameter is fully documented in the schema, so the baseline applies. The description reinforces the meaning of the "uploaded" and "generated" categories by explaining what each contains, but adds no syntax or edge-case detail.

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 a specific verb ("List") and resource ("images in the Flow project library") and then enumerates the two content categories returned: uploads and generated images. It also implicitly differentiates from the download_image sibling by noting generated images are re-downloadable there rather than here.

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?

Gives concrete downstream context for the results — uploads can be reused via reference_library_names without re-uploading, generated images can be fetched with download_image by id. It stops short of explicit when-not-to-use or prerequisite guidance, but the usage intent 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 must carry the behavioral load: it does disclose the write side effect ('save it to disk') and a cost fact ('2K is free'). It omits whether an existing out_file is overwritten, what permissions or project state are required, and any failure behavior, leaving meaningful gaps for a mutation tool with zero annotation coverage.

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 short sentences with the operation, scope, and output front-loaded; '2K is free' is terse but earns its place by flagging cost. Slightly clipped phrasing ('2K is free.') reads as a fragment rather than a fully formed note, but nothing is wasted.

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 6-parameter tool with no annotations and no output schema, the description covers what it does, the prerequisite, and that results land on disk (partly compensating for the missing output schema). It still leaves the semantics of fit/size/background and any return value to the schema, which is adequate but not fully self-contained.

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 83%, so the schema already explains media_id, out_file, size, target, fit, and background in detail. The description only reinforces media_id ('by its media id') and the disk-output meaning of out_file; it adds nothing about the pricing/size/fit interplay that the schema itself documents. Baseline 3 applies when the schema does the heavy lifting.

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 a specific verb and resource ('Upscale an image'), scopes it to images already in the open Flow project, names the lookup key (media id), and states the outcome (saved to disk). It implicitly distinguishes itself from generate_image (new images) and download_image (fetching), though it never names a sibling outright.

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?

'Upscale an image that already exists in the open Flow project' implies a prerequisite (the media must already exist, presumably from generate_image), and '2K is free' gives a cost-based decision hint. There is no explicit when-not guidance, no mention of what to do if the media id is missing, and no routing to alternatives such as regenerating at higher resolution.

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