lentera-aseprite-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action. Drawing tools are separated by shape, palette tools by operation, and export tools by format. Even similar tools like `get_canvas_preview` and `take_screenshot` are clearly differentiated by description.
Naming Consistency5/5
All tools follow a consistent `verb_noun` snake_case convention, making it easy to predict tool names. Verbs are action-oriented (open, get, set, add, remove, draw, export) and nouns clearly identify the target (sprite, layer, frame, tag, palette).
Tool Count2/5
At 51 tools, the server is heavily overloaded. While each tool is individually useful, the sheer number creates navigation burden and suggests excessive granularity (e.g., separate shape drawing tools, multiple export formats). This detracts from coherence.
Completeness5/5
The surface is extremely complete, covering sprite lifecycle, layers, frames, tags, palette, drawing, transformations, export, and cel operations. The inclusion of `run_lua_script` ensures no operation is impossible, making gaps moot.
Average 3.5/5 across 51 of 51 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that content is erased but does not explain side effects (e.g., whether the cel itself is deleted, whether it is permanent, or how it interacts with frame/layer properties). This is a significant gap for a destructive 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, easy to parse and front-loaded. However, it is so terse that it borders on under-specification, lacking any additional context or structure. It earns the middle score due to brevity without completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 zero parameter documentation, this description is insufficient. The agent lacks context about what a 'cel' is, which frame/layer to specify, and what consequences clearing has, making the tool incomplete in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the description does not mention the 'frame' or 'layer' parameters at all. The agent gets no explanation of how these identify the cel, leaving the parameters semantically opaque despite their self-explanatory names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (clear/erase) and the resource (cel), giving a specific verb+resource pair. It does not explicitly distinguish from sibling tools like move_cel or set_cel_opacity, but the operation is unique enough to be understood.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives, nor any prerequisites like valid frame/layer values or whether the cel must exist. The description only states the action, leaving usage context entirely to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions the outline/filled option, but omits key behavioral traits such as interaction with the active layer/frame, coordinate system, whether it overwrites or composites pixels, and any return values. Significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no waste. It is front-loaded with the core action and includes a key option. However, it is under-specified overall, so not a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, nested color object, no output schema, no annotations), the description is too thin. It lacks essential context about layer/frame targeting, parameter defaults, and return behavior, making it inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only color and filled have descriptions). The description adds meaning to 'filled' (outline vs filled) but fails to explain x, y, width, height, frame, or layer. Most parameters remain undocumented, and the description does not compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: drawing a rectangle on the canvas. It mentions 'outline or filled', which distinguishes it from sibling drawing tools like draw_circle or draw_ellipse. However, it does not explicitly name alternatives, so only a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other drawing tools (e.g., draw_pixels, fill_area, outline). The description simply states what it does without giving context on selection criteria or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It does not mention side effects, error handling, permissions, or whether changes are reversible. The description is purely functional with no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and resource, and includes useful parenthetical detail. It is appropriately concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is too thin for a mutation tool with six parameters. It does not explain what happens on error, whether partial updates are supported, or any behavioral consequences. The description needs more context to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a bit by listing some properties, but the schema already documents each parameter clearly. The description does not provide additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets properties of a layer and lists the main properties (name, opacity, visibility, blend mode). It distinguishes from sibling layer tools (add, remove, list, get/set active), though it does not explicitly mention all schema properties like locked or new_name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are any exclusions or prerequisites mentioned. The description only states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior, yet it only says 'draw an ellipse on the canvas.' It does not disclose whether the ellipse is filled by default, how the `filled` parameter interacts, whether existing pixels are overwritten, or how frame/layer parameters are resolved. This is minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently states the tool's core purpose without restating schema fields or adding filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 8-parameter input schema, nested color object, no annotations, and no output schema, this one-line description is severely incomplete. It lacks coordinate system details, defaults for `filled`, layer/frame behavior, and any mention of the return value or side effects. The description is inadequate for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13%, with only `color` described as '{r,g,b,a}'. The description adds no meaning to required parameters like `x`, `y`, `width`, `height`, or optional parameters like `frame`, `layer`, and `filled`. It also doesn't clarify whether x/y are center-based or corner-based, leaving essential semantics unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Draw' and a clear resource 'ellipse on the canvas,' which distinguishes it from related sibling tools such as draw_circle, draw_rect, and draw_line. It immediately and unambiguously states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool should be used when an ellipse is needed, but it provides no explicit guidance on when to choose it over the many other drawing tools, nor does it mention any exclusions or alternative tools. The usage context is only barely implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose the destructive nature of merging (e.g., original layers are likely consumed), and there are no annotations to compensate. For a mutation tool, this is a significant omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant content, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no output schema or annotations, the minimal description leaves key behavioral questions unanswered, such as the fate of original layers and placement of the merged result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both 'layers' and 'into_name'. The description adds no further parameter insight, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'merge' with a clear resource 'layers' and outcome 'into one'. It distinguishes itself from sibling tools like add_layer and remove_layer by naming a unique operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as remove_layer or set_layer_properties. It merely states the function without contextual cues or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not warn that unsaved changes may be lost if the 'save' parameter is false, nor does it mention side effects, confirmation prompts, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words. For a simple operation, this is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally viable for a simple close action, and the schema covers the save parameter. However, it omits the critical warning about data loss and doesn't clarify the 'active sprite' concept, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter ('save' with a clear description and default). The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('close') and resource ('active sprite'), making the operation unmistakable. It distinguishes itself from sibling tools like open_sprite, create_sprite, and save_sprite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor any prerequisites such as saving changes first. The usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral effects; it only mentions the algorithm but does not state whether the operation is destructive, which coordinate system is used, how frame/layer selection works, or what the return value is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core functionality without unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and no annotations, the description lacks critical context about the drawing context and optional parameters, making it insufficient for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies the roles of x1/y1/x2/y2 as the two endpoints, but omits any explanation of the optional frame and layer parameters, and the color object is only documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool draws a line between two points and specifies the Bresenham algorithm, distinguishing it from other primitive drawing tools like draw_rect and draw_circle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use draw_line over other drawing tools, nor are any prerequisites (e.g., open sprite, active layer) mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only mentions the output format, but does not state whether the tool overwrites files, requires a saved sprite, has side effects on the sprite state, or what errors might occur. This is a significant gap for a mutating file-export operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core purpose and key output variation. It is concise and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, but the description covers only the layout concept. There is no output schema, no explanation of return values, and no discussion of how it interacts with sprite state or other tools. Given the complexity and sibling toolset, the description is insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, so the description should compensate for the undocumented parameters. It adds meaning for 'layout' by referencing the horizontal/vertical/packed strip, but does not explain 'scale' or 'merge_duplicates'. Also, saying 'all frames' is misleading because the 'tag' parameter allows exporting only a subset.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports a sprite sheet, with a specific verb ('Export') and resource ('sprite sheet'), and it mentions the layout options (horizontal/vertical/packed). This distinguishes it from sibling export tools like export_frame (single frame) and export_layers (individual layers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool over alternatives. There are many sibling export tools (export_frame, export_animation_tag, export_godot_spriteframes), but no context or exclusions are given to help an agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for disclosing behavior. It does not state whether moving a cel overwrites the destination, whether the source cel becomes empty, or what happens if destination already contains a cel. This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action. No wasted words, and the structure is appropriate for the tool's simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool involves modifying sprite data, yet the description omits critical context such as destination-cel overwrite behavior, source-cel cleanup, or whether the sprite must be open. With no output schema, the description is incomplete for safe and effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on parameter meanings beyond their names. While from_layer/from_frame/to_layer/to_frame are somewhat self-explanatory, the description fails to clarify details like whether frame numbers are zero-indexed or whether layers are referenced by name or ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Move') and resource ('cel'), and clearly identifies the scope ('from one layer/frame to another'). It unambiguously distinguishes this tool from siblings like clear_cel or set_cel_opacity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites like having a sprite open or selecting the target layer. There is no context about required states or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden, but it fails to disclose key behavioral details. It does not specify whether rotation applies to the active frame/layer or the entire sprite, the direction (clockwise vs counterclockwise), or whether it is destructive/reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action. There is no redundancy or unnecessary detail, making it highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and no output schema, the description is too sparse. It lacks explanation of how frame and layer affect the rotation, what is meant by 'sprite' in the context of the editing session, and any side effects or return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially explains the 'angle' parameter by listing valid values, but completely ignores 'frame' and 'layer' parameters, leaving their meaning and purpose unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (rotate) and the resource (sprite), and specifies the allowed angles (90, 180, or 270 degrees). This distinguishes it from sibling tools like flip_sprite and draw operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention related tools such as flip_sprite or state any prerequisites or exclusions. The description simply states what the tool does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavior disclosure. As a mutation tool, it should mention whether opacity is applied to the active cel when layer/frame are omitted, whether the change is reversible, or any prerequisites (e.g., open sprite). The single-sentence description offers none of this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, waste-free sentence, but it is too brief to cover the necessary behavioral and parameter details for a tool with three parameters and no annotations. The conciseness is good, but the overall structure under-specifies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple schema but no output schema or annotations, and the description does not explain default behaviors, success/failure conditions, or how layer and frame are used when omitted. Given the complexity of cel addressing, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes the opacity parameter (0-255), leaving frame and layer with no schema descriptions. The description adds the conceptual meaning that a cel is a layer+frame combination, which helps interpret frame and layer. However, it does not clarify whether these are optional (since only opacity is required), what they default to, or whether they expect names or indices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'set', the resource 'opacity', and the scope 'a specific cel (layer+frame combination)'. This distinguishes it from sibling tools like set_layer_properties, which operate at the layer level, and clear_cel, which removes a cel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'specific cel' implies this is for per-cel opacity adjustments, which is distinct from layer-wide properties. However, it does not explicitly state when to use this tool or when to prefer set_layer_properties, nor does it mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not explain how insertion affects existing frame positions, whether the new frame becomes active, default duration behavior (beyond schema), or error conditions when no sprite is active.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero filler. It is maximally concise while conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too sparse. It omits important behavioral context such as frame-index shifting on insertion, the effect on the active frame, and the fact that duration has a default. A bit more detail would make it a more complete guide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no information about the parameters, but the schema already clearly documents position (1-based, null = end) and duration default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Add'), the resource ('frame'), and the target ('active sprite'), which is a well-defined context given sibling tools. It distinguishes itself from related tools like remove_frame and list_frames.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided beyond the action itself. The description does not mention when to use this tool versus alternatives, nor does it note any prerequisites (e.g., an open sprite) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It states that flipping applies to the active sprite or a specific layer/frame, but does not disclose whether the operation is in-place/destructive, requires an open sprite, affects undo history, or what the return value is. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, appropriately sized sentence with no filler. It front-loads the core operation and adds optional targeting and direction details efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple tool, the description omits critical context for an editor operation: it is presumably destructive/in-place, requires an open sprite, and may interact with frame/layer scoping in non-obvious ways. No output schema or annotations to fill gaps, so the description alone is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero property descriptions, so the description must compensate. It explains that layer and frame target specific components, and direction controls orientation. However, it does not clarify defaults (e.g., if direction is omitted, is horizontal implied?) or whether layer/frame are mutually exclusive. Partial semantics provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (Flip) on a specific resource (active sprite, or specific layer/frame), with orientation options. It distinguishes itself from sibling tools like rotate_sprite by focusing on mirroring rather than rotation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives (e.g., rotate_sprite). The description implies flipping is the intended use but does not mention prerequisites, exclusions, or related tools. No explicit context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the action but does not disclose whether the existing palette is replaced, whether an active sprite is required, or how errors (e.g., missing file) are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words. It is appropriately front-loaded and immediately conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description gives the basic action but omits prerequisites (active sprite) and does not clarify how it relates to the sibling load_palette_lentera. This leaves gaps for an agent deciding between tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'path' is fully described in the input schema, including its default value. The tool description adds little beyond 'palette file' which is already implied by the schema, so it meets baseline without adding substantial value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Load a .gpl palette file into the active sprite' clearly states the specific verb (load), resource (.gpl palette file), and target (active sprite). It distinguishes from the sibling load_palette_lentera by emphasizing file-based loading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives such as load_palette_lentera. The default path hint is present but does not explain when to prefer this tool over the sibling that loads the default palette.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the drawing action and outline/filled option, without revealing whether it overwrites existing pixels, affects the active layer/frame, or has side effects. The outline/filled detail is essentially a restatement of the 'filled' parameter, adding little beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no annotations and no output schema, this is inadequate. It does not mention coordinate units, default layer/frame behavior, color formatting, or return values, leaving the agent with significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14%, so the description must compensate for parameter meaning. It only clarifies the outline/filled distinction, but leaves cx, cy, radius, frame, layer, and the color structure unexplained. The added value is minimal and does not fill the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool draws a circle on the canvas and mentions the outline/filled distinction, which distinguishes it from sibling tools like draw_ellipse or fill_area. The verb+resource pattern is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when a circle is needed), but it does not provide explicit guidance on alternatives like draw_ellipse or fill_area, nor any exclusions or conditions. It lacks clear when-to-use vs. when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the full burden of behavioral disclosure. It only says 'Export a single frame as PNG,' omitting critical traits like whether the file is created/overwritten, whether the sprite is modified, or whether a sprite must be open. The schema covers parameter defaults, but side effects are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero filler. It communicates the essential purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but adequate for a simple export tool. However, it lacks contextual details about how this fits among sibling export tools (e.g., when to choose export_frame over export_sprite_sheet or export_animation_tag), which would improve completeness for an agent deciding between tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — all four parameters have clear descriptions ('Output PNG path', 'Frame number to export (null = active frame)', etc.). The tool description adds no extra parameter information, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports a single frame as PNG. The verb 'Export' with resource 'single frame' and format 'PNG' distinguishes it from sibling tools like export_sprite_sheet and export_animation_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives such as export_sprite_sheet, export_layers, or take_screenshot. It simply states the action without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'export each layer as a separate PNG file,' but omits that the format can be GIF (schema allows gif) and doesn't address the frame parameter or naming/overwrite behavior. The description is slightly misleading by specifying PNG only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is front-loaded with the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the one-sentence description is incomplete. It doesn't explain how frame or format affect the export, nor what the output files will be named or where they go.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (output_dir has a description). The description adds no meaning for the frame or format parameters, leaving them undocumented. It fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (export) and the resource (each layer) and output (separate PNG file). It distinguishes from sibling export tools like export_frame and export_sprite_sheet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The wording implies this is for exporting individual layers as separate files, but it doesn't explicitly state when to use it over alternatives or mention any exclusions. No direct comparison to other export tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention that flood fill overwrites existing pixels, how tolerance affects behavior, or whether the operation is reversible. The description only states the basic mechanism without disclosing the destructive nature or edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, highly concise sentence that front-loads the core purpose. Every word earns its place, and the paint bucket analogy adds clarity without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six parameters, no output schema, and no annotations, the description is severely under-specified. It lacks any explanation of return values, coordinate systems, or how optional parameters like frame and layer affect the operation. More context is needed for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description does not compensate. It refers to 'a point' but does not explicitly identify x and y as the starting coordinates, nor does it explain frame or layer parameters. Only color and tolerance have schema descriptions; the description adds no additional parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('flood fill') and resource ('an area starting from a point'), and the paint bucket analogy makes it immediately recognizable. It clearly distinguishes from sibling drawing tools like draw_pixels or draw_rect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The paint bucket analogy provides clear context for when to use the tool, but it does not explicitly mention alternatives or situations where another tool should be used instead. There is no when-not guidance, so the usage guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral impact. It only states the action without mentioning side effects, error behavior, or whether the rename affects associated frames. The mutation is implied but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise single sentence of five words, immediately front-loading the verb and object. It contains no waste and is appropriately minimal for the simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple signature with two fully described parameters and no output schema or annotations. The description covers the basic action but does not disclose return behavior or error conditions, leaving some gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described ('Current tag name' and 'New tag name'). The tool description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'rename' with the resource 'animation tag', clearly distinguishing it from sibling operations like create_tag, remove_tag, and list_tags. It precisely states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_tag/remove_tag, nor does it mention any prerequisites or conditions. There is no contextual information about selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It does not mention side effects such as whether colors are truncated or extended, whether the operation is reversible, or if any permissions are required. This is minimal transparency beyond the tool's basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately concise for a simple tool, and every word contributes to conveying the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is minimally adequate. The schema covers the parameter, but the lack of annotations and output schema leaves gaps around side effects and return values. It is not as incomplete as tools with multiple undocumented parameters, but it could benefit from clarifying behavior when resizing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single parameter 'size' as 'Number of colors in palette', giving 100% coverage. The description adds little beyond reinforcing that the palette is resized to a specific number of colors, but does not clarify constraints like minimum size or behavior when reducing colors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: resizing the palette to a specific number of colors. It uses a specific verb ('resize') and resource ('palette'), and it distinguishes itself from sibling tools like get_palette or set_palette_colors by focusing on the palette size rather than color values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of when to prefer resizing over setting individual colors, nor any exclusions or prerequisites. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only restates the core action without disclosing any side effects, prerequisites, range limitations, or behavior on invalid frame numbers. The schema notes 1-based indexing, but that is parameter semantics, not behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It effectively communicates the tool's purpose in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter with no output schema, the description plus schema provide the basic information needed to make an initial call. However, it lacks usage context and behavioral caveats that would be useful for an agent, especially given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the frame_number parameter beyond what the schema already provides. Since schema description coverage is 100% ('Frame number to activate (1-based)'), the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Set the active frame' and clarifies the intent with '(navigate to a specific frame)'. This specific verb+resource phrasing distinguishes it from sibling frame tools like add_frame, remove_frame, and set_frame_duration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool vs alternatives. The usage is only implied by the name and description, with no mention of prerequisites (e.g., an open sprite) or edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full responsibility for behavioral disclosure. It fails to mention side effects such as whether the currently open sprite is replaced, if multiple sprites can be open, handling of unsaved changes, or error conditions. This is a significant gap for a mutating action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the action and target without any redundant information. It is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple tool, the absence of annotations and output schema leaves critical context unaddressed. The description doesn't clarify the impact on the current workspace, which is important given the existence of siblings like list_open_sprites and close_sprite. The agent lacks information needed to reason about state transitions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of the parameters, including a clear explanation of the 'path' parameter ('Absolute path to .aseprite or .png file'). The tool description adds no further parameter 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'open' with the resource 'existing sprite file in Aseprite', making the tool's function clear. It distinguishes itself from siblings like create_sprite, save_sprite, and close_sprite by focusing on loading an existing file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an existing sprite needs to be loaded for editing, but it provides no explicit alternatives or exclusion scenarios. It doesn't mention when to use this over create_sprite or other related tools, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It merely says 'Set specific palette colors by index,' but does not explain side effects (e.g., whether it replaces existing colors, what happens on out-of-range indices, or whether other palette entries are left untouched). The mutation nature is implied but not explicitly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that clearly states the action and scope. It is front-loaded and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with only one well-documented parameter, the description is adequate. It tells you exactly what the tool does without needing to explain return values (none expected) or complex behaviors. However, given the lack of annotations, a note about modifying the current palette could improve it slightly, so it does not fully reach the highest tier.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already documents the colors array and the 0-based index. The description's phrase 'by index' adds minor semantic context, but the schema already provides the necessary meaning. It does not significantly go beyond the structured parameter definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Set'), the resource ('palette colors'), and the method ('by index'). It distinguishes from sibling tools like get_palette, load_palette_from_file, and resize_palette, making the tool's specific role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when to prefer it over load_palette_from_file, replace_color, or resize_palette, nor any contextual prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 action and output formats but omits side effects such as file overwriting, directory creation, or required permissions. This is a significant gap for a tool that writes files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence with no filler. It front-loads the action and resource, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no annotations, and no output schema, the description is too terse. It leaves ambiguity about scale, file naming, and side effects, and does not fully guide correct invocation, especially among many sibling export tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only tag_name has a description). The description mentions output formats, which aligns with the 'format' enum, but does not clarify the meaning of 'scale' or behavior of 'output_dir', failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Export'), resource ('all frames from a specific animation tag'), and output formats ('individual PNGs or a GIF'). This distinguishes it from sibling export tools like export_frame, export_sprite_sheet, and export_layers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this to export frames from an animation tag. However, it does not explicitly mention alternatives or when not to use it, but the purpose is unambiguous enough for basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of disclosing behavior. It only says 'Get', which implies read-only, but it does not disclose the return format, behavior when no layers exist, or any error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is free of unnecessary detail. Every word is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no annotations and no output schema, the description provides the core purpose but omits details about the return value and edge cases. It is minimally viable but leaves room for ambiguity about what the agent will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and the schema is empty with 100% coverage. The description needs to explain no parameter semantics, and the baseline of 4 is appropriate because the schema already fully documents the parameter structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and clearly identifies the resource as 'the currently active/selected layer'. This unambiguously distinguishes it from sibling tools like set_active_layer and list_layers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention that to change the active layer one should use set_active_layer, or that list_layers enumerates all layers. Usage is implied only by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It only states 'Save' and 'optionally save to a new path,' but omits important details like whether saving is destructive/overwrites, error conditions (e.g., no active sprite), or what return value to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action and containing no filler. Every word earns its place, making it very concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the essential behavior. However, it lacks edge-case context (e.g., behavior with no active sprite, whether overwriting occurs) that would make it fully complete for an agent, though the simplicity keeps it minimal but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional 'path' parameter, with the schema describing it as 'Optional: save to this path (save-as)'. The description essentially repeats this ('Optionally save to a new path'), adding little semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Save') and resource ('active sprite'), clearly stating the tool's core function. It distinguishes itself from sibling tools like open/create/close and export operations. The optional new path is also mentioned, adding precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you want to save the active sprite) but provides no explicit guidance on alternatives or exclusions. It does not contrast with export functions or mention prerequisites, such as having an active sprite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and does not mention behavior on invalid layer names, error handling, side effects, or reversibility, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, lean sentence with no redundant content, earning full marks for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter with no output schema, the description is minimally sufficient but lacks behavioral context (e.g., error handling, prerequisites) that would make it fully complete in the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter 'name' clearly described as 'Layer name to activate'. The description adds no further semantic detail beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set the active layer by name' clearly states the verb ('set'), resource ('active layer'), and mechanism ('by name'). It distinguishes the tool from siblings like get_active_layer (retrieval) and set_layer_properties (modifying layer settings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for changing the current layer but provides no explicit guidance on when to use this tool versus alternatives like get_active_layer or set_layer_properties. No exclusions or context are offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full behavioral burden. It only states the action without disclosing side effects such as whether the new layer becomes the active layer, whether any prerequisites exist, or what the return value is. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded with the action and target, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and complete schema coverage, the description is mostly adequate. However, it omits potential behavioral consequences like whether the new layer becomes active or any return value, leaving minor ambiguity. It is complete enough for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all three parameters: name has a default, type lists an enum, and position explains stack ordering. The description adds no additional parameter information, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a new layer to the active sprite' uses a specific verb and resource, clearly identifying the action and target. It distinguishes itself from sibling tools like remove_layer or set_layer_properties by stating exactly what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when you want to add a layer) but provides no explicit guidance on alternatives or exclusions. It does not mention related tools like remove_layer or set_layer_properties, leaving the agent to infer the usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does mention that the sprite opens in the GUI, but it does not state whether the sprite is persisted, becomes the active sprite, or how it interacts with existing documents. For a mutation tool, this lack of detail is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. It front-loads the core action and adds one key behavioral trait, making it both concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no required parameters and no output schema, yet the description does not clarify what happens when 'name' is omitted (the schema provides no default for name). It also does not mention return values or error conditions. For a create operation with four parameters, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all four parameters are fully documented in the input schema. The description adds no additional parameter semantics 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (a sprite in Aseprite), and adds the side effect of opening it in the GUI. This distinguishes it from sibling tools like open_sprite, which opens existing sprites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Create a new sprite' provides clear context for when to use this tool. It does not explicitly name alternatives, but the intended use case—creating a new sprite rather than opening an existing one—is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the core behavior (adding pixels around non-transparent areas) and default color, but does not mention side effects like overwriting existing pixels, layer/frame targeting, or undo behavior. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and followed by a useful default value. Every word earns its place without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple drawing tool with no annotations or output schema, the description gives the core purpose but omits context like whether it applies to the active layer/frame if unspecified, or how the 'outside' parameter behaves. Adequate for basic selection, but incomplete for nuanced invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, with descriptions for color and outside only. The description adds little beyond the schema—only reiterating the default color. Frame and layer parameters remain undefined in both schema and description, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Add a pixel outline') and its specific scope ('around non-transparent pixels'). This distinguishes it from sibling drawing tools like draw_rect or draw_line, and the mention of default color adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for outlining sprite pixels but does not explicitly state when to use it versus alternatives or provide exclusions. Sibling tools exist for other drawing operations, but no direct comparison or guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the core action but omits any side effects, such as whether the deletion is irreversible, how it affects other frames (e.g., renumbering), or what happens to the animation. This is a destructive operation and lacks essential transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundant information. It is appropriately sized for the tool's simplicity and front-loads the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description fails to convey important context like irreversibility or impact on the animation. While the tool is simple and the schema covers the parameter, the missing side-effect information makes the description incomplete for real-world decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes frame_number as 'Frame number to remove (1-based)', achieving 100% coverage. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a frame from the active sprite' uses a specific verb ('remove') and resource ('frame') with clear scope ('active sprite'), distinguishing it from siblings like add_frame and list_frames. The action is unambiguous and purpose is immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a frame needs to be deleted from the active sprite. It provides clear context but does not explicitly state when not to use it or mention alternatives. There are no exclusions, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Remove an animation tag by name' without mentioning whether removal is permanent, what happens to frames associated with the tag, or how errors (e.g., missing tag) are handled. This is insufficient for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that clearly states the operation and the key argument. It contains no fluff, repetition, or unnecessary detail, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the essential purpose. It could optionally mention side effects or return behavior, but the combination of a clear description and a well-documented schema makes it sufficiently complete for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single parameter 'name' as 'Tag name to remove', and the description's 'by name' aligns but adds no extra meaning. With 100% schema description coverage, the baseline of 3 is appropriate; the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Remove' with the resource 'animation tag' and the qualifier 'by name', making its purpose unambiguous. It clearly distinguishes itself from sibling tools like create_tag, list_tags, and rename_tag, as it is the only removal operation for tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to delete a tag by name, but it does not explicitly state when to use it vs alternatives or mention any prerequisites (e.g., whether the tag must already exist). No alternatives are named, leaving the usage context only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It states the action and provides typical duration values, but does not disclose side effects, prerequisites (e.g., frame existence), or error handling. The second sentence largely repeats schema parameter descriptions rather than adding operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, with the primary purpose front-loaded and no filler. Every sentence contributes to clarifying the tool's function and typical values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter setter with no output schema and fully documented parameters, the description is largely sufficient. It clearly identifies the action and provides domain-specific values, though it could mention what happens if the frame number is invalid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with 100% coverage. The description adds only the 8fps equivalence for walk duration, which is marginal value beyond the schema. Baseline 3 is appropriate since the description does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Set the duration') and a specific resource ('a specific frame'). It distinguishes itself from sibling frame-related tools like add_frame, remove_frame, and set_active_frame by focusing on duration modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative comparison is provided, but the Lentera walk/attack examples imply the tool is used for animation timing. Since no sibling tool handles frame duration, the missing alternative guidance is less critical, but the usage context is still only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the create action and use case but does not disclose whether tags must be unique, what happens if a tag name already exists, whether frame ranges are validated, or what the return value is. These are 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every word serves a purpose. It includes the operation, the target (frame range), and a contextual use case without any filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema; the description gives the core purpose and context, but it lacks behavioral details like error handling or return values. The schema covers parameter semantics, but the description alone does not fully equip an agent to anticipate edge cases, leaving it incomplete for a straightforward creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all five parameters, including the enum for loop and examples for name. The description adds no parameter-specific details beyond the schema, so it meets the baseline of 3 but does not enhance understanding of individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create an animation tag for a frame range,' which is a specific verb+resource combination. It also names the tool's purpose for walk/attack/idle/dodge cycles, distinguishing it from sibling tools like remove_tag and list_tags that handle other tag operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Used for walk/attack/idle/dodge cycles in Lentera Pudar' provides clear context on when to use the tool, implying it is for creating named animation tags over frame ranges. However, it does not explicitly mention when not to use it or contrast with alternative tools like rename_tag or remove_tag, which would move it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool generates a resource, without mentioning whether it overwrites existing files, validates input paths, or handles errors. For a file-generating operation, these details are important and missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action ('Generate') and includes the key context (Godot 4, SpriteFrames, sprite sheet, AnimatedSprite2D). Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description and schema together cover the core functionality and all parameters, but the lack of annotations and output schema leaves gaps such as overwrite behavior, expected sprite sheet format, and whether multiple animations are supported. It is adequate for a simple tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all five parameters described in the input schema. The description itself does not add any parameter-level semantics beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: generating a Godot 4 SpriteFrames .tres resource from a sprite sheet. It distinguishes itself from sibling export tools by specifying the exact output format and its intended use with AnimatedSprite2D, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you need a Godot 4 SpriteFrames resource for AnimatedSprite2D. It does not explicitly mention alternatives or exclusions, but the specific mention of SpriteFrames and Godot 4 effectively narrows the use case among the sibling export tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool generates a file but does not disclose whether it overwrites the output path, requires specific image formats, or has other side effects. This is a significant gap for a tool that writes resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and purpose. It is concise with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with full schema coverage, and the description covers the core purpose. However, without annotations or output schema, it lacks information about overwrites, prerequisites, or return values, making it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The description itself doesn't add much beyond the schema, but it does provide context for how parameters relate to the tile sheet and output path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Generate') and clearly identifies the resource (a Godot 4 TileSet .tres) and input (tile sheet). It explicitly mentions the intended use with TileMapLayer, distinguishing it from sibling export tools like export_godot_spriteframes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool ('For use with TileMapLayer'), which implies the target scenario. However, it does not offer explicit alternatives or exclusions compared to other export tools, such as export_sprite_sheet.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Get' implies a read operation, but it does not explain return format (e.g., array of RGBA values), behavior when no sprite is open, or whether the palette is document-global. Lacking output schema, these details remain undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the tool's purpose without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description provides the core purpose but leaves out return value structure and error conditions. For a minimal getter, this is adequate but not fully complete, as agents would benefit from knowing the palette color format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so no parameter descriptions are needed. The description correctly omits param details, and the baseline for a 0-param tool is applied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('current palette colors of the active sprite'), making the tool's action unambiguous. It also differentiates from sibling tools like set_palette_colors, load_palette_from_file, and resize_palette by emphasizing retrieval of the current state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reading the active sprite's palette, but it does not explicitly state when to use it over alternatives such as set_palette_colors or load_palette_from_file. Context is clear for a simple getter, but no exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Draw' which implies mutation but gives no details on overwriting behavior, coordinate system, alpha handling, or error conditions. This is a significant gap for a mutation tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no redundant wording. It is front-loaded with the action and follows with a targeted use case, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the rich schema (100% coverage), the description is mostly sufficient. It communicates the core action and a key use case. Minor gaps such as not explaining frame/layer targeting behavior are covered by the schema. Overall, it is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of all parameters, including descriptions for frame, layer, and pixels. The description adds no parameter-specific information, so it does not exceed the baseline value provided by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool draws individual pixels on the canvas, using the specific verb 'Draw' and resource 'pixels'. The phrase 'precise pixel-art placement' helps distinguish it from sibling shape tools like draw_rect or draw_line, so it fully clarifies purpose and differentiates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating 'Use for precise pixel-art placement', implying it is for pixel-level control rather than shapes. However, it does not explicitly mention alternatives or when not to use it, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It simply states the action but does not reveal that removing a layer is destructive, irreversible, or what happens if the layer does not exist. This is a significant transparency gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and object, with no filler or redundant information. It efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the essential context by specifying the target (active sprite) and the action (remove layer by name). It does not explain error behavior or prerequisites beyond the active sprite, but for such a minimal operation this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as the parameter 'name' is described as 'Layer name to remove'. The description adds no extra meaning beyond this, but the parameter is self-explanatory and the schema handles its documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'remove' and identifies the resource 'layer' and scope 'active sprite', clearly distinguishing it from sibling tools like add_layer, list_layers, and set_layer_properties. It unambiguously states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'from the active sprite' provides clear context that an active sprite must be present and that the layer is removed from it. However, it does not explicitly mention when to use this tool over alternatives or exclude cases like non-existent layers or requiring undo permissions, so it falls short of explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the mutation (replacement) and scope but omits crucial details such as how tolerance affects matching, whether changes are destructive/reversible, and what response to expect. This is inadequate for a tool that modifies sprite data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and immediately clarifies scope. Every word earned its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, a one-sentence description is insufficient. It lacks explanation of tolerance behavior, side effects, return values, or default behavior when layer/frame are omitted (though the scope mention partially covers this). The description feels under-specified compared to the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema leaves 'frame' and 'layer' undocumented (0 out of 5 params have descriptions, but the description compensates by explicitly mentioning 'layer/frame' as scope targets). It adds meaning for these otherwise unspecified parameters. For 'from_color', 'to_color', and 'tolerance', the schema already provides descriptions, so the description does not need to repeat them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Replace one color with another' with explicit scope options ('entire sprite or a layer/frame'). This specific verb+resource+scope distinguishes it from all sibling tools, none of which perform color replacement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on usage by specifying the tool can act on the entire sprite or a specific layer/frame. It does not explicitly mention alternatives, but since no sibling tool offers comparable functionality, this is not a significant omission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'List all open sprites' clearly indicates a read-only enumeration operation with no side effects. The behavior is transparent for a simple list tool, though it does not disclose return format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, highly concise, and directly front-loaded with the core functionality. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action but lacks details about the return value format (e.g., sprite names, IDs, handles) and behavior when no sprites are open. Since there is no output schema, this missing information could hinder an agent's ability to use the results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description appropriately avoids adding irrelevant parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'list' and resource 'open sprites in Aseprite', clearly distinguishing it from sibling tools that open, create, save, or close sprites. It unambiguously states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention use cases, prerequisites, or exclude scenarios, leaving the agent to infer from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 clearly implies a read-only operation by saying 'Get info' and lists what data is returned, but it does not disclose potential errors (e.g., when no sprite is active) or return format. Basic transparency is present, but richer detail is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. Every word adds value, and there is no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter-less getter, the description covers the essential purpose and the data fields returned. There is no output schema, but the listed fields (size, layers, frames, filename) provide adequate context. It could be more complete by noting behavior when no sprite is open, but given the low complexity, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is fully described as an empty object. With no parameters, the baseline score of 4 applies; the description does not need to add parameter details that do not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with the resource ('info about the active sprite') and enumerates the exact data categories (size, layers, frames, filename). This clearly distinguishes it from sibling tools like get_active_layer or get_palette.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need details about the currently active sprite. However, it does not explicitly state when to use this tool versus alternatives or mention any exclusions, so it provides only implied guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'arbitrary Lua code' and 'full Aseprite Lua API', which implies broad capabilities and potential destructiveness, but it does not explicitly warn about side effects, error handling, or sandboxing. This is only a moderate disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no wasted words. It front-loads the primary action and then adds the crucial usage guideline. Every sentence earns its place and the structure is highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a generic code execution tool, and while the description gives a clear use case, it lacks context about what the script can actually do (e.g., access to active sprite, file system, return values). Given there is no output schema and no annotations, the description could be more complete to guide the agent on the tool's capabilities and potential side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'script' parameter with 100% coverage, including that it has access to the full Aseprite Lua API. The description does not add additional meaning beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute arbitrary Lua code inside Aseprite', which is a specific verb (execute) and resource (Lua code inside Aseprite). It also distinguishes itself from siblings by positioning as the fallback for operations not covered by other tools, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance: 'Use for operations not covered by other tools.' This tells the agent when to use this tool and implies that for other operations, dedicated sibling tools should be used instead, which is an explicit alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The word 'get' implies a non-destructive read operation, which is the primary behavioral trait. However, it does not disclose any potential failure modes, return format, or prerequisites beyond the implicit connection requirement. For a trivial getter, this is adequate but lacks deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words. It immediately states the tool's purpose and is perfectly structured for quick consumption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, straightforward purpose), the description is largely complete. It could optionally mention the return type or format of the version, but that is inferable from the tool name and common sense. There is no significant missing context for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline score is 4. The description does not need to explain parameter meanings because none exist. The schema already confirms an empty parameter set, and the description adds no extra parameter-related information, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('the version of the connected Aseprite instance'), which is specific and easily distinguishes this tool from all listed siblings. No other sibling deals with retrieving the application version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: whenever you need the version of the connected Aseprite instance. It does not explicitly mention alternatives or exclusions, but given the singular purpose, no alternatives are necessary. This is a simple getter with no competing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the scope (canvas, active frame, visible layers) and format (PNG), but does not explain the return mechanism (e.g., path, base64) or whether there are any side effects, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences. The first states purpose, the second offers a comparative benefit. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description covers the essential aspects: what is captured and the output format. However, the absence of an output schema and no mention of the return type (file path, binary, etc.) leave a small gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema trivially covers everything. The description correctly avoids adding unnecessary parameter details, matching the baseline for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a PNG preview of the canvas, specifically mentioning active frame and visible layers. It also distinguishes itself from the sibling take_screenshot, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names an alternative (take_screenshot) and states this tool is 'cleaner' for canvas previews. However, it does not describe any scenarios where take_screenshot would be preferable, so it lacks full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 transparently indicates a read-only listing operation with no side effects, and the active sprite scope is made explicit. It does not describe edge cases (e.g., no active sprite) but is adequate for a simple list function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It communicates the essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no annotations, no output schema), the description sufficiently explains what the tool does and what information is returned (frames with durations). It could be slightly more explicit about the return format, but it is complete enough for a no-param listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. The description appropriately adds no parameter information since none exist, and the schema is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('all frames'), the scope ('in the active sprite'), and additional detail ('with their durations'). This distinguishes it from sibling tools like add_frame, remove_frame, and set_frame_duration, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to inspect frames and their durations) but does not explicitly mention alternatives or exclusions. It's simple enough that the intended use is clear, but it lacks direct comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description names the palette and colors, but does not disclose side effects such as whether it replaces the current palette entirely or preserves other slots. Since no annotations exist, more clarity on how it interacts with the current palette would be beneficial. However, 'load' implies setting the palette, so basic behavior is conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, with the essential information first. No fluff, and the color list adds value without clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This simple tool is adequately explained for its low complexity. It lacks an explicit statement about palette size resetting, but includes the colors and usage context, covering the core behavior needed by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description doesn't need to explain any. The palette definition is fully specified in the description, making the tool self-contained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (load) and the specific resource (official Lentera Pudar 8-color palette) with actual color values. It distinguishes itself from sibling tools like load_palette_from_file by targeting a built-in palette.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear directive to use this tool for Lentera Pudar art. It does not explicitly mention alternatives or exclusions, but the context is sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. The verb "List" clearly indicates a read-only operation, and the phrase "active sprite" implies a prerequisite context. However, it does not explicitly state behavior when no sprite is active or the return format, which would enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to understanding the tool's purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema), the description is fully complete. It conveys what the tool lists, where it operates, and the active-sprite constraint, which is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds value by specifying the implicit context ("active sprite"), which is the only relevant semantic. No parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb "List" with the resource "animation tags" and scope "in the active sprite," making the action unambiguous. It clearly distinguishes from sibling tools like create_tag, remove_tag, and rename_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for inspecting existing tags within an active sprite, but provides no explicit guidance on when to use it versus alternatives. No exclusions or alternative tool references are given, leaving usage partially to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It describes the zoom action but does not explicitly state that this is a non-destructive view change or that it does not modify the sprite data. This is a minor gap for a simple view tool, but more explicit disclosure would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the action, target, and purpose efficiently, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, clear purpose), the description is complete. It explains what the tool does and why it is useful, without needing additional details about return values or complex side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms this. Per baseline, a 0-parameter tool should score 4 because there are no parameter semantics to convey, and the description adds no irrelevant parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states the action ('Zoom') and the target ('Aseprite canvas'), with a clear outcome ('fit the window') and context ('for better screenshot visibility'). It is distinct from sibling tools like take_screenshot or get_canvas_preview, as it focuses on view manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('for better screenshot visibility'), implying when to use it. It does not explicitly contrast with alternative tools or state when not to use it, but the context is sufficient for this simple view command.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral constraint: it operates on the 'active sprite,' not on any other sprite. It also implicitly indicates a read-only operation via 'List.' However, it does not specify the return format or behavior when no active sprite exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. It efficiently conveys the entire purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-argument list operation, the description fully captures the tool's functionality. The lack of an output schema is not addressed, but the expected result (a list of layers) is inferable from the name and description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the schema fully documents the inputs. The description adds no parameter details, but none are needed. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: enumerating all layers within the active sprite. It uses a specific verb ('List') and resource ('layers'), and it is distinct from sibling tools such as get_active_layer, add_layer, or remove_layer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the appropriate context: whenever the user needs a complete inventory of layers in the currently active sprite. It doesn't explicitly contrast with alternatives, but the scope ('active sprite') and the verb 'list' make the usage obvious. No exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 clearly states the action and result ('Capture the Aseprite window as an image'), implying a non-destructive read operation. It doesn't specify image format or whether the image is returned or saved, but the simple nature of the tool limits the risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two brief sentences with no fluff. The first sentence states the action, the second provides the typical use case, making it front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with clear purpose and no output schema, the description is sufficient for an agent to select and invoke it. It covers what it does and why to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no parameter details. Baseline for 0 params is 4; the description adds no parameter information because there is nothing to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Capture' and resource 'Aseprite window' with output 'image'. It distinguishes the tool from siblings like get_canvas_preview by focusing on window-level capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a use case: 'Use to visually verify pixel art results.' It provides clear context but doesn't mention when not to use or name alternatives, which are not necessary given its uniqueness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![lentera-aseprite-mcp MCP server](https://glama.ai/mcp/servers/adityaairlangga12/lentera-aseprite-mcp/badges/card.svg)](https://glama.ai/mcp/servers/adityaairlangga12/lentera-aseprite-mcp)

Score Badge

Copy to your README.md:

[![lentera-aseprite-mcp MCP server](https://glama.ai/mcp/servers/adityaairlangga12/lentera-aseprite-mcp/badges/score.svg)](https://glama.ai/mcp/servers/adityaairlangga12/lentera-aseprite-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/adityaairlangga12/lentera-aseprite-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server