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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), lowering the burden on the description. The text adds the useful provenance fact that sources are local file paths rather than URLs, but says nothing about whether originals are modified, where results are written, or model/quality defaults.

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 tight sentences, front-loaded with the verb and resource, with the parenthetical examples earning their place. The trailing sentence on local file paths partially duplicates the images schema description, but overall there is no padding.

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 and the description never says what an edit returns or that output_path controls where the result lands. Combined with four undocumented parameters, an agent lacks enough context to invoke this confidently, especially around output handling.

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 only 43%: n, model, quality, and output_path carry no documentation anywhere. The description partially compensates for images and prompt semantics, but four of seven parameters remain entirely unexplained, so it does not meet the compensation burden for a low-coverage 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 ('Edit one or more existing images with a prompt') and enumerates the edit modes (inpainting, restyle, object changes). The word 'existing' implicitly distinguishes it from generate_image, but it never names that sibling explicitly, so the differentiation is left for the agent to infer.

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 tool applies when you already have source images on local disk. Neither generate_image nor list_image_models is named, and there is no statement of when to prefer editing over generating, or of prerequisites such as source image format/size.

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?

Annotations only declare the safety profile (not read-only, not idempotent, not destructive). The description adds real behavioral context beyond that: generation is sequential, and there is a hard cap of 4 images per call — both relevant for latency and cost planning. It does not say what is produced (files vs. inline data) or how output_path interacts with multi-image calls, so not 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?

Three short sentences, front-loaded with what the tool does and then the parameter triage. Every clause carries information; nothing is redundant padding.

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, zero-required tool with no output schema, the description covers the key selection logic and the per-call cap. It leaves the return artifact unexplained (where images land, and how `output_path` behaves when several images are requested), which is the one gap an agent might hit.

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 86%, so the schema already documents almost every parameter including the `n`-ignored-when-`prompts` rule. The description restates the prompt/prompts/n triage in more readable form but adds no format, default, or constraint detail beyond 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?

States a specific verb and resource ("Generate images from text") and names the backend (WikiVibe), which is enough for an agent to place it against edit_image and list_image_models. It does not explicitly contrast itself with either sibling, so it stops short of a 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?

Gives explicit mode-selection guidance: `prompt` for one image, `prompts` for several distinct images, `n` for variations of the same prompt. That is genuine when-to-use-which-parameter routing. It offers no guidance about when to prefer this tool over edit_image, and no exclusions, so it is a solid 4 rather than a 5.

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?

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds one useful behavioral fact — results depend on the configured WikiVibe key — but says nothing about return shape, ordering, or whether the list can be empty for an unentitled key.

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 no filler, front-loading the action and resource before the scope qualifier. Nothing could be removed without losing 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?

For a zero-parameter, read-only tool with no output schema, the description covers what it does and the key scoping, but it never indicates what is returned (model identifiers/names) or that those values are meant to be fed to generate_image/edit_image — the one piece of context an agent actually needs.

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 per the baseline this dimension starts at 4. There is nothing for the description to disambiguate and it correctly makes no false claims about inputs.

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 ('List image-generation models') and adds a scope qualifier ('available to the configured WikiVibe key'). The listing verb naturally separates it from the action-oriented siblings generate_image and edit_image, though no sibling is named 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?

Usage is only implied: an agent would infer this is a discovery step before generate_image/edit_image. There is no explicit statement of when to call it, no prerequisites, and no mention of the alternatives it feeds into.

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