remask_image

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

No annotations are provided, so the description carries the full burden and does so: it states that nothing is uploaded, no model is called, no cost is incurred, and the work happens on this computer. It also discloses the hard prerequisites (requires an `edit_image` result made with `mask_path` on openrouter-image-mcp 0.2.0+, the sibling `<result>.unmasked.png`, and the original input still in place/unchanged), and the save behavior (PNG next to `image`, never overwriting, JSON sidecar, plus a JPEG preview in the result).

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 action and the routing decision, then prerequisites, then args; the structure is easy to scan. It is somewhat longer than necessary, repeating the free/offline/no-cost point in three separate places ("free and offline", "it costs nothing", "no model is called"), which is mild redundancy rather than 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 four-parameter tool with no annotations, no output schema, and 0% schema coverage, everything an agent needs is present: when to call it, prerequisites that will make it fail, path-format rules, side effects, and the shape of the returned result (saved path + JPEG preview).

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 0%, so the description must carry all four parameters — and it does. It defines `image` (masked `edit_image` or earlier `remask_image` result), the white/black semantics of `mask_path` plus that any size is stretched to the input, the default derivation of `mask_feather_px` from image size, and the `output_dir` override — all beyond the bare titles in the 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: re-doing the mask blend of a masked `edit_image` result with a new mask, locally and for free. It explicitly distinguishes itself from the sibling `edit_image` ("call this instead of paying for another `edit_image`"), so an agent can route between them without opening either 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?

Gives explicit when-to-use conditions (a masked edit that blends badly: a seam, a ghosted edge, a limb/shadow cut off at the mask edge, or a mask that should have been bigger/smaller) and names the alternative plus the reason to prefer this one (free, offline vs. paying for another `edit_image`). It also states prerequisites and that a re-masked result can itself be re-masked.

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