likenessforge_repair

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

Beyond the annotations (which only declare non-readonly, open-world, non-idempotent, non-destructive), the description discloses that the call returns a retained background job rather than a finished artifact and names the polling tool, which is essential behavioral context. It also enumerates the effect classes (write, inference, download, network) and flags that some are conditional and discoverable via danceflow_component, usefully extending the permissions schema. It stops short of saying what happens on failure, how long jobs are retained, or that the model weights may be fetched at runtime beyond the effect flag list.

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, front-loaded sentences with no filler: the action, the return/async contract, and the effect profile. The effect list partially restates the permissions enum already in the schema, but it is cheap and signals which flags must be acknowledged, so it mostly earns its place.

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?

An output schema exists, so return-value documentation is not required, and the description correctly covers the asynchronous job contract and the effect model. For a tool with a nested arguments object of this size and a required permissions acknowledgement, however, it leaves too much unexplained — the bulk of tunable parameters and the mechanics of the permission gate remain undocumented.

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 50% and only one nested field (allow_downloads) carries an inline description, yet the description explains none of the roughly twenty sub-parameters (lora, seed, steps, guidance, feather, detector, segmenter, low_vram, references, crop_margin, etc.). It only hints at the face selector via "explicitly selected face", which is arguably in tension with that field's "largest" default, and says nothing about the required output or image paths.

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 pairs a specific verb ("Repair") with a bounded resource ("one explicitly selected face") and names the execution path ("the canonical workflow"), so an agent understands this is a targeted face-repair operation rather than a generic pipeline run. It does not, however, distinguish itself from the nearby sibling likenessforge_repair_wizard, leaving the agent to infer which of the two repair entry points is correct.

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 phrase "one explicitly selected face" implies a precondition (a face must be chosen), and pointing at danceflow_component for conditional effects is genuine routing guidance. But there is no statement of when to prefer this over likenessforge_repair_wizard, no prerequisites, and no guidance on the required permissions acknowledgement beyond an oblique hint.

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