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

With no annotations, the description carries the full burden. It does usefully disclose that the tool reports a 'connection status with Aseprite' (implying it is callable even when disconnected) and enumerates the returned data, but it never explicitly states that it is read-only / side-effect free or what happens when no document is open.

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 field enumeration is long but justified because there is no output schema to describe the return shape.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read tool with no output schema and no annotations, enumerating the returned fields (dimensions, color mode, layers, frames, active layer/frame, revision) is exactly the missing information. It stops short of describing the structure or types of those values, which is a minor 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?

The tool takes zero parameters, so the baseline is 4. Nothing in the description is needed to explain arguments, and none are introduced.

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 ('Returns') and resource ('connection status with Aseprite, open document details...') and enumerates the exact payload contents. It does not distinguish itself from siblings with overlapping scope such as get_sprite_info, inspect_sprite, or get_canvas, so an agent cannot tell which status-like tool to prefer.

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 call this versus get_sprite_info, inspect_sprite, get_canvas, or list_layers/list_frames, which appear to return overlapping data. No prerequisites (e.g., an active Aseprite connection) are stated either.

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 that the new frame is blank and where it is placed, but says nothing about side effects such as selection changes, undo behavior, or sprite modification.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, well-formed sentence with no wasted words. The key operation and placement behavior are front-loaded and easy to parse.

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 tool, the description is adequate but not complete. It omits when to use this versus duplicating a frame, and it does not mention whether the new frame becomes selected or how errors are handled.

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 both parameters fully. The description adds only the 'specified frame or at the end' placement concept, which is already covered by the afterFrame parameter description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Creates a new blank animation frame') and clarifies the insertion position. The word 'blank' distinguishes it from duplicate_frame, which would copy an existing frame.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains where the frame is inserted but gives no guidance on when to choose this tool over duplicate_frame or other frame creation approaches. No prerequisites or alternatives are mentioned.

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 does not say whether the group is created at the top level or nested under the active layer, whether the new group becomes selected, what happens on name collision, or whether the parent group must exist — all of which matter for a hierarchy-mutating tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single efficient sentence with the key action and resource front-loaded and no wasted words. It is arguably under-specified rather than padded, but nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a creation tool with no annotations and no output schema, the description should at least describe nesting behavior and what is returned (e.g., the new group's identifier). It omits these, leaving the agent unable to predict the operation's effect on the layer tree.

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 there is a single 'name' parameter documented in the schema, so the baseline is 3. The description adds no naming constraints, uniqueness rules, or format details beyond what the schema already states.

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 (creates) and resource (folder layer group for organizing layers), and the word 'folder' distinguishes it from the sibling create_layer. However, it never explicitly contrasts itself with create_layer, so an agent must infer the relationship between the two tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus create_layer, no prerequisites (e.g., must a sprite be open or a layer selected?), and no exclusions. The agent is left to guess based on 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. It states that the operation creates a layer in the active sprite but does not disclose side effects such as selection changes, undo behavior, required permissions, or what happens on failure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single front-loaded sentence with no redundant or filler content. Every word contributes to conveying the tool's action and target scope.

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 tool is a simple two-parameter mutation, but it has no annotations and no output schema. The description covers the core action and the active-sprite scope, but omits side effects, return details, and when to choose it over sibling creation tools, leaving clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents 'name' and 'parentGroup' as an optional parent group folder. The description adds no parameter syntax, defaults, or format guidance 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?

The description pairs the verb 'Creates' with the resource 'image layer' and scopes it to the active sprite, so the tool's function is immediately clear. It does not, however, contrast itself with sibling tools such as create_group or create_frame, leaving sibling differentiation mostly to the tool name.

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 conditions, prerequisites beyond 'active sprite', or alternatives such as create_group for folders. It merely states what the tool does, leaving the agent to infer when it is appropriate.

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 for a mutation tool. It does not say whether tag names must be unique, what happens on a duplicate name, whether the tag persists to the file, or what happens if fromFrame/toFrame exceed the sprite's length.

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 the verb first and no wasted words. It is efficient, though the brevity leaves little structure to work with for a four-parameter mutation tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description is too thin: it omits uniqueness constraints, error behavior, and whether the new tag is returned or how it is confirmed. The schema covers parameter shapes but the description should carry the rest.

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, including the name examples the description repeats. The description adds only the framing that fromFrame/toFrame define a range, which is already evident from the schema; 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 ('Creates an animation tag') plus the scope it applies to ('a range of frames'), which is enough to separate it from list_tags. It stops short of explicitly contrasting itself with any sibling tool, but the purpose 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?

The description gives no when-to-use guidance, no prerequisites (e.g. a sprite must be open), and no mention of alternatives such as list_tags for inspecting existing tags. Only implied usage is available 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 behavioral burden. It does disclose the hard requirement of confirm:true, which tells the agent the call will be rejected otherwise, but it says nothing about irreversibility, whether the deletion can be undone/redone, or what happens to adjacent frame numbering.

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 then the blocking precondition. Every word earns its place with no padding.

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 destructive, unannotated mutation with no output schema, the definition is thin: it omits reversibility/undo behavior, failure modes, and any post-delete state description. The confirm gate is covered, but the rest of the behavioral picture an agent needs 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 description coverage is 100%: the schema already documents frameNumber as 1-indexed with exclusiveMinimum 0 and confirm as a required boolean. The description merely restates the confirm requirement and adds no new semantics, 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?

The description gives a specific verb and resource ('Deletes an animation frame'), which is unambiguous and distinct from siblings like delete_layer or duplicate_frame. It stops short of differentiating itself from any alternative deletion path or stating scope, so it is clear but not maximally informative.

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 tool versus alternatives, nor any precondition or caution beyond the confirm flag. Nothing tells the agent when deletion is appropriate or what to do first (e.g., verify the frame number).

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 the confirm safety gate but not whether deletion is irreversible, whether it can be undone, or what happens to the layer's pixel content and its position in the stack.

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 its scope, with the safety constraint immediately following. Nothing 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?

A destructive, unannotated tool with no output schema should disclose irreversibility and undo behavior; those are missing. The confirm gate and full schema coverage keep it minimally viable.

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 both parameters are already explained in the schema. The description restates the confirm requirement but adds no syntax or format meaning beyond it, 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?

Specific verb+resource: 'Deletes a layer from the active sprite.' The scoping to 'active sprite' plus the layer resource clearly separates it from delete_frame, rename_layer, and the other layer siblings, 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?

No when-to-use guidance versus alternatives (e.g., set_layer_visibility=false to hide instead of deleting, or undo for reversal). The only conditional mentioned is the confirm parameter, which is a requirement rather than usage guidance.

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

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

With no annotations, the description carries the full burden. It usefully discloses that the operation is wrapped in a single undo transaction, which tells the agent the draw is atomic and reversible. However, it omits which layer/frame is targeted, permission needs, and 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?

A single front-loaded sentence with no wasted words; the core action leads and the transactional detail trails.

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 drawing tool with no annotations and no output schema, the description is thin. It covers purpose and atomicity but leaves layer/frame targeting and the returnPreview behavior unaddressed, which matters for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 60%, so the schema documents the bounding-box and color params while layerName, layerIndex, frameNumber, and returnPreview remain bare. The description's 'bounding box' and 'outline or filled' phrasing reinforces the x/y/width/height and filled params but adds no meaning to the undocumented targeting params.

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 (draws an ellipse) and adds scope detail (outline or filled, within a bounding box). It is distinguishable from siblings like draw_rectangle and draw_line by shape, 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as draw_rectangle or flood_fill. The only contextual note is the atomic undo behavior, which is a behavioral trait rather than usage 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?

With no annotations, the description carries the full burden, and it does disclose two meaningful traits: Bresenham's algorithm (deterministic rasterization) and a single undo transaction (atomicity). However, it omits permissions, how layer/frame defaults are resolved, and what returnPreview changes about the response, so mutation behavior is only partially covered.

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 that still conveys the algorithm and the transactional guarantee. Nothing is redundant or buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter mutation tool with no annotations and no output schema, the description covers the core draw behavior adequately but leaves several parameters and the returnPreview behavior unexplained. It is minimally sufficient 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?

The description only restates x1/y1/x2/y2, which the schema already documents. With 60% schema coverage, the undocumented parameters (layerName vs layerIndex, frameNumber, returnPreview) are explained in neither the schema nor the description, and no added meaning is provided for any parameter.

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 ('Draws a pixel art line') with the endpoints and algorithm named, which clearly distinguishes it from draw_rectangle, draw_ellipse, and flood_fill. It is unambiguous what the tool produces, though it does not explicitly call out sibling alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the verb 'draws a line' but there is no explicit when-to-use guidance or comparison against related tools like set_pixels or draw_rectangle. The agent can infer the context but receives no routing help.

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 trait: the draw happens 'in a single undo transaction' (atomic, undoable). However, it omits where the rectangle lands (current layer/frame by default), any auth/permission needs, and what returnPreview triggers.

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 efficient sentence with no waste, and the core action plus the undo-transaction note are front-loaded. Nothing redundant against the name or schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter mutation tool with no annotations and no output schema, the description covers the core action but leaves the layer/frame targeting params and the preview behavior to inference. Adequate but with clear gaps given the tool's complexity.

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%, so the schema already documents x, y, width, height, color, and filled. The description's 'outline or filled' maps to the filled flag, but the four undocumented params (layerName, layerIndex, frameNumber, returnPreview) get no added 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 ('Draws') and resource ('a rectangle... on the canvas'), and the parenthetical 'outline or filled' clarifies the mode. It is trivially distinguishable from siblings draw_line, draw_ellipse, and flood_fill by resource.

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 offers no when-to-use context, no prerequisites, and names no alternatives. It does not tell an agent when to prefer draw_rectangle over flood_fill or set_pixels for filling an area.

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

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

No annotations, so the description carries the full behavioral burden for a mutation tool. It says what is copied (cels) but not where the duplicate is inserted, whether the new frame becomes selected, what happens to tags or frame durations, or whether the source must be selected first.

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 short sentence with no filler, front-loaded with the action. It is efficient, though its brevity contributes to the missing behavioral detail noted elsewhere.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and no annotations, but the operation is simple and the schema is self-documenting for its one parameter. The description is minimally adequate, though an agent still lacks the post-conditions (insertion position, selection state) needed to chain it confidently with select_frame or set_frame_duration.

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 single parameter is fully documented in the schema (1-indexed frame number with exclusiveMinimum 0). The description adds no parameter detail, 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 (Duplicates) and resource (frame), and adds scope detail ('and its cels') that tells the agent exactly what is copied. It does not, however, distinguish itself from the sibling create_frame or indicate how the result differs from manually creating a frame.

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 guidance, no conditions, and no mention of the obvious alternative create_frame. The agent must infer that duplication is preferable when the caller wants an identical copy rather than an empty frame.

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 load, and it does disclose two meaningful traits: the exact effect (transparent #00000000) and atomicity ("a single undo transaction"). It omits other relevant behavior such as layer-resolution rules, error handling, and whether partial erasures are possible.

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; the verb, mechanism, and atomicity are all packed economically into one line.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter mutation tool with no annotations and no output schema, the description covers the core effect and undo semantics but leaves gaps around return values, layer targeting, and failure modes. 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 layerName/layerIndex/frameNumber/returnPreview are already documented. The description adds no additional parameter meaning (e.g., precedence between layerName and layerIndex), so 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 states a specific verb ("Erases") and resource ("a list of pixel coordinates") plus the exact mechanism ("turning them transparent (#00000000)"). This implicitly distinguishes it from set_pixels/set_pixel, though it never names a sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to choose this tool over set_pixels, replace_color, or the drawing primitives. Usage is only implied by the word "erase," with no conditions or exclusions stated.

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, yet it omits key traits: whether an existing file at outputPath is overwritten, whether the write can fail or require permissions, and whether the operation affects editor state. 'On disk' confirms a filesystem side effect, but nothing about its consequences is disclosed.

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. It is efficient, though the brevity comes at the cost of the missing behavioral and usage detail noted elsewhere.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no annotations, so the description should describe the return result and side effects; instead it says nothing about what a successful export yields (path, confirmation) or about overwrite behavior. For a filesystem-writing tool with three parameters, this leaves material gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with each of the three parameters individually documented (scale's nearest-neighbor semantics, the .png target path, and a specific frame number). The description adds only the vague notion of exporting 'the active sprite or frame,' which does not extend meaning 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 (exports) and resource (active sprite or frame) plus the output format (PNG file on disk), so the fundamental action is unambiguous. It does not, however, distinguish itself from sibling tools like save_sprite or save_sprite_as, which also persist sprite data, so an agent must infer the difference between raster export and native save.

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 guidance on when to choose this over save_sprite/save_sprite_as, nor any prerequisites (e.g., must a sprite be open, does it operate on the active sprite only). Usage is implied solely by the word 'Exports'.

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, but it does disclose a genuine behavioral trait: matching is done by Euclidean distance and falls back to nearest. It does not say what is returned (palette index, hex, match distance) or what happens when findNearest is false and no exact match exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler, and the key qualifier ('active palette', 'Euclidean distance') is placed where it is read first. 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 two-parameter lookup with full schema coverage the description is serviceable, but there is no output schema, so the return shape (index vs. hex vs. match quality) is left unexplained. The no-match behavior when findNearest is false is also unaddressed.

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 both parameters are documented in the schema itself (hex format example, findNearest default). The phrase 'exact or nearest color match' loosely maps to findNearest but adds no format or threshold detail beyond the schema. 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?

States a specific verb (finds) and resource (color match in the active palette), which is enough for an agent to distinguish it from get_palette and set_palette_color. It does not explicitly name a sibling or scope boundary, but the lookup-versus-mutation distinction is implicit in 'finds'.

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 or mention of alternatives. Nothing tells the agent to prefer this over get_palette when it just needs to enumerate swatches, or what to do when matching against a non-active palette. Only the bare purpose is stated.

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 full burden, and it does disclose one valuable trait: the fill occurs in a single undo transaction. However it is silent on layer/frame targeting rules, how tolerance affects matching, and whether an active sprite/layer must already be selected.

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 tight sentence with the seed point and the undo-transaction detail front-loaded; no filler. Size is appropriate for the operation, though it trades some needed detail for brevity.

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 mutation tool with no annotations and no output schema, the description leaves half the parameters unexplained and says nothing about targeting a layer/frame or what returnPreview returns. It is under-specified for the complexity of the call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%: x, y, color, and tolerance are documented in the schema, but layerName, layerIndex, frameNumber, and returnPreview have neither schema nor description guidance. The description repeats the seed-point and color semantics already in the schema and adds nothing for the undocumented layer/frame targeting parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Fills) and resource (contiguous area of matching pixels) and names the seed point, which is more precise than a generic 'fill'. It implicitly contrasts with siblings like replace_color and set_pixels, but never names them, 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?

The description implies when flood fill applies (contiguous matching region from a seed), but offers no explicit when-to-use vs when-not, and does not point to replace_color for global replacement or to drawing tools for shapes. Usage is implied by the well-known operation rather than stated.

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 burden. It usefully discloses the output form (official MCP image content) and the nearest-neighbor rendering behavior, but says nothing about prerequisites (an active sprite/document must exist), read-only nature, or failure modes.

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 zero waste, front-loading the core action and output format. 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?

No output schema exists, but the description compensates by stating it returns MCP image content. However, without annotations it omits prerequisites, read-only confirmation, and error behavior, leaving meaningful gaps for a rendering tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters (scale, layerName, frameIndex, checkerboard) are already documented in the schema. The description only echoes the nearest-neighbor scaling concept for the scale param, adding no meaning 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?

The description pairs a specific verb ('Renders') with a clear resource ('the active sprite canvas/frame') and states the output format ('PNG image'). It does not explicitly differentiate from close siblings like export_png or get_pixel_grid, but the render-as-image framing is clear.

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 explicit guidance on when to use this versus alternatives such as export_png (file output) or get_pixel_grid (raw pixel data). The distinction is only weakly implied by the phrase 'Returns official MCP image content'.

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 adds the useful behavioral trait of returning only modified regions and pixel deltas, which clarifies output nature. However, it omits details like what constitutes a 'modified region' (format, granularity) and any performance or permission considerations.

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 efficiently conveys purpose and benefit without any fluff. Every clause earns its place by clarifying the differential nature and the avoidance of full reads.

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 the simple one-parameter tool and lack of output schema, the description is largely complete. It explains what is returned (modified regions and pixel deltas) and the efficiency benefit. It could be improved by specifying the return structure or revision format, but for a diff tool this is adequate.

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 parameter 'sinceRevision' is documented in the schema as 'Base revision to diff against.' The description adds no additional meaning beyond what the schema provides, 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 and resource: returns modified regions and pixel deltas since a revision. The phrase 'Differential inspection' and mention of avoiding full canvas re-read clearly distinguishes this from get_canvas and get_pixel_grid.

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?

Implies usage context with 'avoiding re-reading the entire canvas,' suggesting it's for efficient delta tracking. However, it does not explicitly state when to choose this over get_canvas or get_pixel_grid, nor does it mention any prerequisites.

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 the return content and implies a safe read operation, but does not state side effects, required active-sprite context, error behavior, or palette-size limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no wasted words. It efficiently communicates the resource, scope, and return shape.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read tool with no output schema, the description sufficiently covers what is retrieved and what the returned values contain. It could be slightly more complete by noting behavior when no sprite is active or the palette is empty, but the core context is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so the baseline is 4. The description adds no parameter semantics beyond what the empty schema already shows, but no parameter explanation is needed for this tool.

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 ('Retrieves'), resource ('all colors in the active sprite's color palette'), and output fields (index, RGBA, HEX). This clearly distinguishes it from siblings like set_palette_color and find_palette_color, which respectively mutate or locate a single color.

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 explicit guidance on when to use this tool instead of alternatives such as find_palette_color or set_palette_color. The description implies palette inspection, but it provides no when/when-not conditions or routing instructions.

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 coordinate system and output format options, but omits permissions, side effects (though 'Returns' implies read-only), and return structure. It adds some useful behavioral context but remains 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?

One sentence, front-loaded with purpose and coordinate system, with a compact parenthetical listing format options. No wasted words.

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 tool with five parameters, nested region object, no annotations, and no output schema, the description covers purpose, coordinates, and output formats. It lacks explicit return shape and layer/frame selection behavior, but the schema fills in defaults and constraints.

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 baseline is 3. The description adds meaning beyond the schema by specifying absolute canvas coordinates with origin (0,0) top-left, which clarifies how region x/y are interpreted, and by labeling compact as token-saving. Other parameters are already well covered by 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 ('Returns') and resource ('exact pixel values from the canvas or cel'), plus scope in absolute canvas coordinates. It distinguishes itself from get_pixel_grid_preview through the emphasis on 'exact' values, but does not explicitly name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use, when-not-to-use, or alternative guidance. The description implies pixel inspection but does not help an agent choose between get_pixel_grid, get_pixel_grid_preview, get_canvas, or inspect_sprite.

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

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

No annotations exist, so the description carries the full behavioral burden. It usefully discloses the rendering behavior (nearest-neighbor scaling, grid separators, rulers, optional highlights), but says nothing about whether the operation is read-only/non-destructive, whether it mutates sprite state, or how the PNG is delivered back to the caller.

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 output first and then lists the visual features. No filler, no repetition, and the most important information (what is generated) leads.

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 seven (all-optional) parameters, nested highlight objects, and no output schema, the description should clarify the return mechanism for the generated image (inline image, file path, base64, etc.) and whether frames must be selected first. It explains the visual content but leaves these call-critical details unspecified.

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 (scale, showGrid, frameIndex, checkerboard, highlightPixels, highlightRegion, showCoordinates) is already documented in the schema. The description restates a few of these (grid separators, rulers, optional highlights) without adding format, constraints, or interaction details, 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 ("Generates") and a precise resource ("enlarged visual inspection PNG") and enumerates the rendering features (nearest-neighbor scaling, 1px grid separators, X/Y rulers, highlights). An agent can tell what comes out, but the description never differentiates this from sibling preview/read tools like get_pixel_grid, get_canvas, inspect_sprite, or 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?

No when-to-use, when-not-to-use, or alternative guidance is given. With four sibling tools that all produce visual output (get_canvas, get_pixel_grid, inspect_sprite, export_png), the absence of any routing condition is a real gap; the agent must infer usage purely from the name.

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

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

No annotations exist, so the description carries the full burden. 'Returns' implies a read-only getter, and the enumeration of returned fields partially compensates for the absent output schema, but it says nothing about side effects, error behavior when no sprite is active, or any permission/state 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?

A single front-loaded sentence with no filler. Every enumerated item is load-bearing because there is no output schema describing the return shape.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter getter with no output schema and no annotations, enumerating the returned fields is exactly the right compensation and covers most of what an agent needs. The remaining gap is error/edge-case behavior (e.g. what happens with no active sprite), which is not addressed.

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 zero parameters, so there is nothing to document; the baseline of 4 applies. The description correctly does not waste space inventing 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 ('Returns') and resource ('structural information about the active sprite'), then enumerates exactly what is returned (dimensions, color mode, layers, frames, active layer/frame, revision). This distinguishes it from pixel-oriented siblings like get_pixel_grid, but it never differentiates itself from inspect_sprite or get_canvas, which sound like overlapping reads.

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 explicit statement of when to use this tool versus alternatives. The phrase 'complete structural information' implies a full-state snapshot use case, but the agent is given no condition, prerequisite, or named alternative (e.g. inspect_sprite, get_canvas) to route between them.

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

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

With no annotations, the description must carry the whole behavioral burden, and it does disclose the response payload (PNG image, dimensions, active layer/frame, revision, pixel matrix) in one call, which is genuinely useful. It still omits that this is a read-only/no-mutation operation, how the includePixels flag/token cost behaves, and any auth or rate-limit context.

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 tool's role and then the payload, with no wasted clauses. The 'PRIMARY VISION TOOL' tag is mild framing rather than wasted space, so it lands just short of a 5.

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 correctly enumerates the returned artifacts, and combined with the 100%-covered input schema an agent has enough to invoke it. It stops short of clarifying read-only status or how the pixel grid interacts with the format/includePixels 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 four parameters (scale, format, frameIndex, includePixels) are already documented in the schema. The description only alludes to the pixel matrix and adds no syntax or default guidance 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 (inspects) and resource (active sprite) and enumerates what a single call returns, which is more than the name conveys. It labels itself 'PRIMARY VISION TOOL' but never names or contrasts the overlapping siblings (get_pixel_grid, get_pixel_grid_preview, get_sprite_info), so an agent must still guess which inspection tool to reach for.

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?

'PRIMARY VISION TOOL' implies this is the default first look at visual state, which is useful implied usage. However, there is no explicit when-to-use vs. get_sprite_info/get_pixel_grid_preview, and no exclusion criteria; the routing decision is left to inference.

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

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

No annotations are provided, so the description carries the full burden, but for a zero-parameter read-only listing there is little risk to disclose. It does reveal the return content (frame numbers and durations in milliseconds), which is the key behavioral trait, though ordering and scope (all frames vs. selected) are not clarified.

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; every clause (frames, frame numbers, durations in milliseconds) adds 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?

With no output schema, the description must describe the return value, and it does specify frame numbers and durations in milliseconds. It omits ordering and whether additional frame metadata is included, but it is sufficient for a simple no-argument listing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4. There are no parameter semantics to clarify and the description correctly adds none.

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 (lists) and resource (animation frames) plus what each entry contains (frame numbers and durations in ms). It is clearly distinguishable from mutation siblings like create_frame/delete_frame, though it does not explicitly contrast with read siblings such as get_sprite_info.

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 statement of when to use this tool versus alternatives, nor any prerequisites or exclusions. Usage is only inferable from the tool name and surrounding 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?

No annotations are provided, so the description carries the full burden. It discloses the information returned (visibility, opacity, blend mode, hierarchy position), which is helpful and especially valuable since there is no output schema, but it does not state that the operation is read-only/non-mutating or describe error/pagination 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?

A single front-loaded sentence with no redundancy; every clause earns its place by naming the resource, scope, and returned fields.

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 parameterless read tool with no output schema, the description adequately covers what the agent needs by listing the returned fields. It could be more complete by noting the read-only nature or failure conditions, but the essentials are present.

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 zero parameters, so the baseline is 4. The description adds no parameter context, but none is needed given the empty 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 uses a specific verb ('Lists') and resource ('layers') scoped to the 'active sprite', and enumerates the returned fields, so an agent immediately knows what it does. It does not explicitly contrast itself with the many layer-mutation siblings (create_layer, delete_layer, etc.), but the 'list' verb makes the read variant distinguishable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the 'Lists all layers' phrasing - call it to enumerate layers - but there is no explicit when-to-use guidance, no prerequisites, and no alternative named. Adequate but leaves the agent to infer the 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?

No annotations are provided, so the description carries the full burden. It confirms a read operation implicitly ('Lists') but adds no behavioral context about output format, ordering, empty state, or caveats. With zero annotation coverage, 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 with no filler. Every word 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 zero-param list tool with no output schema, this is minimally adequate. The description could clarify the return format (e.g., tag names vs. objects) since no output schema exists to carry that information.

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 zero parameters, so the baseline is 4. The description correctly implies no inputs are needed, consistent with the empty 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?

Clear verb (Lists) and specific resource (animation tags defined in the sprite). It is distinguishable from sibling create_tag, though it doesn't explicitly name the alternative. Scope is well-defined.

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 guidance or mention of alternatives. The description doesn't state that this is a read-only inspection tool versus the create_tag sibling, nor any context for when an agent should call 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?

No annotations are provided, so the description carries the full behavioral burden. It omits whether index 0 is top or bottom, what happens on out-of-range indexes, whether the move is undoable, and whether it affects the currently selected layer or group nesting — significant gaps 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 front-loaded sentence with no filler. It states the operation immediately and wastes nothing.

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 should say more: index orientation, boundary behavior, side effects, and success semantics are all absent. What exists is accurate but far too thin to call the definition 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 'name' (layer to move) and 'targetIndex' (destination stack index) are already documented in the schema. The description adds only the notion of a 'layer stack', which is baseline context, so a 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 specific verb ('reorders') and resource ('a layer position in the layer stack'), which is clear and unambiguous. However, it does nothing to distinguish itself from adjacent siblings such as rename_layer, select_layer, or delete_layer beyond the verb 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?

The description gives no when-to-use guidance, no prerequisites (e.g., layer must exist), and never names an alternative approach. An agent must infer that this is the reorder operation rather than, say, delete-plus-create.

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 a new document is created but never states whether the existing sprite is replaced or a new tab opened, whether anything is persisted to disk, or what the return value is — significant gaps for a creation 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 front-loaded sentence with no filler; the verb and resource lead. It is efficient, though the trailing 'with specified dimensions and color mode' is largely redundant with the schema.

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 tool is simple (3 optional params, all defaulted, no output schema), and the description covers the essential action. However, with zero annotations and no output schema, it omits whether the created sprite becomes the active document and what happens to any currently open sprite.

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%: width, height (with defaults, exclusiveMinimum 0, max 4096) and the colorMode enum are fully documented in the schema. The description only echoes 'dimensions and color mode' and adds no format or constraint detail beyond it, 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?

Specific verb+resource: 'Creates a new blank sprite document in Aseprite' with the configurable dimensions and color mode named. It is clearly distinguishable from open_sprite and create_frame, though it does not explicitly contrast itself with those siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No statement of when to use this tool versus alternatives such as open_sprite (open existing) or resize_canvas. No prerequisites or exclusions are given; 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 burden. It does not disclose whether opening replaces the current document, what happens to unsaved changes, whether the file must exist, or what the call returns – all relevant for a tool that mutates application state.

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; nothing is repeated from the schema and nothing extraneous is included.

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 one-parameter tool with a fully documented schema and no output schema, this is adequate but thin. The absence of annotations means the description should have covered side effects on the current document, which it does not.

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 single parameter's 'absolute file path' meaning is fully documented in the schema. The description adds only the supported extension list, so 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?

States a specific verb (opens) and resource (existing sprite file) plus the supported formats (.ase, .aseprite, .png). It is distinguishable from new_sprite through the word 'existing', though that sibling is never 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?

There is no guidance on when to use this versus new_sprite, nor any prerequisites such as whether the current sprite must be saved first. Usage is only implied by the word 'opens'.

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 some burden shifts to the description. It discloses the mutation ('redoes ... editing operation') and that it acts on the redo stack of the active sprite, but does not say what happens when the redo stack is empty, whether the action is reversible, or which sprite state is affected — modest disclosure 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 sentence with zero filler, front-loaded with the verb and immediately qualifying which operation is redone. Every word earns its place and nothing is repeated from the schema or annotations.

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 no-parameter, no-output-schema, single-action tool the description is nearly complete, but with no annotations and no return contract it leaves unstated the edge behavior (empty redo stack) and any restriction on the target sprite. Those gaps are minor for such a simple tool, keeping it just short of full completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters, the baseline is 4; the description correctly adds no parameter noise because there is nothing to parameterize. No further semantic gain is possible or needed here.

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 (redoes) and its precise object (the most recently undone editing operation on the active sprite). It sits clearly opposite the sibling 'undo' and cannot be confused with any other tool — the operation, target, and locus (active sprite) are all pinned 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 implies the when: redo applies only after an undo has occurred, and scope is limited to the active sprite. It does not explicitly name alternatives or state the precondition (e.g., that a redo stack must be non-empty), so it stops short of an explicit when/when-not pairing.

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 hints that the layer must already exist ('existing layer'), but says nothing about name collision handling, case sensitivity, undo/reversibility, or permissions for a mutation operation.

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 or repetition. It is appropriately terse for a simple tool, though extremely minimal.

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 is too sparse. It omits error conditions, whether the new name must be unique, and how the rename affects other references, leaving real gaps an agent would need filled.

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 both parameters ('oldName' and 'newName') are fully documented in the schema. The description adds no additional meaning beyond what the schema already provides, 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 (renames) and resource (layer), so the agent knows exactly what the tool does. It does not explicitly differentiate from sibling layer tools such as move_layer or set_layer_visibility, but the action is unambiguous on its own.

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 tool versus alternatives, nor any prerequisites or conditions. The usage is only implied by the verb 'renames', leaving the agent to infer 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, and it does disclose one genuinely useful trait: the operation happens in 'a single undo transaction', so the agent knows the whole replacement is atomic and reversible in one step. It says nothing about the returnPreview behavior, tolerance handling, or whether layerName/frameNumber restrict the affected region.

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 front-loaded and no filler. It is dense but every clause carries information, so it is appropriately sized for the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a mutation tool with no annotations, no output schema, and four of six parameters undocumented, yet the description only covers the atomic-undo trait. An agent still lacks the meaning of tolerance, the scoping effect of layerName/frameNumber, and what returnPreview produces.

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%: only toColor and fromColor are documented, and the description merely restates them rather than adding meaning. The four undocumented parameters (layerName, tolerance, frameNumber, returnPreview) are unexplained anywhere, and the description does not compensate for that gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Replaces all occurrences of fromColor with toColor') plus the scope ('across the cel or sprite'), which is enough to distinguish it from siblings like flood_fill or set_pixel. It does not name a sibling explicitly, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this versus alternatives such as flood_fill, set_pixels, or set_palette_color, nor any prerequisites or exclusions. Scope is implied by the phrase 'across the cel or sprite' but the agent must infer when a global color swap is the right call.

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 mentions no interpolation or blurring, which is useful, but omits whether existing pixel content is preserved, cropped, or repositioned, whether the operation is reversible, and what permissions or context are required.

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 sentence that is front-loaded and wastes no words, though it is very short and could benefit from slightly more context without becoming verbose.

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, no output schema, and only 3 parameters, the description is too thin. It should clarify what happens to existing content (preservation, cropping, padding) and whether undo is supported.

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 width, height, and anchor including enum values and a default. The description adds no parameter-level detail beyond the schema, 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 and resource ('Resizes the active sprite canvas dimensions') and clearly distinguishes from pixel-drawing siblings by noting it does not interpolate or blur. It does not, however, name or differentiate from a sibling like create_frame or set_pixels 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?

No guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description simply states what it does.

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 disclosure burden. It does add one genuinely useful behavioral trait: saving is not implicit/automatic and occurs only on explicit request. It does not say whether an existing file is overwritten, which path/target is written, or what happens on failure.

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, with no filler beyond the parenthetical. The parenthetical largely restates 'Explicitly', so there is minor redundancy, but the definition stays tight.

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 zero-parameter tool with no output schema, the core is present, but a disk-mutating tool with no annotations should say more: where the file is written, whether it overwrites, and how it differs from save_sprite_as in the sibling set. Those gaps keep it merely adequate.

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 schema has zero parameters, which is the baseline-4 case per the rubric. There is nothing parameter-wise for the description to clarify, and it correctly implies a no-argument call.

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 ('saves the active sprite to disk'), so the agent knows exactly what the call does. It is separable from the sibling save_sprite_as by name and by the 'to disk' phrasing, but the description never explicitly draws that contrast, 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?

The parenthetical 'Saves only when explicitly requested' implies the tool should be invoked only on an explicit user save request, which is useful implied guidance. However, it names no alternative (e.g. save_sprite_as for saving under a new name) and gives no preconditions, so usage remains inferential.

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 for what is clearly a write operation. It does not disclose whether an existing file is overwritten, whether the format is inferred from the extension, whether the sprite's associated path changes, 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?

A single tight sentence with the action and destination front-loaded and no filler. It is efficient, though its brevity comes partly from omitting useful details.

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 one-parameter write tool with no output schema and no annotations, the description covers the basic action but omits overwrite behavior and format inference, which matter for a save-to-path operation. 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 description coverage is 100%, and the schema already documents the filePath parameter and its accepted extensions (.aseprite, .ase, .png). The description adds only the notion of 'specific target file path', which is essentially a restatement, 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 (saves) and resource (the active sprite) plus the destination concept (target file path on disk). However, it does not distinguish itself from the sibling 'save_sprite' or 'export_png', so the agent must infer that '_as' means save-to-a-new-path.

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 guidance is given. With siblings 'save_sprite' and 'export_png' present, the description never explains when to choose save-as over a plain save or an export, leaving the routing decision entirely to inference.

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

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

No annotations provided, so the description carries the full burden. It doesn't state whether this affects persistent editor state, whether it requires a sprite to be open, or what happens when frameNumber exceeds the frame 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?

A single efficient sentence with no filler. Front-loaded with the action, though generic phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-param stateful mutation with no annotations or output schema, more behavioral context (state persistence, required preconditions) would help. It's minimally adequate but leaves important 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% and the schema documents frameNumber as 1-indexed with exclusiveMinimum 0. The description adds no parameter semantics beyond this 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 clear verb (select/change) and resource (frame) in the editor. However, it doesn't differentiate from the sibling select_layer, which has the same 'select' pattern applied to a different resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this vs. siblings like list_frames or create_frame. The agent must infer that selecting is for making a frame active before drawing/editing.

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 implies a state mutation (the active layer changes) but says nothing about side effects, error behavior for nonexistent layer names, or whether the prior selection is preserved anywhere. Only the basic action is disclosed.

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 short sentence with no wasted words, and the verb+object are front-loaded. It is as concise as a description can be, though brevity here borders on under-specification rather than deliberate economy.

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 one-parameter tool with a fully documented schema and no output schema, the description covers the core action. However, with no annotations it still omits what happens if the named layer does not exist and what the tool returns, leaving gaps for an agent handling errors.

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 single parameter 'name' is documented in the schema as 'Layer name to select as active'. The description adds nothing beyond that, so the baseline 3 applies for a schema that already does 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?

The description states a specific verb ('Sets') and resource ('active working layer in Aseprite'), which is unambiguous about what the call does. It does not explicitly differentiate itself from siblings like set_layer_visibility or set_layer_opacity, but the phrase 'active working layer' is specific enough to distinguish 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 guidance on when to use this tool versus alternatives, no preconditions (e.g., the layer must already exist), and no mention of when-not to use it. The agent must infer usage entirely from the name and 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?

No annotations are provided, so the description carries the full behavioral burden. It does not say whether the frame must exist, what happens on an invalid frame number, whether the change is undoable, or what the call returns. For a mutation tool with zero annotation coverage, 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 no filler or repetition beyond the unit restatement. It is efficient, though its brevity edges toward under-specification rather than tight conciseness.

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 mutation tool with a fully documented schema and no output schema, the description is minimally adequate. It omits the failure modes and undo semantics that an agent would need to call this safely, but the small surface area limits the damage.

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 durationMs and frameNumber are documented in the schema, including units and exclusiveMinimum constraints. The description's only added detail, 'in milliseconds', duplicates 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 (sets) and resource (frame duration) with the unit, so an agent can tell it apart from sibling mutators like set_layer_opacity or set_pixel. It does not explicitly distinguish itself from related frame tools such as create_frame or duplicate_frame, which may also influence timing.

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 tool versus alternatives, nor any stated prerequisites. The description never mentions that the target frame must already exist or that duration is an editable property of an existing frame, leaving usage entirely to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose whether the layer must already exist, whether the change is undoable, what happens on an invalid layer name, or whether the value persists to disk. The only behavioral detail is the numeric range, which is already in the schema.

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 short, front-loaded sentence with no filler. It is appropriately sized for the operation, though extremely minimal.

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 full schema coverage and no annotations or output schema, the description is minimally adequate. It covers the core action but omits error conditions and persistence/undo behavior that a mutation tool would benefit from given the absence of annotations.

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 both 'name' and 'opacity' with the 0=transparent/255=opaque semantics. The description's '(0 to 255)' merely repeats what the schema provides, 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 (adjusts) and resource (layer opacity) with the value range, so the action is unambiguous. It does not name a sibling or explicitly distinguish itself from related layer tools like set_layer_visibility, but the purpose is clear.

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 prerequisites (e.g. layer must exist), and no mention of alternatives such as set_layer_visibility for toggling visibility. The agent must infer usage entirely from the name.

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, yet it only restates the basic operation. It says nothing about whether the change is undoable, whether it requires an existing layer in the current sprite context, or how visibility interacts with rendering/export.

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 waste. It is efficient, though it is arguably too terse to earn a top score given the missing 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 full schema coverage and no output schema, the description is minimally adequate. However, with no annotations, it should say more about state prerequisites and reversibility to be fully 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 both parameters (name, visible) are already documented in the schema with clear semantics. The description adds nothing beyond what the schema provides, so the 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?

States a specific verb pair (shows/hides) applied to a specific resource (layer), which is more informative than a tautology. It implicitly distinguishes itself from set_layer_opacity, select_layer, rename_layer, and delete_layer, though it never names those siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus set_layer_opacity, select_layer, or delete_layer, and no mention of prerequisites such as which sprite/layer must be active. 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?

With no annotations, the description carries full behavioral burden and delivers little. It does not disclose that this overwrites an existing palette entry, whether the change is undoable/redoable (undo and redo exist as siblings), or whether an active palette must be loaded first.

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 efficient sentence with the resource and target front-loaded, and no wasted words. It is concise but borders on under-specification rather than trimming 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?

For a two-parameter mutation with a fully documented schema, the description is minimally viable. It omits the mutation's side effects (overwrite, undoability) and any state prerequisite, which for an unannotated write tool leaves an agent with real 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%: index (0-255) and color (hex, e.g. #FF0000FF) are fully documented in the schema. The description adds no format, range, or edge-case detail beyond what the schema already states, 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 ("Updates") and resource ("the color at a specific palette index"), so the action is unambiguous. However, it does not distinguish itself from palette siblings like get_palette or find_palette_color, so an agent gets no explicit routing help.

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 (e.g. an active sprite/palette), and no reference to alternatives such as get_palette or find_palette_color. Usage must be inferred entirely from the name and sibling 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 usefully discloses that the operation is wrapped in an atomic undo transaction, but it omits other important traits such as default layer/frame targeting, permission requirements, and the interaction between layerName and layerIndex.

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 efficient sentence with the core action and scope front-loaded. 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?

The description is minimally adequate for a 7-parameter mutation tool with no annotations. It covers the core action and undo behavior, but lacks details on default layer/frame selection and mutual exclusivity of layerName/layerIndex, which an agent would need for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each parameter is already documented in the schema. The description only restates x, y, and color without adding nuance, 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?

The description states a specific verb ('Paints') and exact resource ('a single pixel at (x, y)'), which implicitly distinguishes it from batch or shape-drawing siblings like set_pixels, draw_line, and flood_fill. An agent can tell what the tool 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?

No explicit when-to-use guidance is given. The description does not mention when to prefer this over set_pixels, draw_line, flood_fill, or replace_color, nor does it note any prerequisites or 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?

With no annotations, the description carries the full burden and delivers real behavioral facts: operations are atomic in a single undo step, and it returns modified count, bounding box, and optional preview. It omits any permission/auth requirements or constraints like the layerName/layerIndex mutual exclusivity, which is a minor 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 tight sentences with the most important routing signal ('PRIMARY DRAWING TOOL') front-loaded, followed by behavioral and return-value facts. No filler or 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 exists, and the description compensates by naming the return payload (modified count, bounding box, optional preview). Atomicity and batch scope are covered for a 6-parameter mutation tool, leaving only permission/layer-targeting caveats unaddressed.

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 (pixels, layerName, layerIndex, frameNumber, previewScale, returnPreview) is already documented in the schema. The description adds no parameter-level syntax or format detail beyond what the schema provides, 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 (Paints) and resource (pixels) with clear scope: batched tens-to-thousands in one call. 'PRIMARY DRAWING TOOL' signals it is the default over per-pixel siblings like set_pixel, though it never names the alternative 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?

The 'PRIMARY DRAWING TOOL' label implies this is the preferred path for painting, which is implicit routing guidance. It gives no explicit when-not conditions or named alternatives (e.g. set_pixel for single pixels, draw_line/draw_rectangle for shapes).

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 granularity -- a single most-recent action, scoped to the active sprite. It stops short of the traits that matter for an undo: whether structural operations (frames, layers, groups) are also covered by 'editing tool call or transaction,' how deep the undo stack goes, and what happens when there is nothing left to undo.

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 sentence, no filler, with the scope constraint ('most recent ... on the active sprite') front-loaded. Nothing 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 zero-argument tool with no annotations and no output schema, the description is adequate but not complete: it never says whether undo covers non-editing operations handled by siblings like create_frame or delete_layer, nor what the tool reports when the stack is empty. These are the details an agent needs to avoid surprising 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?

The schema has zero parameters and 100% description coverage, so the baseline is 4. The description correctly implies the tool is parameterless by describing an action applied to the current context rather than to a target argument.

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 uses a specific verb ('Undoes') and pins the resource and scope precisely: 'the most recent editing tool call or transaction on the active sprite.' That scoping distinguishes it from a broad history reset, though it never names the 'redo' sibling that an agent would naturally pair it with.

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 by the semantics of 'undo' -- there is no explicit statement of when to reach for this versus redo, nor any precondition (e.g. that an active sprite must exist). An agent can infer the intent, but nothing routes it between the two history tools.

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