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 two real behavioral facts an agent needs: indices are 0-based, and inserted frames start empty (so content must be drawn separately). It says nothing about reversibility, tag/timeline side effects, or whether durationMs applies to the new frames.

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 sentences, front-loaded with the verb and resource, then the indexing convention, then the placement control, then the follow-up workflow. No wasted words and no repetition of schema detail.

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 mutation tool with no annotations and no output schema, the description covers the essential call semantics and the natural follow-up step. It leaves minor gaps: the interaction of durationMs with newly inserted frames and whether any return value or frame count is reported.

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 100%, so mode, count, index, document, and durationMs are already documented in the schema; baseline is 3. The description adds only the 0-based indexing note and the mode-relative-to-index framing, which the enum description largely already conveys.

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 ("Insert empty frames") and the word "empty" cleanly distinguishes it from sibling aseprite_duplicate_frame, which would otherwise be the nearby ambiguous alternative. An agent can tell what this does without opening the 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?

It implies the workflow (insert empty frames, then draw into them via aseprite_draw's `frame` argument), which is genuinely useful sequencing guidance. However it never states when to choose this over aseprite_duplicate_frame or when not to use it, so usage is inferred rather than explicit.

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 behavioral burden and largely fails: it never says where the new layer lands by default (top of stack?), what happens on a name collision, whether it mutates the document, or that it needs an active/open document. Only the implied mutation from "Add" is conveyed.

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 sentence, which is good. The second sentence is a domain tip rather than tool information, so it does not fully earn its place in a definition whose job is selection and invocation.

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 six-parameter mutation tool with no annotations and no output schema needs more than one functional sentence. Placement semantics, document handling, and default behavior are left entirely to the schema, which is inadequate for a write operation.

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 100% and all six parameters are self-documented, so the baseline is 3. The description adds nothing about parameters and notably omits that above/below are mutually exclusive placement alternatives.

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 first sentence gives a clear verb+resource ("Add a layer") and the tool's role is unambiguous. However, it does not distinguish this from siblings like aseprite_set_layer, aseprite_merge_layer_down, or aseprite_remove_layer, so an agent gets no help choosing among 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?

The pixel-art layering advice implies a usage context (organizing artwork into outline/base/shading/highlight layers), which is genuinely tool-adjacent. But there is no explicit when-to-use, no mention of prerequisites (e.g. needing an open document), and no alternate-tool routing.

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 says what is copied but not what happens to pre-existing artwork at the destination cel, whether missing destination frames/layers are created, whether the source is left intact, or what the operation returns. For a mutation tool with zero annotation coverage this is a substantial gap.

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 short sentences, front-loaded with the operation and its scope, followed by the use cases. No filler, no repetition of schema content, and the parenthetical gloss on 'cel' 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?

There is no output schema to compensate, and with no annotations the description should ideally cover overwrite/create semantics and permission or document-state prerequisites. It covers purpose and use cases adequately but leaves the behavioral outcome of the copy underspecified.

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 100% and the schema already documents all five parameters, including the default behaviors for fromLayer, toLayer, and document. The description adds only the conceptual definition of a cel, so the baseline of 3 is appropriate.

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 precise verb+resource+scope ('copy one layer's artwork from one frame to another') and immediately defines the jargon 'cel = one layer on one frame'. This lets an agent distinguish it from timeline-level siblings such as aseprite_duplicate_frame or aseprite_move_frame without opening any 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 concrete motivating use cases ('holding poses', 'stamping a base drawing across a new animation'), which implies when the tool is appropriate. However, it never names an alternative or states when NOT to use it — notably it does not distinguish itself from aseprite_duplicate_frame, the nearest overlapping sibling.

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 the key behavioral fact that the created document becomes active and that every other tool operates on it, plus the 0-based top-left coordinate convention. However, it says nothing about what happens to a previously open document, error/overwrite behavior when the name exists, or side effects of palette indexing.

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?

Four tight sentences, front-loaded with purpose and the critical 'active document' fact, then coordinate convention, then sizing heuristics. No filler; each sentence carries actionable 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 10-parameter creation tool with no output schema and no annotations, the description covers purpose, activation semantics, coordinate frame, and sizing/frame guidance well. It leaves gaps around error/overwrite behavior and indexed-color mode interactions that an agent might need, but the schema covers per-parameter defaults.

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 100%, so the baseline is 3, but the description adds meaning beyond the schema: practical sizing guidance for width/height, the rationale for pre-setting `frames` (animation planning), and the coordinate system the canvas uses. It doesn't explain indexed-mode palette/paletteSize interplay, so not 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?

States a specific verb+resource ('Create a new pixel-art document') plus a crucial side effect ('make it active'), and immediately distinguishes itself from siblings like aseprite_open and aseprite_import_image by being the document-origin tool. An agent can tell what it does without opening the 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 real when-to-use guidance: choose a small canvas, with concrete size heuristics (16-32 px characters/items, 64-128 px scenes), and set `frames` up front when planning animation. It doesn't explicitly name the alternatives (open vs. import) it should be preferred over, which keeps it from a 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 behavioral burden. It does disclose scope ('every frame'), which is genuinely useful, but it omits that cropping is destructive (pixels outside the rect are discarded) and whether sprite dimensions, tags, or cels are recalculated.

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 short sentences, zero waste, with the core action front-loaded and the use case trailing. Nothing needs cutting.

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 5-parameter mutation tool with no annotations and no output schema needs more than two sentences. Missing are destructive-effects disclosure, what happens to art outside the rectangle, and whether canvas/sprite dimensions change as a result.

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 60%: x, y, and document are documented, but width and height carry only a minimum constraint with no meaning. The description adds no parameter guidance at all, so it fails to compensate for the four undocumented rectangle semantics.

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 (crop) and resource (every frame) with the target shape of the operation (a rectangle). 'Every frame' usefully distinguishes it from per-frame or canvas-level operations, though it does not explicitly name the nearest siblings like aseprite_resize_canvas or aseprite_scale_sprite.

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 to trim dead space around the artwork' gives a concrete motivating scenario, which is better than nothing. However it offers no when-not guidance and no alternatives (e.g., vs resize_canvas or scale_sprite), leaving the agent to infer when cropping is preferred over resizing.

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 useful traits: ops apply in order, coordinates are 0-based from top-left, each op may override layer/frame, and 'clear' makes regions transparent. However, it is silent on side effects like whether drawing requires an open document, undo/reversibility, whether a missing layer auto-creates, and error 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?

Front-loaded with purpose and the key 'ops applied in order' mechanic, then a dense but well-aligned op reference table. Every line documents a distinct operation or coordinate/color convention; nothing is redundant 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?

Given no output schema and no annotations, the description is strong on input semantics and op behavior. Minor gaps remain around document creation requirements, failure behavior, and interaction with the active document when 'document' is omitted, but an agent has enough to invoke correctly.

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?

Top-level schema coverage is 100% for document/frame/layer/ops, but the ops array is additionalProperties:true with only 'op' documented, so the description carries essentially all op-level parameter semantics: per-op fields (x, y, w, h, cx, cy, rx, ry, points, tolerance, bands, matrix, ratio, tile, scale) plus the '#rrggbb'/'#rrggbbaa'/name color formats. This is substantial added meaning well beyond 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 ('Draw geometric primitives') and immediately enumerates the exact drawing operations supported, making it distinguishable from siblings like aseprite_fill_regions, aseprite_text, and aseprite_pixels. An agent can tell what this tool produces without opening the 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?

The op catalog implies usage (use 'fill' for flood fill, 'text' for text, 'spline' for curves), but there is no explicit when-to-use guidance or routing against overlapping siblings such as aseprite_fill_regions, aseprite_text, or aseprite_draw_across_frames. Usage must be inferred from the operation list.

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 behavioral burden and does clarify the default scope (all frames when `frames` is omitted) and the semantics of the dx/dy offset. However, it says nothing about what drawing does to existing pixel content, required permissions, or error behavior for these mutating operations, leaving meaningful gaps.

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, front-loaded with the core purpose before the defaults and the offset explanation. Nothing is wasted, though it could be marginally tighter.

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-param mutating drawing tool with no annotations and no output schema, the description covers frames well but is silent on the `layer` and `document` targeting parameters and on return/error behavior. It is adequate but not 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 coverage is 100%, so baseline is 3, but the prose adds genuine meaning: it explains the {index, dx, dy} object form actually moves the artwork by (dx, dy) on that frame and that omitting `frames` means every frame. That offset semantics goes beyond the terse schema text.

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 (apply drawing operations) and resource (several frames) plus the distinguishing capability (per-frame offsets). It explicitly anchors to the sibling aseprite_draw by saying ops are 'the same operation objects as aseprite_draw', so an agent can route between them without opening schemas.

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?

Explains the intended use case ('how you animate motion efficiently') and the key branching condition: omit `frames` to draw on all frames, or pass indices/offset objects for per-frame placement. It stops short of naming when NOT to use it (e.g. a single static draw), which aseprite_draw would cover, so it isn't fully explicit about alternatives.

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 behavioral burden. It discloses that all layers are copied to the next slot, but omits side effects such as whether subsequent frames shift, undo behavior, and return information.

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 front-loaded sentences with no wasted words. The second sentence earns its place by giving a concrete animation-building rationale.

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 low complexity, full schema coverage, and no output schema, the description supplies enough purpose and usage context to invoke correctly. It could mention side effects, but that is a minor gap for this simple frame-duplication operation.

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 100%, so the index, document, and duration parameters are already documented. The description adds only the scoping phrase 'all layers' and target phrase 'next slot', not parameter syntax or defaults.

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 (Copy) and resource (frame), plus explicit scope (all layers) and target (next slot). This differentiates it operationally from siblings like move_frame and copy_cel even without naming 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?

Provides a clear usage context: the fastest way to build an animation by duplicating and then editing only changed parts. It does not explicitly list alternatives or when-not-to-use conditions.

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 behavioral burden. It states the effect (makes the region transparent) and scope (layer, across frames), but omits whether the action is destructive, reversible, how it interacts with other layers, or what result is returned.

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 with no wasted words. It is appropriately sized for the operation it names.

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 tool with no annotations, no output schema, and low schema description coverage, the description is too thin. It does not explain the coordinate system, defaults beyond what the schema partially covers, or expected return behavior, leaving gaps an agent would need to infer.

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 43%, so the description must compensate. It implies that x, y, width, and height define a rectangular region and mentions layer and frames, but it adds no coordinate-system, units, or detailed parameter meaning beyond that.

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 a specific verb (erase) and resource (rectangular region on a layer, across frames), making the core operation clear. It does not explicitly differentiate from siblings such as aseprite_remove_frame or aseprite_fill_regions, but the resource scope is distinct enough for an agent to understand.

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 gives no when-to-use guidance or alternatives. It implies the operation is for erasing pixels in a rectangle across frames, but an agent gets no help choosing this over sibling tools like aseprite_fill_regions or aseprite_replace_color.

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 adds one genuinely useful trait (timing derives from each frame's duration), but says nothing about overwrite behavior, default output location, required document state, or what a successful export returns.

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 action and followed by a single routing rationale. Nothing 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 simple export tool with full schema coverage this is nearly adequate, but with no annotations and no output schema the description should say more about the produced artifact and where it lands. It covers purpose and one timing behavior but leaves side effects and output handling to inference.

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 100%, so the schema already documents scale, output, and document in detail. The description adds no parameter-level meaning beyond what the schema provides, making the baseline 3 appropriate.

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 (Export) and resource (animated GIF) and clarifies it preserves each frame's own duration. This naturally separates it from aseprite_export_png and aseprite_export_sprite_sheet, though it never names those siblings 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 'quickest way to show the user a moving preview' implies when to reach for it, but there is no explicit when-not guidance or named alternative (e.g., export_sequence for frame files, view for stills). 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?

No annotations are provided, so the description carries the full burden and does well: it discloses the default compositing of visible layers, the default frame (0), and that integer scales preserve crispness. It omits whether an existing file is overwritten and what authorization/path constraints exist for writing output.

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 sentences, front-loading the default behavior before the optional parameters. Every sentence carries distinct information with 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?

With no annotations and no output schema, the description should ideally say what the tool returns (e.g., the written file path/how the agent learns where the PNG landed). It covers invocation semantics well but leaves the result side and overwrite behavior unstated.

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 already 100%, so the baseline is 3, but the description adds genuine meaning: the default frame index, the union of layers used when `frame` is omitted, and the pixel-crisp rationale for integer scaling. The `output` parameter's semantics are left entirely to 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 ("Export the sprite as a flat PNG") plus the composite semantics, which distinguishes it functionally from the gif/sheet/sequence siblings. It does not name any sibling explicitly, so the differentiation is implicit 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?

Gives clear conditions for the optional parameters: default writes the first frame with all visible layers composited, pass `frame` for a specific frame, pass `scale` to upscale. It does not state when to prefer this over aseprite_export_sprite_sheet or aseprite_export_sequence, so the routing guidance is incomplete.

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 behavioral burden, and it does disclose the key trait: output is numbered per-frame files rather than a single image. However, it says nothing about whether an existing output directory is created or overwritten, or what the call returns, which are relevant for an export side-effect 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?

Two sentences, zero waste: the first defines the behavior and output shape, the second gives the use case. Front-loaded and easy 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?

No output schema exists, so the description should carry return/side-effect context, and it partially does by describing the produced files and naming pattern. Given the fully documented schema and the straightforward export purpose, this is nearly complete, missing only overwrite/permission 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 100% across all five parameters, so the schema already documents name, scale, format, document, and outputDir with defaults. The description echoes the default PNG naming pattern but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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 ('Export every frame as its own numbered PNG') and demonstrates the output naming convention with a concrete example (hero_000.png, hero_001.png). It implicitly separates itself from aseprite_export_sprite_sheet by framing it as the alternative to a packed sheet, though it never names that sibling directly.

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 this when an engine or artist wants individual frames rather than a packed sheet' gives a clear selection condition and contrasts with the packed-sheet alternative. It stops short of naming aseprite_export_sprite_sheet explicitly, so the routing requires a small 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 burden. It does disclose the output artifacts (PNG plus optional JSON) and a real behavioral concern (padding to prevent bleeding when scaled), but says nothing about output overwrite semantics, active-document fallback, or how the JSON relates to dataOutput. Useful but incomplete for a mutation-free but 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?

Two sentences, front-loaded with the core action and rationale, then a compact clause covering the most useful knobs. No padding or redundancy, though the second sentence is a slightly loose list rather than a tight single idea.

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 an 18-parameter tool with no annotations and no output schema, the description is adequate but thin: it omits frame-range vs tag tradeoffs, layer splitting behavior, and the fact that relative paths land in the out folder (left to the schema). It covers enough for correct invocation but not for confident use across all options.

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 100%, so all 18 parameters are already documented. The description only name-drops tag, sheetType and padding, which duplicates schema content without adding syntax, defaults, or interaction details. Baseline 3 is correct when the schema does the heavy lifting.

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 (export a sprite sheet PNG plus optional JSON metadata), and the framing 'the standard way to hand pixel-art animations to a game engine' scopes it against the sibling exporters (export_gif, export_sequence, export_png). An agent can tell this apart from the other export tools 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?

Gives clear context for when to reach for it and hints at three selectors (tag, sheetType, padding). It stops short of naming an alternative such as export_png or export_sequence and saying when NOT to use this one, so no explicit when-not is present.

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 discloses the single-layer scope and per-pixel semantics, but says nothing about whether existing pixels are overwritten, undo behavior, or permission/document requirements for a clearly mutating operation. Useful scoping context, but the mutation contract is underspecified.

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, front-loaded with the core action, then the differentiation. Every clause earns its place with no redundancy.

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 and no annotations, but for a per-pixel paint tool the description plus rich schema cover the essentials. The main remaining gap is behavioral: overwrite/undo semantics and document-state requirements are unstated, which a mutation tool of this kind ideally would address.

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 100%, so the schema already documents x/y offsets, cells structure, layer, document, and color formats. The description only loosely maps to the parameters ('each with its own colour, on one layer') and adds no format or default details beyond what the schema supplies. Baseline 3 applies.

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 ('Paint') and resource ('set of individual pixels, each with its own colour, on one layer'), and explicitly names the sibling it differs from (`aseprite_pixels`). An agent can distinguish this from the rectangular-block variant 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?

Explicitly contrasts with the alternative ('Unlike `aseprite_pixels` this does not need a rectangular block') and lists concrete scenarios: touching up scattered details, adding a highlight, fixing stray pixels. It lacks an explicit 'when not to use this' caveat, but the context is clear.

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 discloses that only *visible* layers are collapsed, which is meaningful scope information, but omits the critical behavioral facts: that flattening destroys layer separation irreversibly and what happens to hidden layers (dropped or preserved).

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 short sentences, front-loaded with the operation and followed by the timing constraint. No filler or restatement of the tool name.

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 simple, zero-required-parameter tool with full schema coverage and no output schema, the description supplies the operation and the workflow timing. A brief note on irreversibility or hidden-layer handling would make it 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?

Only one optional parameter, documented at 100% schema coverage, which already explains the short-name/relative-path/absolute-path/omit-for-active-document forms. The description adds nothing beyond the schema, so the baseline of 3 applies.

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 ('Flatten all visible layers into one') with a clear scope qualifier ('visible'). This implicitly distinguishes it from aseprite_merge_layer_down, which merges a single adjacent pair, though no sibling is named 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?

'Do this last, once the composition is settled' gives real sequencing guidance and is genuinely useful for workflow ordering. It does not, however, say when NOT to flatten, nor does it route the agent to alternatives like aseprite_merge_layer_down for partial merges.

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 behavioral burden, and it leaves key mutation semantics unstated: whether existing frames are overwritten or new frames created, whether the document is modified destructively, and what permissions/state are required. The single-layer constraint is useful, but the overwrite/create ambiguity is a real gap for a write 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?

Three sentences, front-loaded with the core action and rationale, with no filler. The efficiency claim is somewhat promotional but functions as usage guidance, so little 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 6-parameter mutation tool with no annotations and no output schema, the description explains the main workflow but omits frame-creation/overwrite semantics and any indication of what the call returns or how failures surface. Adequate but 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 coverage is 100%, so the parameters are already documented, and the description only restates the x/y offset and single-layer behavior. Baseline 3 applies since the schema does the heavy lifting and the description adds no syntax or format detail beyond it.

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: draw an entire animation by mapping one character grid to one frame. It is clearly distinguishable from single-draw siblings like aseprite_draw or aseprite_draw_across_frames, but it never names them, so sibling differentiation is left implicit.

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 states the positive condition well — 'the fastest, most token-efficient way to produce a multi-frame animation' tells the agent to reach for this when animating wholesale rather than drawing frames one at a time. It offers no explicit exclusions or named alternatives, but the context is clear.

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 discloses that output is hex colours (useful), but says nothing about whether it reads the saved file or the in-memory document state, what happens with no document open, or that it is strictly non-mutating. For an unannotated tool this is a significant gap.

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 zero filler; every word earns its place and the resource and return format are stated up front.

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 simple one-parameter read tool with no output schema, the description tells the agent the operation and the shape of the result (hex colours), and the schema fully covers the input. Only the missing behavioral context 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 100% and the 'document' parameter is fully documented in the schema (short name, relative path, absolute path, omit-for-active). The description adds nothing beyond that, so the baseline of 3 applies.

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 document's current palette') plus the output format ('as hex colours'), so the agent immediately knows what it returns. It does not explicitly name the sibling it differs from (e.g. set_palette, load_palette, pick_color), leaving some differentiation to inference, but the purpose itself 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?

There is no when-to-use guidance, no mention of prerequisites, and no routing to or away from the closely related siblings (set_palette, load_palette, pick_color, quantize_palette). The agent can only infer it is a read operation from the verb 'List'.

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 behavioral burden. It discloses the two modes and that non-new-sprite imports are drawn onto a layer of the active document at (x, y), but it omits mutation side effects such as layer creation behavior, frame targeting, reversibility, or what happens to the active document.

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 sentence, and the following sentences efficiently explain the two operational modes with relevant examples. The parenthetical examples are useful, though slightly verbose, keeping it from a perfect score.

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 mutation tool with no annotations and no output schema, the description covers the main branching behavior but leaves gaps around return values, error handling, and side effects like document/frame/layer interactions. The rich schema reduces the burden, but the description could do more to prepare an agent for safe 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 coverage is 100%, so all parameters are already documented in the input schema. The description names `asNewSprite` and references (x, y), but it does not add syntax, formatting, or constraints beyond what the schema already provides.

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: importing an external image into the pipeline, with a clear branch for `asNewSprite` versus drawing onto the active document. It does not name a sibling tool to contrast with, but the purpose is unambiguous and distinguishable from generic open/create operations.

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 provides concrete use cases for both modes: tracing over a reference or manually slicing a sprite sheet with `asNewSprite`, and stamping a palette reference, logo, or texture otherwise. It does not state when not to use the tool or name alternatives, so it stops short of full routing 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?

No annotations are provided, so the description carries the full behavioral burden. It effectively communicates that this is a non-mutating report and what fields it surfaces, but never explicitly states it changes nothing, requires no permissions, or has any cost/side effects – leaving the safety profile to inference.

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: the first enumerates the returned data, the second gives the when-to-use. Zero filler and the content is front-loaded.

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 output schema, the description must convey return values and does so thoroughly. Combined with the schema's full parameter documentation, an agent has everything needed to invoke it correctly.

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 single 'document' parameter is fully documented in the schema (100% coverage), including short-name, relative-path, absolute-path resolution and the omit-to-use-active behavior. The description adds no further parameter meaning, so baseline 3 applies.

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 ('Report') and enumerates exactly the resource facets returned: document size, colour mode, layer list, frame list with durations, and tags. This distinguishes it from siblings like aseprite_status or aseprite_get_palette, which cover different facets.

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?

States two concrete trigger conditions ('re-orient before editing', 'confirm a change landed'), which gives an agent clear context for selecting this over siblings. It stops short of naming an explicit alternative when a narrower read tool would do, but the guidance is actionable.

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 output format (text rows, palette legend, '.' for transparent pixels) and references a safety limit via maxPixels, which is useful. However, it never states that the operation is read-only/non-destructive, nor whether it requires an open document or has any cost/auth implications.

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, front-loading what the tool produces and following with the comparison and the key output convention. Every sentence 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?

There is no output schema, and the description compensates well by explaining the text-row/palette-legend format and the transparency marker. Minor gap: it doesn't mention the read-only nature or behavior when maxPixels is exceeded, but nothing essential to calling it correctly 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?

Schema coverage is 100%, so all three parameters (frame, document, maxPixels) are already documented in the schema, establishing the baseline of 3. The description adds only the '.' transparency convention, which describes output rather than parameter 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+resource ('Dump a frame as text rows, one character per pixel') and immediately clarifies the output form with a palette legend. The phrase 'Cheaper and more precise than an image' distinguishes it from the image-based siblings like aseprite_view and aseprite_export_png.

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 a clear condition for use: 'when you only need to verify exact pixel positions or check a symmetric arrangement.' This implicitly routes agents away from the heavier image tools, though it names no sibling explicitly and states no true exclusion case.

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 says 'apply/load' but does not disclose whether this replaces the existing palette, affects the active document, requires indexed mode, or is undoable.

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 short and front-loaded, with the core action stated first. The preset list duplicates the schema enum and 'Great starting point' is somewhat decorative, but overall it is 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 palette-mutating tool with no annotations and no output schema, the description identifies sources and brief intent but omits the effect on the document or palette and any error behavior. The schema covers parameters well, making this adequate but not 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 100%, so the baseline is 3. The description repeats preset names already enumerated in the schema and mentions .gpl/.ase files, but adds no syntax, constraints, or semantics beyond what the schema provides.

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: apply a retro palette by name or load one from a .gpl/.ase file. The source choices make the tool recognizable, but it does not explicitly differentiate itself from siblings such as aseprite_set_palette or aseprite_quantize_palette.

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?

Offers implied guidance with 'Great starting point for a coherent piece,' suggesting early workflow use. It does not state when to prefer this over set_palette/get_palette/quantize_palette or provide exclusions.

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. 'Merge' implies a destructive mutation that removes the source layer, but the description never states that the merged layer is consumed/deleted, nor any prerequisite that a layer must exist beneath it. The core direction is clear, but the destructive consequence is left implicit.

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 short sentences with the core action front-loaded and zero filler. The second sentence is somewhat imprecise (a merge-down is not exclusively an end-of-piece operation), which slightly dilutes the otherwise tight structure.

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 mutation tool with no annotations and no output schema, the description omits key context an agent needs: that the operation is destructive (source layer removed), and how it differs from aseprite_flatten. It is adequate but leaves notable 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 coverage is 100%, so both optional parameters (name, document) are fully documented in the schema, including the default-layer behavior. The description adds no parameter detail beyond that, so the baseline of 3 applies.

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 (merge), resource (a layer), and direction (into the one beneath it), which distinguishes it from siblings like aseprite_flatten, aseprite_remove_layer, and aseprite_add_layer.

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 second sentence gives loose usage context ('at the end of a piece, or to flatten shading into a base layer'), but it never names or distinguishes the close alternative aseprite_flatten (which flattens all layers) nor states when-not to use this tool. Context is implied rather than precise.

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 discloses essentially nothing beyond the basic action: no mention of whether tags/cels follow the moved frame, how indices shift, whether the operation is undoable, or what permissions/document state are required for a mutation 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 tight sentence with the action and mechanism front-loaded and no filler. It is appropriately sized, though it errs on the side of under-specification rather than being wasteful.

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 3-parameter mutation tool with no annotations and no output schema, the description leaves key gaps: no return information, no document-state prerequisites, and no note on side effects such as index shifting or tag/cel 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 100%, with 'from', 'to', and 'document' each documented. The description adds no syntax, indexing convention, or accepted-range detail beyond what the schema already supplies, so the baseline 3 applies.

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 (reorder/move) and resource (timeline frame) with a clear mechanism: relocating one frame to another position. It is distinguishable from siblings like aseprite_remove_frame, aseprite_duplicate_frame, and aseprite_add_frames, though it never names them 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 description gives no when-to-use guidance, no prerequisites (e.g., opening/selecting a document), and no alternatives among the many frame-manipulation siblings. The only cue is the implicit 'reorder the timeline' context.

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 what the render looks like (red/cyan ghosting, adjacent-frame comparison), but says nothing about whether this is a read-only operation, whether it returns an image or writes a file, or any side effects—leaving real behavioral gaps for a 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?

Two sentences, zero waste, and the concrete rendering behavior is front-loaded before the use case. Every clause 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?

For a simple 3-parameter read-style tool with no output schema, the description conveys enough to invoke it correctly. The only shortfall is not clarifying the output medium (returned image vs. saved file), which matters in a family of view/export tools.

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 67%: 'frame' and 'document' are documented in the schema, 'scale' is not, and the description adds no parameter-level detail (e.g., what scale does to output). Baseline 3 is appropriate since the schema does most of the work.

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 ('Render a frame') and immediately specifies the distinct visual output: previous frame ghosted red, next frame ghosted cyan. This is clearly distinguishable from siblings like aseprite_view, aseprite_export_png, or aseprite_inspect_pixels.

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?

Explicitly gives the use case ('use it to verify the arc of a swing, a walk, or a bounce'), which tells the agent when this diagnostic is appropriate. It does not name an alternative tool or state exclusions, so it falls short of a 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?

No annotations are present, so the description carries the full behavioral burden. It usefully discloses the path-resolution rule (absolute, or inside the art folder) and that it makes the file active, but says nothing about what happens to the previously active document, whether unsaved changes are lost, or the error behavior for a missing 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?

Two tight sentences, front-loaded with the core action and followed by the use case. No filler, nothing 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?

Covers the essentials (what it opens, path rules, when to use it) for a simple one-parameter tool with no output schema. It would be fully complete with a note on what happens to the current active document and error handling for a nonexistent path.

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 100% and the sole parameter is documented there. The description still adds meaning beyond the schema by explaining that the path may be absolute or relative to the art folder, which resolves ambiguity about accepted path formats.

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 action (open an existing .aseprite file and make it active) and names the resource precisely. The word 'existing' implicitly contrasts with aseprite_create_sprite/aseprite_import_image, but no sibling is named 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?

Gives clear context ('to continue work on a file, or to work on art the user already has'), which tells the agent when this tool applies. It stops short of naming the create/import alternatives or stating exclusions, so it's a strong 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?

No annotations are provided, so the description carries the burden. It usefully signals that the value is 'final composited' (i.e., flattened across layers) and gives the return shape ('hex plus RGBA'), which is real behavioral value. But it omits any permission/auth notes, coordinate-space semantics, and whether hidden layers count.

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 short sentences, front-loaded with the action and followed by the return format. No filler; every phrase 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?

There is no output schema, so the description's 'Returns hex plus RGBA' is necessary and helps. However, with no annotations and undocumented x/y parameters, the definition leaves key invocation details (coordinate space, frame/layer determinism of 'composited') unstated.

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 only 50%: 'frame' and 'document' are documented, but 'x' and 'y' are bare integers. With no annotations and an incomplete schema, the description should clarify the coordinate origin (canvas vs. sprite bounds) and units, but says nothing beyond 'a single pixel'.

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 ('Read the final composited colour at a single pixel') and implicitly distinguishes itself from the sibling aseprite_inspect_pixels by scoping to one pixel. It is clear, though it never explicitly names that sibling or contrast 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?

There is no when-to-use guidance, no mention of alternatives, and no prerequisites (e.g., whether a document must be open). The agent must infer usage entirely from the description and schema.

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 declares the coordinate origin (top-left, x right, y down), states the non-destructive behavior ('only touches the pixels you supply; everything else is left alone'), and imposes the 'all rows must be the same length' constraint. What is missing is whether the edit is undoable/saved and how errors on mismatched data are surfaced.

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?

Content is front-loaded with the core action and coordinate convention before the two data modes. It is longer than average but nearly every sentence carries information; the numbered naming of the two approaches aids scanning.

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 nested tool with no annotations and no output schema, the description covers the essentials an agent needs: coordinate system, both data formats, transparency semantics, and the non-destructive guarantee. Remaining gaps (undo/save behavior, frame/layer semantics) are minor given the schema documents frame, layer, and document.

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 100%, so the baseline is 3. The description goes further by explaining the two data-passing modes (pixels vs rows+key), with a worked example and the meaning of '.'/null as transparent, plus the row-length constraint. These semantics exceed what the schema alone conveys.

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+resource ('Draw a rectangular block of pixels') and even frames it as 'the main tool for putting actual artwork into a sprite', which scopes its role. It does not, however, explicitly differentiate itself from siblings like aseprite_draw or aseprite_fill_regions.

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 offers strategy advice ('send one small block per part (outline, fill, shading) rather than repainting the whole sprite'), which is genuine usage guidance. But it never says when to prefer this over aseprite_draw, aseprite_fill_regions, or aseprite_text, so alternative selection is left implicit.

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 must carry the full behavioral burden. It does disclose the core effect (pixels are repainted/snapped to the new palette), but never states that this mutates the document destructively, whether it is reversible/undoable, or how remap=false changes behaviour. Adequate but incomplete for a mutation 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?

Two tight sentences, action first and rationale second, with no filler. Every clause 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?

All three parameters are covered by the schema and no output schema exists, so little more is required. However, as an unannotated document-mutating tool it should mention that it rewrites pixel data (and that palette changes are applied), which it only implies.

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 100%, so the schema already documents count, remap and document, making 3 the baseline. The description adds only the algorithm hint (k-means) behind 'count' and nothing on remap or document resolution.

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 effect on the resource ('reduce the artwork to N colours and snap every pixel'), and naming k-means plus the colour-count target distinguishes it from palette siblings like aseprite_set_palette or aseprite_replace_color. It does not explicitly name a sibling, so it lands at a clear-but-undifferentiated 4.

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 when-to-use context ('tame a messy palette', 'hit a retro constraint like 16 colours'), which is more than most siblings offer. It stops short of naming alternatives (e.g. set_palette for an exact palette) or stating when not to use it.

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 one meaningful constraint: the tool refuses to remove the last remaining frame. However it omits other behavioral details an agent would want for a destructive operation, such as whether deletion is undoable, what happens to cels/tags on the deleted frame, or what the call returns.

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 short sentences with zero filler; the action is front-loaded and the key constraint follows immediately. Nothing here wastes the agent's context.

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 simple two-parameter mutation with rich schema coverage and no output schema, the description covers the action and its main guardrail. It falls short on side effects and reversibility, which matter for a delete operation that has no annotations to supply them.

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 100%, so both 'index' and 'document' are already fully documented in the schema, including zero-based indexing and default-to-active-document behavior. The description adds no parameter meaning beyond that baseline.

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 ('Delete a frame'), which cleanly distinguishes it from sibling frame operations like duplicate_frame and move_frame. It stops short of naming an alternative operation, so it is clear but not maximally 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?

No when-to-use context, prerequisites, or alternative routing is given. The refusal condition is a behavioral rule rather than usage guidance, and it never says when to prefer this over moving, duplicating, or reordering frames.

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 supplied, so the description carries the full disclosure burden. It does usefully disclose that layer contents are destroyed along with the layer, which is real behavioral value. However, it says nothing about irreversibility/undo, permission or document-state requirements, or what happens if the layer is referenced elsewhere.

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?

One short sentence, front-loaded with the verb-resource pair, and the destructive scope is appended rather than buried. 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 two-parameter destructive operation with no annotations and no output schema, the definition is minimally adequate: the target and the destructive scope are clear, and the schema handles parameters. It is missing failure modes, reversibility, and any routing to related layer operations, which limits confidence on an irreversible action.

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 100%: both 'name' and 'document' are documented in the schema, including the art-folder/relative/absolute path convention and the active-document default. The description adds nothing beyond that, so the baseline 3 applies.

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 ('Delete') and resource ('a layer'), and adds the scope of deletion. It is clearly distinguishable from siblings like aseprite_remove_frame or aseprite_remove_tag by naming the layer as the target, though it does not explicitly contrast against the closest sibling, aseprite_merge_layer_down.

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 gives no when-to-use guidance, no prerequisites, and no alternatives (e.g., when to merge_layer_down instead, or whether this is the right call for clearing a layer's contents). The agent must infer usage from the name alone.

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, and it only states the deletion. It does not say whether deletion is permanent/undoable, whether the tag must exist first, whether frames tagged with it are affected, or what the response looks like — meaningful gaps for a destructive mutation.

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 wasted words and the action clearly leading. It is efficient, though it could have spent a clause on the tag-existence or irreversibility behavior.

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 low-complexity tool with a fully documented schema, the core action is conveyed. But with no annotations and no output schema, the description leaves undescribed what destruction entails and how failures are surfaced, leaving a modest but 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 100%, so both the tag name and the document selector are already documented in the schema. The description adds nothing beyond the schema, so the baseline 3 applies.

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 (delete) and resource (animation tag) keyed by name, which is enough for an agent to distinguish it from sibling setters like aseprite_set_tag and aseprite_set_loop. However, it makes no explicit distinction from sibling tools, relying on the name itself.

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 aseprite_set_tag (to modify) or what happens if the tag does not exist. An agent must infer usage purely from the verb.

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 document-wide and all-frames scope of the replacement, which is useful behavioral context, but it does not address mutation/permissions/reversibility or what happens to indexed or palette-based colours.

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, front-loaded with the core operation, followed by concise use cases. No filler or redundant restatement.

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 adequately covers the core operation for a tool whose parameters are fully documented in the schema. However, with no annotations and no output schema, it leaves gaps around behavioural caveats, return behaviour, and alternative-tool routing.

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 100%, so the schema already documents every parameter. The description only loosely reinforces the from/to pair and whole-document scope and does not add meaning beyond 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?

The description states a precise verb and resource: replacing every pixel of one colour with another across the whole document. It clearly separates the operation from general drawing or palette tools, though it does not explicitly name sibling alternatives such as set_palette or fill_regions.

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 offers example scenarios ("recolouring a character", "swapping a shade across all frames") but gives no explicit guidance on when to use this tool instead of alternatives like set_palette or fill_regions. Usage is implied through examples rather than stated conditions.

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 key behavioral trait that artwork is not scaled. However, it omits other important behavior for a canvas mutation: whether reducing width/height discards artwork, and how the anchor interacts with resizing. Useful 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 tight sentences with the core purpose front-loaded and the usage example second. Every sentence earns its place with 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 parameterized mutation tool with no annotations, no output schema, and only 50% schema coverage, the description covers purpose and a use case but leaves out resize-specific behavior (shrink effects, anchor default interaction) and any mention of document selection. Adequate but 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 coverage is 50%: anchor and document are documented, but width/height are bare integers. The description does not compensate by clarifying units, range, or how width/height relate to the anchor. The dimension semantics for width/height are left to the obvious enum/min-max in the schema, so a baseline 3 is appropriate.

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 (Change) and resource (canvas size) and crucially distinguishes the effect from scaling by stating 'without scaling the artwork', implicitly separating it from aseprite_scale_sprite. It does not name any sibling outright, so it stops short of full sibling differentiation.

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 a concrete when-to-use context ('add room for an attack animation or breathing space around a character'), which is clear and actionable. It offers no exclusions or explicit alternatives (e.g. use crop to trim), so it falls short of the when/when-not bar.

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 that the operation affects every frame and layer and that non-integer scaling blurs pixels, which is real behavioral context. It omits whether the change is destructive/undoable, how it interacts with the canvas, and whether it applies immediately or must be saved.

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 with the core action front-loaded and the pixel-art guidance following. Nothing is wasted, though the second sentence is advisory rather than operational.

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 mutation tool with no annotations and no output schema, the description covers purpose and scope but leaves the meaning of the two required dimensions unspecified. An agent needs to know whether width/height are target sizes or scale factors before it can call this correctly.

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 only 33% (width and height are undocumented), and the description's 'integer factors like 2 or 4' framing is ambiguous against parameters named width/height. It never clarifies whether the values are absolute pixel dimensions or multipliers, leaving the two required parameters semantically unresolved.

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 (scale) and resource (the whole sprite) with explicit scope: all frames and layers. It does not distinguish itself from the closely related sibling aseprite_resize_canvas, so the agent cannot tell whether to resize the canvas or scale the content from the text alone.

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 a genuine usage hint about integer factors for pixel-art upscaling and blur with non-integer scaling, which is useful. However, it never says when to use this instead of aseprite_resize_canvas or aseprite_transform, which are the obvious competing siblings.

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 behavioral burden. It usefully discloses that the operation targets a range or every frame, but omits side effects such as whether changes are undoable, whether a document must be open, and what the response 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?

Three tight sentences with the core action front-loaded, followed by scope behavior and practical defaults. Every sentence adds useful information without repetition or 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 setter with full schema descriptions and no output schema, the definition is nearly complete: it covers action, scope, and timing guidance. It could be more complete by mentioning mutation side effects or undo behavior, but the schema already covers document and index 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 100%, so the baseline is 3, but the description adds genuine semantic value: it clarifies the interaction of `from`/`to` as a range selector and gives practical meaning for `durationMs` via the 100 ms = 10 fps equivalence and 40–80 ms guidance for fast actions.

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: set frame durations in milliseconds. This is inherently distinct from every sibling tool, none of which manipulate frame timing, so an agent can identify it without opening the 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?

It clearly explains the range behavior when `from`/`to` are given and the fallback to all frames, and gives recommended duration values with a practical example. It does not explicitly compare to alternatives or state when not to use it, but the context is clear.

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 behavioral burden. It says what can be changed but not what happens when the layer is missing, whether changes require the document to be open/active, whether the operation is reversible, or that opacity maps to a 0-255 range. For a mutation tool this is thin.

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 that names the resource and enumerates the four modifiable properties 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?

For a 6-parameter mutation tool with no annotations and no output schema, the schema covers parameter semantics well, but the description omits behavioral caveats (error cases, at-least-one-property requirement, blend mode value set) that an agent needs before invoking.

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 100%, so the schema already documents all six parameters (including the document-resolution rules). The description merely restates the same attribute list and adds no syntax, defaults, or constraints beyond the schema — baseline 3.

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?

Clear verb ("Change") and resource ("layer") plus the specific mutable attributes (opacity, visibility, blend mode, name). An agent can distinguish this from add_layer, remove_layer, and merge_layer_down by the field list, though no sibling is named 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?

Usage is only implied: "set"/"change a layer's" plus the required `name` conveys that this modifies an existing layer rather than creating one. There is no explicit when-to-use, no exclusion against add_layer/merge_layer_down, and no note that at least one property should be supplied.

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 note the effect applies to both playback and export, but does not say whether the range persists in the saved file, what happens when from/to are omitted or inverted, or whether existing loop settings are replaced.

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 scope qualifier comes after the action. It is efficient, though there is little structure to speak of.

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 mutation tool with no annotations, no output schema, and no statement of persistence, defaults, or interaction with tags/playback state. An agent calling it cannot predict side effects or failure modes.

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 100%, so from/to/document are already documented as zero-based indices with an active-document default. The phrase 'of the whole sprite' is the only added meaning, so baseline 3 applies.

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: restricting playback/export looping to a frame range. An agent can tell this is a loop-range setter, distinct from frame-duration or tag tools, though it never names a sibling to differentiate further.

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 when-to-use guidance, no stated prerequisites, and no mention of alternatives such as aseprite_set_tag or aseprite_set_frame_duration. The agent must infer the use case entirely from the one-line purpose.

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 that this REPLACES the palette (destructive) and that in indexed mode it constrains the usable colours — useful context. But it omits permissions, reversibility/undo, and what happens to existing indexed pixels (the schema's remap hints at this but the description doesn't clarify the default 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, front-loaded with the core action and no filler. The second sentence is contextual rather than redundant, though it could be tightened.

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 an annotation-free mutation tool with no output schema, the description covers the core behavior and the indexed-mode consequence but leaves open the fate of existing pixels and reversibility, which an agent would need to call this safely.

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 100%, so the schema already documents colors, document, size, and remap fully. The description adds no syntax or format detail beyond 'explicit colour list,' which merely restates the colors parameter. Baseline 3 applies when the schema does the heavy lifting.

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: 'Replace the document palette with an explicit colour list.' An agent can distinguish this from load_palette/quantize_palette by the word 'explicit,' though the description never names those siblings to make the distinction 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?

Usage is only implied via the indexed-mode sentence ('this is the actual set of colours the artwork can use') and the 'tight, coherent palette' framing. It offers no explicit when-to-use/when-not guidance and never routes to alternative palette tools like load_palette or quantize_palette.

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 upsert semantics ('Create or update'), which is meaningful for a mutation tool, and its downstream effect on export. It does not say what happens when a tag of the same name already exists (overwrite vs. error) or whether the operation is reversible.

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 action and range, followed by useful domain context. No wasted phrasing, though the second sentence is explanatory rather than strictly operational.

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 mutation tool with no annotations and no output schema, the description covers purpose and effect but omits expected preconditions and conflict behavior. The rich schema compensates on parameters, so this is adequate rather than 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 100%, so every parameter is already documented in the schema, which sets the baseline at 3. The description's 'walk frames 0-5' example loosely illustrates the from/to range, but adds no syntax or constraint detail beyond 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 pair (create/update) and resource (named animation tag) plus its scope (frame range), with a concrete example. It clearly separates itself from siblings like aseprite_remove_tag and aseprite_set_loop, and the second sentence explains what a tag actually is.

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 usage by explaining that tags become exported animations and are playable in the timeline, which helps an agent understand intent. However, it never states when to prefer this over siblings such as aseprite_set_loop or aseprite_remove_tag, nor any prerequisites (e.g., an open document).

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 burden, but this is a zero-parameter read-only query with negligible risk. It discloses the key behavioral trait — the content of the report (installation, workspace folders, active document) — though it never explicitly states it is non-destructive.

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 with zero filler, front-loaded with what is reported before the conditional usage instruction. Every clause 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?

With no output schema and no annotations, the description must convey the return value's essence, and it does so at a category level (installation, workspace folders, active document). An agent knows enough to use and trust it; exact field names are unspecified but not essential for a diagnostic 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?

The tool takes no parameters, so per the rubric the baseline is 4. There is nothing further the description could add about parameter semantics.

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 ('Report') and three concrete resources (Aseprite installation, workspace folders, active document). This is the only diagnostic/status tool among the ~40 siblings, which are all mutation or export operations, so an agent can distinguish it immediately.

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 two explicit usage triggers: 'Call this first if a tool fails' and 'to learn where files are being written.' Clear context for when to invoke, though there is no explicit when-not guidance or named alternative (there is no sibling that overlaps, so that omission is minor).

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 that the font is fixed at 5x7 and that non-ASCII characters degrade to "?" — a real behavioral caveat — but it never states that this mutates the target document/frame/layer, what happens on out-of-bounds coordinates, or any permission requirements.

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 sentences, front-loaded with what the tool draws, followed by use cases, a limitation, and a parameter tip. No filler; every sentence adds actionable 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 an 8-parameter drawing tool with no annotations and no output schema, the description covers font, use case, encoding limitation and scaling but omits the mutation semantics (which document/frame/layer gets altered) and error behavior. Adequate but with a real gap around what the call changes.

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 already 88%, so baseline is 3, and the description earns above that by adding non-obvious guidance on the scale parameter (crisp results at 2 or 3) and the ASCII restriction on text that the schema's "ASCII text to draw" only hints at.

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 — drawing text with a named built-in 5x7 pixel font — which clearly separates it from the generic aseprite_draw sibling. The font identity and size constraint make the purpose unambiguous, though it never explicitly names how it differs from aseprite_draw.

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?

"Suitable for labels, UI mockups and small titles" gives concrete usage context, and the scale advice ("Use scale 2 or 3 for larger text") tells the agent how to handle a common variant. No when-not guidance or named alternative is provided, so it stops short of a 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 at all, the description carries the full behavioral burden and falls short: it never says the operation mutates the active document in place, whether it is reversible/undoable, or what happens to layers/frames not targeted. The one behavioral fact it does add -- the outline is fixed at 1 px (no width parameter exists in the schema) -- is genuinely useful but not enough.

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, front-loaded with the three actions. The second sentence about outlines reading clearly against backgrounds is flavor, but it is short and clarifies the intent of the outline action, so it earns most of 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?

For a 9-parameter, in-place mutation tool with no annotations and no output schema, the description is only minimally sufficient. It conveys what the actions are but omits mutation semantics, scope defaults, and any interplay between action/target/frames that an agent must get right.

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 100%, so every parameter is already documented and the baseline is 3. The description adds the fixed 1 px outline width, which is not represented in the schema at all, and restates the rotation angles; it adds modest value but no syntax or interaction detail beyond that.

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 three specific verbs (flip, rotate, outline) applied to 'the artwork', with the rotation angles spelled out. No sibling tool overlaps with these transforms (resize/crop/scale are geometry changes of a different kind), so an agent can route here unambiguously.

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 choose this over alternatives, no prerequisite or state notes, and no mention of which document/layer context is used. The single hint is 'artwork', which is not an actionable condition.

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 dual output mode (PNG plus optional ASCII character map) and hints at the verification purpose, but says nothing about whether the document is mutated, where the PNG goes, or how the render is returned to the agent.

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-loads the core action in the first clause and keeps the whole thing to a few tightly packed sentences. The parenthetical workflow advice ("before telling the user the piece is finished") is slightly chatty but earns its place as usage 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?

No output schema and no annotations, so the description should disclose what actually comes back. It explains the ASCII alternative but not the PNG return shape or scale/layers defaults, leaving a gap for a tool whose entire value is the rendered result.

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 100%, so all five parameters are already documented. The description only re-states includeAscii ("also get an exact character map") and adds no syntax or interaction detail beyond the schema, so the baseline 3 applies.

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 ("Render a frame to a PNG image") and frames the intent as inspecting artwork rather than exporting it, which implicitly separates it from aseprite_export_png and aseprite_export_sprite_sheet. It never names those siblings, so the differentiation is left to inference.

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 timing guidance ("Use this after drawing, and before telling the user the piece is finished"), which tells the agent when in the workflow to call it. There is no explicit when-not or named alternative, keeping it short of a 5.

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