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

There are no annotations, so the description carries the full behavioral burden, and it does disclose important traits: frames are added if needed, the source layer is hidden, clean removes specks and orphan pixels, and it returns a summary plus an onion-skin view. It stops short of stating overwrite/error behavior or permission requirements, but it is substantially more transparent than typical.

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?

The description is dense and front-loads the core operation before moving into motion sources and mechanics. It is long but largely justified by the 16-parameter tool, with little obvious filler, though the single-paragraph structure could be easier to scan.

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 complex 16-parameter mutation tool with no annotations and no output schema, the description gives useful behavioral and return-value context. Still, the missing semantics for required parameters path and rig, plus several optional parameters, leave it only partially complete for correct invocation.

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 explain all 16 parameters. It meaningfully covers preset values, strength, the keys structure, frames, ease options, feet pivot, clean, and out_layer, but it omits required path and rig structure as well as durations, flash_color, hide_source, start_frame, source_frame, and only alludes to source_layer.

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?

It states a specific verb and resource ('Pose a rigged character over several frames') and names the output target ('write them to out_layer'). That makes the operation clear, but it never explicitly distinguishes itself from likely siblings such as tween_poses or rig_preview, so it falls short of the strongest clarity level.

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 explains the two motion sources (preset vs. keys) and the available easing modes, which implies usage. However, it does not say when to choose animate_rig over siblings like tween_poses, rig_preview, or check_animation, and it gives no explicit when-not-to-use guidance.

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?

With no annotations, the description carries the full burden and does substantial work: atomic all-or-nothing save semantics, error messages that name the failing op, 1-based frame indexing, default layer targeting, and the notable 'pixels drawn past the canvas edge are kept in the cel, never clipped' trait. It does not state what path expects (file type, is the original overwritten, are backups made), which is a meaningful gap for a mutating tool on a file.

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?

It is long, but the length is earned by a 50+ op catalog, and the critical semantics (transactionality, frame indexing, dry_run) are front-loaded before the catalog. Minor waste exists in self-evident op names and stray formatting artifacts (e.g. the double space in 'frames? (hit flash)'), but nothing structurally misplaced.

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 complex multi-op mutation tool with no annotations and no output schema, the description supplies nearly everything an agent needs: op syntax, argument defaults, indexing conventions, and failure behavior. The remaining gaps — what path refers to and what a successful call returns — are small but real given the absence of an output schema.

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 coverage is 0%, yet the description fully specifies ops_list's item contract ({"op": name, ...arguments}) and documents dozens of per-op arguments with defaults and formats, plus dry_run's exact behavior. The one missing piece is 'path', which is never explained in text and is completely undocumented in the schema — the only thing keeping this from a 5.

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 opening sentence gives a specific verb and resource ('Run edit operations on a sprite') plus a scope qualifier ('as ONE transaction'), and the op catalog makes the boundary with read-only siblings like view/check_animation/lint obvious. It stops short of naming a sibling directly, so it is clear but not fully differentiated in-text.

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 implied through the transaction contract and the 'dry_run=true runs everything and reports, but saves nothing' hint, which is a real decision rule. However, there is no explicit when-not guidance and no named alternative (e.g. use sprite_new to create, export to write out), so an agent must infer when this is the right entry point versus sibling tools.

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?

With no annotations, the description carries the full burden. 'Without playing it' implies a non-destructive read and it discloses the report contents, which is useful. However, it never explicitly confirms read-only behavior, does not say whether it mutates state, and says nothing about failure modes (missing path, malformed animation).

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?

Dense and front-loaded: the core measurement list comes first, then the mode semantics. Every clause carries information, though the run-on enumeration of measurements sacrifices some scannability.

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?

The measured output fields are well described, which compensates for the missing output schema. But with 0% schema coverage and no annotations, four of five parameters remain undocumented, and nothing is said about error behavior or what `path`/`layer`/`frames` should contain.

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. The description thoroughly explains `kind` and its three modes, but leaves `tag`, `path`, `layer`, and `frames` entirely undefined in both schema and description. Only one of five parameters is given meaning.

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 ('Measure an animation without playing it') and enumerates the exact measurements produced (bounds, ground row, centroid, height, repeated frames, colour drift, spacing). It is clearly distinguishable from siblings like lint, compare, or find_glitches, though it never names those alternatives 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?

