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

No annotations are provided, so the description carries the full burden. It states that tasks may be generation or edit and that concurrency is controllable, but omits the behavior that matters most for a batch tool: what happens on partial failure (does one bad task abort the rest?), result ordering/correlation to input tasks, and any cost or rate-limit implications.

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, zero waste, with the core purpose front-loaded and the generation-vs-edit distinction immediately after. Nothing is 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 batch tool with no annotations and no output schema, the description covers purpose but leaves out partial-failure behavior and how results map back to the input tasks—information an agent needs to call and interpret this correctly. Adequate but with real gaps.

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% and there are only 2 top-level parameters, so the schema already documents the task fields and the concurrency default of 3. The description adds only the notion of 'concurrency control,' no format or semantics beyond the schema—appropriate baseline of 3.

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+resource (generate or edit multiple images) and clearly scopes it to batching in a single call, which implicitly separates it from the singular generate_image/edit_image siblings. It does not name those siblings 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?

Usage is implied: use this when you have several image tasks to run together rather than one at a time. There is no explicit when-to-use/when-not statement, no guidance on when batch beats looping the single-image tools, and no mention of when the concurrency control matters.

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 behavioral burden. It discloses the return contents (total credits, usage, remaining balance), which is useful, and implies a safe read. However it says nothing about authentication requirements, rate limits, or whether the data is live/cached.

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?

One front-loaded sentence with an em-dash elaboration; no filler, no redundancy. Appropriate for the tool's simplicity.

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, but the description substitutes by naming the three values returned, and the zero-parameter schema needs no explanation. Auth/mutability details are the only real gaps, and those are minor for a read-only balance check.

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. There is no parameter syntax that requires explanation in the description.

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 (check) and resource (OpenRouter account balance), then enumerates the returned figures. An agent immediately knows what the tool does. It does not need sibling differentiation since the siblings (image generation tools) are unrelated, so a 4 rather than 5.

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 implied by the name and description — you call it to inspect account credit status. There is no explicit statement of when to use it, no prerequisites, and no alternatives named, but for a zero-argument read tool the intent is self-evident.

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 provided, so the description carries the full burden. It usefully discloses accepted input sources (local paths, URLs, data URIs) and prompt-expansion behavior, but says nothing about cost, whether the result is returned inline or written to disk, or what output_path does by default for a generative operation.

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 tightly written sentences that front-load the core action and then the prompt-quality tip. Every clause earns its place, with no redundant restatement of the tool name or schema fields.

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 7-parameter generation/edit tool with no annotations and no output schema, the description covers inputs but leaves the output contract and cost/behavior profile unstated. It is minimally adequate given the rich schema, but not fully 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 100%, so all seven parameters are already documented in the schema, including enums for style, image_size, and aspect_ratio. The description adds no parameter-level detail beyond this baseline, which is acceptable but unremarkable.

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 (edit/transform) and resource (existing images via text prompt and reference images). The word 'existing' implicitly distinguishes it from generate_image, though it never names that sibling explicitly.

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 real guidance on prompt preparation ('expand brief prompts... unless the user explicitly asked for a simple/minimal prompt'), which is useful operating advice. However, it offers no guidance on when to pick this tool over generate_image, batch_images, or how it relates to list_image_models/check_balance, so tool selection is left to inference.

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 provided, so the description carries the full behavioral burden. It discloses the OpenRouter backend and the meaning of the quality presets (cheap/quick vs best output), which is useful. But it omits cost implications, latency, rate limits, and whether the result is returned inline or only via output_path.

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, front-loaded with the core action and backend. The prompt-expansion caveat follows logically and is appropriately short.

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 an 8-parameter generation tool with no output schema, the definition should clarify what is returned (image bytes, URL, or a saved file path) and how output_path changes that. The model/preset relationship is covered, but this return-shape gap leaves the definition only adequate.

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 all 8 parameters are already documented in the schema, establishing a baseline of 3. The description adds one cross-parameter nuance (model overrides the quality preset) that the schema only hints at, but doesn't explain output_path behavior or aspect-ratio/size interaction.

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+resource (generate an image) plus the backend (OpenRouter), and distinguishes its two configuration paths (quality presets vs explicit model IDs). An agent can tell it apart from edit_image, batch_images, and list_image_models without opening a 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?

Offers concrete advice on when to expand a prompt and when not to (simple/minimal user request), which is real usage guidance. However, it says nothing about when to use this tool versus edit_image or batch_images, nor about cost/prerequisite conditions implied by check_balance being a 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?

No annotations are provided, so the description carries the full burden. It states what is listed but not whether results are cached, how fresh pricing data is, whether authentication is required, or if the list is paginated.

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 efficient sentence that front-loads the action and resource with no wasted words.

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?

Adequate for a simple read-only single-param tool, but with no annotations and no output schema, the description could reasonably say more about return shape or usage context.

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%, with the query parameter fully documented as a substring match. The description adds no parameter details, so baseline 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?

Clear verb+resource: lists image generation models, and specifies source (OpenRouter) and included data (pricing, capabilities). It distinguishes itself from siblings like generate_image by being a read-only catalog operation, though it does not explicitly name them.

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?

No guidance on when to use this versus alternatives or prerequisites. An agent could infer it's for discovering models before calling generate_image, but nothing is stated explicitly.

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