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

Annotations only declare readOnlyHint=false and openWorldHint=false, so the description carries most of the behavioral burden and does it well: it warns that the render is HOLISTIC and will also move skin/age/expression, maps denoising_strength bands to outcomes, and instructs the client to load the keeper's sidecar params. It omits cost/latency, determinism of seed, and return-format behavior, 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?

Front-loaded with the critical ⚠ HOLISTIC caveat before the Args block, and nearly every clause carries actionable information. The Google-style Args formatting is slightly awkward for a tool description and the deferred-args sentence is a bit hand-wavy, but there is little filler.

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 16-parameter tool with no output schema and thin annotations, the description covers the distinctive behavior and the two key parameters but leaves the bulk of the argument surface to be resolved via generate_image. An agent can call it correctly for the common case but must cross-reference another tool for anything beyond init_image/denoising_strength.

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?

With 16 parameters at 0% schema description coverage, the description documents only init_image and denoising_strength (with concrete 0.3-0.45 / 0.5-0.65 bands and the 0.45 default). The remaining 14 parameters, including the required prompt, are deferred wholesale to generate_image, which is a useful pointer but leaves most of the surface undocumented in place.

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/vary an image (img2img)") and scopes it precisely: whole-frame re-derivation, not single-feature fixes. It implicitly separates itself from generate_image by noting that tool covers "all other args" and by requiring an init_image, so an agent can route correctly between the two.

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?

Explicit when-to-use and when-not-to-use: use it for variants that should re-settle (wardrobe, pose, lighting, hair-mass), and NOT for single-feature fixes, which "belong in a PSD." It also gives a concrete workflow for character consistency (pass the canonical keeper as init_image plus its seed/prompt, change only the delta).

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?

Goes well beyond the annotations by disclosing return format (inline preview + params + full-res base64 PNG), model-switch behavior ('Switched only if different from loaded'), that the NSFW block is always appended, the VRAM-safe bucket constraint, and that the resolved seed is echoed back. These are genuinely useful behavioral facts an agent needs.

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?

Front-loaded with the core purpose and return info, then a well-structured Args block. It is long, but the length is justified by 14 parameters; a few entries (cfg/steps/sampler/scheduler) are thinner than others, keeping it just under a 5.

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 14-parameter local-generation tool with only minimal annotations and no output schema, the description covers purpose, all key parameter semantics, return values, and behavioral constraints. Nothing an agent needs to call it correctly appears to be 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?

With 0% schema description coverage and 14 parameters, the description carries the full burden and documents essentially all of them: prompt verbatim semantics with attention-weight syntax, shot enum-like values with dimensions, seed=-1 meaning and return, profile names, style presets, and the allowed width/height buckets. This compensates thoroughly for the empty 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?

The description states a specific verb and resource ('Generate an image (txt2img) on the local SDXL box'), which clearly separates it from the edit_image and list_models siblings. It stops short of explicitly naming and contrasting those siblings, so it lands just below 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?

Provides clear usage context for parameters — include_full=False for rapid iteration, seed=-1 for random vs. locking the echoed seed to reproduce, and the shot shortcuts. However, it never explicitly states when to use this tool versus the alternatives (edit_image, list_models), so it is not a full 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=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: it discloses what comes back (available checkpoints) and the loaded-state information, which matters with no output schema present.

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 resource and scope come first and the extra return detail follows immediately.

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 tool with no output schema, the description adequately covers what is returned and the state it reflects. It could add a note on cost/caching or output shape, but nothing essential to 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 there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter detail is required here.

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 the image models (checkpoints)') plus the environment ('on the Forge box') and an extra facet ('which one is loaded'). It is unambiguous against the generate_image/edit_image siblings, though it never explicitly contrasts itself with 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?

Usage is only implied: an agent would infer this is a discovery step before generating or editing images, but the description never says when to call it, nor names any alternative or prerequisite.

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