The kind values carry real usage context: 'loop' for walk/idle that must close, 'oneshot' for attack/hurt/death that may hold poses, 'scene' for multiple actors where it only reports. That tells the agent which mode to pick, but there is no guidance on when to reach for check_animation versus lint, find_glitches, or compare.

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?

With no annotations, the description carries the full burden; it does usefully disclose the computed outputs (master-colour share within a just-noticeable difference, missing colours, height/width drift). It omits whether the tool is read-only, how frames/layers are selected by default, and what form the results take.

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 dense sentences with the core action and metric list front-loaded; nothing is redundant or padded.

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 5-parameter tool with no output schema and zero schema descriptions, the definition explains what is measured but leaves frame/layer selection, the master_frame default of 1, and result formatting unexplained.

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 coverage is 0% across 5 parameters, so the description must compensate, and it only clarifies 'master' (accepting png or .aseprite). path, layer, frames, and especially master_frame receive no meaning beyond their bare titles.

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 (compare) and resource (every frame vs a master image) plus the exact metrics produced, so the intent is unmistakable. It does not, however, distinguish itself from the sibling tool 'compare', leaving the agent to infer the difference between a generic comparison and this identity check.

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 closing line 'The check that a character is still itself after animating' implies the use case well, but there is no explicit when-to-use/when-not guidance and no named alternative (e.g. 'compare' or 'check_animation') to route between.

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?

With no annotations, the description carries the full burden. It usefully discloses the return semantics (changed pixel count and the changed-box) and the interpretation of a zero result, but says nothing about read-only nature, permissions, or cost/limits.

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 core operation and return values, with zero 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?

