Renders labeled multi-panel contact sheets comparing 12 Reel styles or PixelForge presets on an image, so you can evaluate and select a style before conversion.
Renders a labeled multi-panel contact sheet comparing all 12 Reel styles or top PixelForge presets on an input image.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | presets | |
| input_path | Yes | ||
| tile_width | No | ||
| output_path | Yes | ||
| tile_height | No |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, and it says nothing about what the tool writes to output_path, whether an existing file is overwritten, what image format results, or whether rendering is read-only aside from the output file. It does convey that the result is a labeled multi-panel sheet, which is useful behavioral color, but the write/overwrite semantics for a rendering tool are left entirely unaddressed.
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 well-formed sentence with the verb and the distinguishing scope front-loaded; no filler or redundancy. Its compactness is close to ideal, even if some needed detail is missing rather than excess being present.
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?
With 5 undocumented parameters, no annotations, and no output schema, the description should do much more: explain the mode choice, tile sizing, and what lands at output_path. As written, an agent knows roughly what the tool produces but not enough to set parameters confidently.
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% across 5 parameters, so the description must compensate and largely does not. It hints at the mode enum ('Reel styles or top PixelForge presets') and that an input image is involved, but tile_width, tile_height, and output_path are never explained, and the mode values 'presets' vs 'reel_styles' are not mapped to their meanings.
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: 'Renders a labeled multi-panel contact sheet comparing all 12 Reel styles or top PixelForge presets on an input image.' That is far more concrete than a generic 'process image' and implicitly separates it from image_stylize_reel (this one compares many styles rather than applying one), though it never names that sibling or explicitly contrasts with it.
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 description never says when to reach for this over alternatives such as image_stylize_reel or palette_tool, nor any preconditions (image format, size limits, whether output_path must not exist). The comparison/preview use case is inferable from 'contact sheet' but is not stated as guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.