upscale_image

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.