No output schema exists, and the description does cover the return shape (count plus box), which is helpful. But for a 6-parameter tool with no annotation or schema documentation, leaving layer and region undefined is a real gap.

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 coverage is 0%, so the description must compensate. The parenthetical '(of one sprite, or of two files)' implicitly explains other_path versus a single path, but layer and region — two of the six parameters — get no mention at all.

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 (pixel difference) and resource (two frames) plus the two supported modes (one sprite's frames vs. two files) and what it returns. An agent can distinguish it from siblings like check_identity or find_glitches, though it never explicitly names those alternatives.

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: '0 changed pixels proves a part did not move' hints at a verification use case, but there is no explicit when-to-use/when-not guidance and no routing to alternatives such as read_pixels or check_identity.

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?

No annotations exist, so the description carries the full burden. It discloses real behavior: hidden and reference layers are omitted, the 'frames' kind requires {frame} in the output path, and gif supports transparency vs background, palettes, per-frame durations and looping. However it never mentions that overwriting existing files is off by default or what the tool returns, which matters for a file-writing tool.

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?

Dense but front-loaded: the format enumeration comes first and each clause adds a distinct constraint. The 'Export without Aseprite.' opener is slightly confusing on its own, and the single-run-on paragraph makes scanning harder than a short list would.

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, mutation-style tool with no annotations and no output schema, the description covers the highest-complexity options well but leaves several parameters (path, output, tag, scale, frames, overwrite) entirely implicit, so an agent still needs to guess at required-vs-optional semantics and file-clobbering behavior.

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 14 parameters, so the description must compensate. It does add meaning for kind, layers, layout/columns/padding, background, loop and hints at data_output via 'optional JSON frame data', but path, output, tag, scale, frames, and overwrite receive no explanation at all.

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?

Names a specific verb (export) and enumerates the output formats (gif, png, frames, sheet) with their distinguishing traits, so an agent can tell it apart from sibling tools like verify_with_aseprite or import_strip. It does not explicitly name a sibling alternative, keeping it out of the 5 tier.

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 opener 'Export without Aseprite' hints that it is the non-Aseprite export path, but there is no explicit statement of when to choose this tool over verify_with_aseprite, live_open, or the other siblings, and no prerequisites or exclusions are given.

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?

With no annotations, the description carries the full burden and does well: it discloses the output form (onion-skin, previous red / next blue, boxed and labelled), the comparison rules (neighbour frames, loop wrapping, master reference), and the defect taxonomy. It omits whether the tool writes files or is read-only, which is a real gap for side-effect awareness.

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 purpose and output form, then progressively more detail. The defect-kind enumeration is long but each term earns its place by defining a distinct class the agent will see in results.

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 analysis tool with no output schema, it explains the comparison model, master semantics, and the full glitch taxonomy so an agent can interpret results. Missing documentation of path/layer/frames and of read-vs-write behaviour keeps it from a 5.

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 coverage is 0%, so the description must compensate. It adds real meaning for loop (wraps round), master (default is the first frame), and master_frames (transition start/end keys whose content is design), but leaves path, layer, and frames entirely unexplained despite being callable parameters.

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 ('find what animating broke, frame by frame') with a clear notion of the artifact produced (an onion-skin problem view). It is easy to tell apart from abstract siblings like 'lint' or 'compare' from the description alone, though it never names those siblings to make the distinction explicit.

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?

'Run it after every animate/edit pass; fix until ok' gives a clear trigger and lifecycle. It does not, however, contrast itself with apparent neighbours such as check_animation or lint, so the agent must infer when this is preferred over them.

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?

With no annotations, the description carries the full burden, and it does disclose the applied transformations (shared cell size, palette lock, ground-line/axis alignment) and that it returns a preview rather than nothing. It does not say whether existing frames at those indices are overwritten, whether the import is undoable, or what happens if `master` is null and no reference sprite exists.

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 action and core behavior in one long sentence, followed by the one parameter default that most changes behavior. The `count:` fragment is terse but unambiguous, and no sentence is wasted.

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 10-parameter mutation-ish tool with no annotations and no output schema, the description is unusually complete on the mechanics (scaling, palette, alignment, frame count, preview return). The remaining gap is operational: layer targeting, frame duration/start index, and overwrite/undo semantics.

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 coverage is 0% across 10 parameters, so the description must compensate — and it does for roughly half: `cell` (defaults to master's height), `count` (defaults to splitting at transparent gaps), `align` (feet or centre), `master`, and `palette_lock` (locked to master's colours). Nothing is said about `path`, `image`, `layer` (default 'reference'), `duration_ms`, or `start_frame`, which materially affect the import but are invisible to the agent.

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: bringing a strip of poses into a sprite as frames, with the key transformation (pixelized, palette-locked, aligned to master) named inline. It is clearly distinct from siblings like pixelize or animate_rig, 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 implied rather than stated: the repeated reference to 'the master's scale/colours/ground line' tells the agent this belongs downstream of a master sprite, and 'drawn by hand or generated' hints at acceptable sources. There is no explicit when-to-use, when-not-to-use, or named alternative among the many sibling tools.

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?

With no annotations at all, the description carries the full burden. It discloses the diagnostic categories and that results carry coordinates, which is useful, but never states that it is a read-only/no-mutation operation, what the return payload looks like, or how it behaves on a path that doesn't resolve to a sprite.

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 dense sentences with no filler; the output (coordinates plus findings) is front-loaded ahead of the scoping advice. The opening clause "Find what is easy to miss" is slightly rhetorical, but it earns its place by framing the tool.

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?

Given a three-parameter tool with no annotations and no output schema, the description covers the detection categories and the layer/frame choice but leaves the return shape, the meaning of `path`, and the read-only nature unspecified. Adequate to invoke, incomplete for confident use.

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 coverage is 0%, so the description must compensate and it only partly does: the layer-versus-frame relationship is explained in real terms (a layer lints one object, the flattened frame lints everything composited). The required `path` parameter and the numeric frame index (default 1) are left entirely unexplained by both schema and description.

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 concrete verb-and-resource: it finds pixel-art anomalies and reports them with coordinates, then enumerates the specific checks (orphan pixels, lone pixels, detached parts, colour count, darkest colour share, out-of-canvas pixels). An agent knows exactly what it gets back conceptually. It does not differentiate itself from close siblings such as find_glitches or check_identity, 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?

"Use a layer for one object; the flattened frame touches everything else" tells the agent how to scope the call, which is genuine guidance. But there is no when-to-use-versus-siblings statement, no exclusion, and no prerequisites, so usage is only implied.

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?

With no annotations, the description carries the full burden and does reasonably well: it discloses that the viewer is local-only, that it returns a URL to open in the browser pane, that a `path` argument will open that specific file, and that user actions in the viewer produce review notes as a side effect. It stops short of stating whether the call blocks on user interaction, how to stop the viewer, or what happens on an invalid path.

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?

The identity and return behavior are front-loaded, which is good, but the middle passage is a laundry list of viewer features (onion skin, side-by-side/difference/blink compare, version diffs) that mostly describes the UI rather than how to invoke the tool. Several of those clauses could be trimmed without losing invocation-relevant 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 single-optional-parameter tool with no output schema, the description covers the essential contract: what it launches, that it is local, and that it returns a URL. Remaining gaps (URL form, failure modes, whether it blocks) are minor given the tool's narrow scope.

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 coverage is 0%, so the description must supply the meaning of `path`, and it does at a basic level ('with `path` it opens that file'). It adds nothing about expected file type, relative vs. absolute paths, or behavior when omitted (the null default implies the default project), so it only partially compensates for the documentation gap.

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 identifies the tool as the built-in Studio Live web viewer and states that it returns a URL to open in the browser pane, which is a concrete resource and effect. It implicitly contrasts with siblings like view/compare by describing the viewer's interactive review features, though the opening sentence never uses an explicit verb like "opens" or "launches."

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?

It gives one concrete downstream workflow ('read those with review_notes') that routes the agent to a sibling, which is genuinely useful. However, it never explains when to choose live_open instead of the sibling `view`, `compare`, or `rig_preview`, nor any when-not conditions, so the selection logic against the closest alternatives is left to inference.

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?

With no annotations, the description carries the full burden; it does disclose the generative behavior in useful detail (even lightness steps, warm-leaning lights, cool shadows, chroma tapering at both ends). However, it says nothing about whether a ramp is persisted as an asset, whether it mutates existing material, determinism, or what gets returned, which are the questions an agent needs answered for a mutation-capable tool.

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 compact sentence with no filler, and the most distinctive fact (the output type) comes first. The terseness is a mild liability rather than verbosity, since the poetic phrasing crowds out the missing verb and parameter guidance.

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?

Four parameters at 0% schema documentation, no annotations, and no output schema: the description should carry the load and instead covers only aesthetic intent. An agent still cannot determine parameter meanings, defaults behavior, or the return shape before calling.

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 4 parameters, so the description must compensate and largely does not: no parameter name (base, steps, contrast, hue_shift) is mentioned or explained. At best, 'even lightness steps', 'hue leaning warm… cool' and 'chroma tapering' hint at what steps, hue_shift and contrast conceptually control, but the mapping and valid ranges are left entirely to inference.

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 names the concrete output ('a shading ramp around one colour') and its defining properties (OKLCh, darkest first, even lightness steps), so an agent can tell what it produces. It never states an explicit verb ('generates'/'returns') and gives no differentiation from siblings such as pixelize or apply, so it falls 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?

There is no guidance on when to reach for this tool versus alternatives like pixelize or apply, and no prerequisites or exclusions are stated. The only implicit signal is that it operates on 'one colour', which an agent must infer.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses a lot of algorithmic behavior (OKLab palette reduction, specks/orphan cleaning, grid-line drift handling, background auto-removal only when there is no transparency), which is genuinely useful. It is silent on overwrite semantics, what happens on failure, whether the source image is modified, and where output paths resolve, though, so gaps remain for a file-mutating tool.

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 one-line purpose, then a compact block of behavioral context, then terse per-parameter glosses with no wasted words. Dense but every line carries signal. The parameter list format is scannable, though the paragraph on grid detection is slightly heavy for what it adds.

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?

No output schema exists, and the description handles that by stating the return value (a report plus a source|result preview). Combined with mode-selection and parameter glosses, an agent has enough to invoke it correctly. Missing overwrite/failure semantics keep it from being complete for a mutating tool.

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 12 parameters, so the description must compensate, and it does for the five non-obvious ones: cell, target_height, background, outline, palette_from. image, output, layer, and overwrite are self-evident from their names. max_colors, merge_delta, and png_output are undocumented in both schema and description, which keeps it below 4.5.

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 chain: convert an image into pixel art and save it as a native-resolution .aseprite. No sibling tool (export, import_strip, apply) does this, so the agent can distinguish it from every other tool in the set without opening a 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?

Clearly explains the three modes: fake-grid detection, real illustration downscale, or explicit target_height. That tells the agent which path fires for which input. It stops short of naming sibling alternatives (e.g. when to use export + import_strip instead), so it is 4 rather than 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?

With no annotations, the description carries the full burden and does well: it discloses the return shape, the '.' = transparent convention, that omitting `layer` yields the flattened frame, and that the region is capped at 128x128. It does not state whether the call itself is side-effect free or what happens if the region exceeds the cap.

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 tight sentences with no filler, and the size cap is stated compactly. The opening fragment ('Pixels as a character map: {...}') prioritizes return format over purpose, which is mildly awkward as a lead but still efficient.

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 4-parameter read tool with no output schema, the description compensates by inlining the exact return structure and the transparency convention, which is the key missing piece. The remaining gap is `frame` semantics for multi-frame sprites, which matters given siblings like `check_animation` and `tween_poses`.

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 coverage is 0%, so the description must compensate and only partly does: it explains `layer` (flattened frame when absent) and `region` (128x128 cap), but `frame` (default 1) and `path` are never given meaning, format, or numbering conventions. Two of four parameters remain purely schema-derived.

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 conveys a specific operation on a specific resource: reading pixels and returning them as a character map, with the flattened-frame behavior when `layer` is omitted. It is distinguishable from write-oriented siblings (`apply`, `pixelize`) and from `map`-op writes, though the verb 'read' only appears mid-sentence rather than being front-loaded.

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?

It sketches a concrete workflow ('edit the rows and send them back with the map op: a read-edit-write round trip'), which tells the agent how the output is meant to be consumed. However, it never compares against the many sibling inspection tools (`view`, `sprite_info`, `compare`, `export`) or states when not to use this instead.

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?

No annotations are provided, so the description carries the full burden and does not meet it. It doesn't disclose failure behavior when there is nothing to redo, whether new edits invalidate the redo history, or whether this requires an open editor/session.

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, which is structurally fine, but the brevity is under-specification rather than economy — the size is mismatched to a two-parameter, annotation-free mutation tool.

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 no annotations, no output schema, and zero parameter documentation, the description should explain target selection and the multi-step behavior. It leaves both gaps and gives an agent only a bare conceptual gloss.

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% for both 'path' and 'steps', and the description never mentions either. Critically, an agent would not learn from the description that multiple steps can be redone in one call — that only shows up as an undocumented integer defaulting to 1 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 ('Redo') and target ('edits that were undone'), which is enough to place it as the inverse of the sibling 'undo'. It doesn't say anything about scope (which editor/document the history belongs to), but the core operation is unambiguous.

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?

No guidance on when to call this versus 'undo', no prerequisite stated (e.g. that a prior undo must exist), and no note on what happens if the redo stack is empty. The agent must infer all routing from the one-line description.

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?

With no annotations, the description carries the full burden, and it does disclose genuinely useful behavior: the reply text is shown to the user beneath the note, and status="open" reopens rather than resolves. It omits permissions/auth requirements, whether replying to an already-resolved note is allowed, and what happens on failure — significant gaps for a mutation tool with zero annotation coverage.

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 tight sentence front-loads the action, then nests the mechanism and the alternate mode parenthetically. No filler, every clause adds information the schema lacks.

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 mutation tool with no annotations and no output schema, the description does well to explain the two modes and the user-visible effect of the reply. The unexplained path parameter and the absence of any error or idempotency note keep it from fully covering the call.

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 coverage is 0%, so the description must supply all parameter meaning. It explains reply ('say what was fixed', visibly shown to the user) and status ("open" reopens), but says nothing about path — an unlabeled string the agent must guess at — and does not state whether reply is optional or required per mode.

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 gives a specific verb and resource: answering a 'Studio Live note', with the two possible outcomes (mark resolved vs. reopen). An agent can tell this apart from review_notes, which presumably lists notes rather than answering them. It stops short of naming that sibling explicitly, so the differentiation is inferential rather than stated.

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?

It clearly conveys the situation the tool is for (responding to a note already in hand) and describes the two modes: resolve, or reopen with status="open". It does not say where note_id comes from, whether review_notes must be called first, or when this should not be used, so usage is implied rather than spelled out.

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?

With no annotations, the description has to carry behavior, and it does most of the work: it discloses the default status filter (open), what each note contains (1-based frames, the fixed tag vocabulary, user text, per-frame pixel bbox and pixel data in sprite coordinates), and the composition of the returned image (previous / marked / next frame). It never explicitly states the operation is read-only or describes volume/pagination limits for large projects, which keeps it below 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?

The purpose is front-loaded in the first line and the enumeration of note contents is dense but purposeful, with no filler sentences. The text is a single long run-on block that would read better split by parameter or return value, but nothing is redundant.

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 three-parameter read tool with no output schema, the description supplies the return shape (frames, tags, text, bboxes, pixels, composed images) and the default filtering, which is close to complete. The gaps are the undocumented `pictures` flag and no statement that the call is non-mutating or that fixing requires the separate resolve_note/resolve flow.

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 coverage is 0%, so the description must document all three parameters, and it only covers two: `path` (omitted → all sprites under allowed folders) and `status` (open | resolved | all, default open). The `pictures` boolean is never explained — the sentence about what a note's picture contains hints at image output but doesn't tell an agent what setting `pictures: false` suppresses.

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 opens with a concrete statement of the resource: user-marked issues in Studio Live (wrong frames, painted pixels, tags, text). That is enough for an agent to tell it apart from pixel-inspection siblings like read_pixels or find_glitches. The phrasing is slightly indirect — it describes what the notes contain rather than saying plainly 'returns review notes' — so it falls short of a clean verb+resource statement.

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 implied rather than stated: 'Without `path`, every sprite with notes under the allowed folders' conveys the broad-vs-targeted selection, and 'Fix, then resolve_note' points at the natural follow-up. There is no explicit when-to-use/when-not-to-use framing against siblings such as find_glitches or lint, which also surface animation problems.

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?

No annotations, so the description must carry the load, and it does disclose non-obvious behavior: parts claim pixels in list order, leftovers form an implicit 'rest' part, and the preview is rendered with tints plus white pivot dots. It omits whether the tool mutates document state or errors on an invalid rig, which is a meaningful gap for a nested-object tool.

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?

Dense but front-loaded: the purpose and observable outputs come first, then the rig grammar. The inline pseudo-schema is terse and earns its space, though the run-on structure makes it slower to scan than a bulleted shape.

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 4-parameter tool with a deeply nested object, no annotations, and no output schema, the rig grammar is well covered but the frame/layer targeting and the mutation-vs-read nature are left undefined. An agent could construct a rig but not confidently pick frame or layer values.

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 coverage is 0%, so the description must document everything, and it does an above-average job on the complex `rig` parameter — mask variants (rect/polygon/rows/colors/union/minus), pivot, parent, z, and the overlap flag are all explained. However `path`, `frame`, and `layer` (half the parameters) are never mentioned, so compensation is partial.

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+resource: 'Check a rig before animating', and enumerates what the preview reveals (tinted pixel assignment, white pivot dots, pixel counts, bounding boxes). It is distinguishable from animate_rig and check_animation by being a static diagnostic rather than a motion evaluation, though it never names those siblings.

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?

'Check a rig before animating' gives clear situational context — this is a pre-flight validation step. There are no explicit exclusions or named alternatives (e.g. lint, check_animation) telling the agent when to pick a different diagnostic.

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?

With no annotations provided, the description carries the full behavioral burden. It usefully discloses the returned information including layer/cel/link details and warnings, which implies a read-only inspection operation, but it does not explicitly state that the tool is non-mutating, what permissions or file-access assumptions apply, or what the response format looks like.

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?

The description is a single front-loaded sentence that efficiently enumerates the important return categories. Every clause contributes useful information, and there is no waste.

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?

Because there is no output schema, the description must explain what comes back, and it does so with a strong list of structural fields and warnings. The main remaining gap is that the input path parameter is undocumented and no annotations are available, but for a simple one-parameter inspection tool the definition is largely complete.

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%, and the description does not mention the single path parameter at all. While 'path' is intuitive for a sprite-information tool, the description adds no semantics about what kind of path is expected or how it is interpreted.

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 clearly identifies the resource as a sprite and enumerates the structural information returned: size, frame durations, layer tree, tags, slices, palette size, and warnings. It lacks an explicit verb like 'inspect' or 'retrieve', and it does not name a sibling alternative, so it is clear but not fully differentiated.

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 implies that this tool is used to inspect a sprite's structure, but it gives no explicit when-to-use guidance, no prerequisites, and no comparison to siblings such as view, lint, or check_animation. An agent must infer the appropriate context entirely.

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?

With no annotations, the description carries the full burden. It does add real value by disclosing that the canvas starts transparent RGBA, that one layer named "Layer 1" exists by default, and that `layers` are ordered bottom to top. It omits what happens on collision when overwrite=false, whether directories are created, and any permission or failure behavior.

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 sentences, zero filler, with the core operation front-loaded and the layer caveat attached directly after. Sizing is appropriate for the tool's simplicity, though the brevity contributes to the parameter gaps noted elsewhere.

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 file-creating mutation with no annotations and no output schema, the description is thin. An agent still cannot tell what overwrite does, what frames/duration_ms control, or what the tool returns on success versus file-exists failure.

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 7 parameters, so the description must compensate and largely does not. Only `layers` (ordering and default) is explained, plus the implied meaning of path/width/height from the first sentence; `frames`, `duration_ms`, and `overwrite` get no semantics at all.

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 with distinguishing detail: creating a new transparent RGBA .aseprite file. That clearly separates it from siblings like import_strip, sprite_info, or open. No sibling is named, so it misses the top band.

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?

There is no guidance on when to use this versus import_strip or other creation paths, and no prerequisites stated (whether the parent directory must exist, what happens when the target file already exists). The only contextual note is the default layer naming, which is behavioral rather than usage guidance.

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?

With no annotations, the description carries the load and does disclose real behavior: out_layer is written from first_frame as start drawing + inbetweens + end drawing, deformation is fitted per part, and the return includes per-part fit, bone_stretch, and an onion-skin view. Gaps remain — the `clean` flag (default true) and what happens to pre-existing out_layer content are never explained.

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 purpose, then organized by topic: rig setup, output framing/ease/extra, then return values. It is dense with long parenthetical asides but nearly every sentence carries technical information an animator needs.

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?

A complex 15-parameter geometry tool with no annotations and no output schema gets a solid explanation of the core rig and output mechanics. However, with 0% schema coverage and roughly half the parameters unexplained, an agent still cannot confidently supply durations, angle_range, clean, or the frame bounds.

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 coverage is 0% across 15 parameters, so the description must compensate, and it only explains some: rig_start/rig_end, ease, extra, inbetweens and first_frame get real meaning. durations, angle_range, clean, path, start_frame/end_frame, and start_layer/end_layer are left entirely undocumented by both schema and description.

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: generates in-betweens between two drawn key poses for one character (pose-to-pose). It is clearly distinguishable from rig_preview (it only references its mask syntax) though it never explicitly contrasts itself with animate_rig, another animation-producing sibling.

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 concrete operating context: rig_start/rig_end must share part names and pivots must sit on the same joint in both drawings. It also provides actionable remediation (under 0.4 match = split at the joint or redraw). It stops short of saying when to pick this over animate_rig or other animation tools.

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?

With no annotations, the description carries the full burden, and it does disclose two real behavioral facts: the undo history is server-scoped and capped at 50 per file. It does not say whether the file on disk is rewritten, whether undo is itself reversible via redo, or what error/behavior occurs when the cap is hit.

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 parenthetical cap is the only extra clause and it does add information. Slightly tighter phrasing could clarify that the cap is on undo depth rather than edits per call.

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 two-parameter, no-annotation tool with no output schema, the description gives the essential capability and scope but omits post-undo state (is the file saved? is redo now available?) and any explanation of the 'steps' argument. Adequate minimum, with clear gaps.

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% and neither parameter is documented. The description implies a history limit of 50 that relates to the 'steps' parameter, but it never explains that 'steps' selects how many edits to roll back or what 'path' should point to, so an agent must guess at the multi-step behavior.

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 (undo) and resource (the last edits made through this server to a file), plus a concrete scope bound of 50 undo levels per file. It is clearly distinguishable from siblings like redo or view by the plain meaning of 'undo', though it never names an alternative 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?

The phrase 'edits made through this server' is an implicit precondition (only server-tracked edits can be undone), which is useful guidance. However, there is no explicit statement of when to prefer this over redo, or what happens once the 50-step history is exhausted — usage must be inferred.

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?

With no annotations, the description carries the full burden. It discloses the external dependency and the core process (open, render, compare), but it does not clarify side effects, failure modes when Aseprite is unavailable, permissions required, or the nature of the comparison result. Some transparency is present but incomplete.

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 tightly written sentences. The first sentence front-loads the process, and the second states the value proposition. No wasteful language, though it could more explicitly link the process to the required path argument.

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?

The description covers the core behavior and external dependency, which is the main complexity. However, given no output schema, it should explain what 'compare' returns (e.g., boolean, report details) and describe the path parameter. These gaps leave the tool partially specified for an agent.

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?

There is one parameter ('path') with 0% schema description coverage. The description refers to 'the file' but never explains what the path parameter expects (e.g., absolute vs relative path, supported file types). It adds no meaning beyond the schema's bare title.

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 sequence of actions (open with real Aseprite, render every frame, compare with server's renderer) and clarifies the outcome (proves file validity and preview match). This clearly distinguishes it from siblings like lint or check_animation, which do not involve external Aseprite.

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?

It implies usage by mentioning the dependency on Aseprite installation (ASEPRITE_PATH or usual folder), but it does not explicitly say when to choose this tool over alternatives such as lint, check_animation, or compare. No exclusions or direct sibling comparisons are given.

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?

No annotations are provided, so the description carries the full burden. It does disclose return-shape behavior well (composited image, checkerboard, 8px grid, rulers, onion skin in red/blue) and implies a 16-frame cap, but says nothing about whether it is read-only, whether it writes files, or what happens with large scale/frame counts.

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?

Dense but every clause carries information, and the rendering description is front-loaded before parameter details. The line breaks inside sentences make it slightly harder to scan than necessary, but there is no 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 9-parameter tool with no annotations and no output schema, the description covers the visual result and four key parameters adequately. The required path, scale, and layers remain unexplained, and side-effect/read-only behavior is unstated, leaving meaningful gaps for an agent to guess at.

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 coverage across 9 parameters, the description has to do all the work. It explains the non-obvious ones well — frames accepts 1-based lists, "all", or ranges like "2-6"; region is [x,y,w,h]; mode is color/value/silhouette; onion=true. But the required `path` parameter, plus grid, scale, layers, and rulers, are left undocumented, so half the surface is still opaque.

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 opens with a concrete verb+resource ("Look at frames") and immediately specifies the rendered output: one image, up to 16 frames side by side, with checkerboard, grid, rulers, and per-frame labels. It never names the artifact type (sprite/animation file) or explains what `path` points to, and it doesn't distinguish itself from siblings like read_pixels or sprite_info, so it falls 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?

Usage is only implied through the mode definitions (e.g. value mode framed as "do the forms read without hue?"), which hints at intent but gives no explicit when-to-use vs. read_pixels, compare, or sprite_info. There are no stated exclusions or prerequisites, so the agent must infer when this visual-check tool is the right choice.

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