This server provides AI assistants with comprehensive programmatic control over Aseprite to create, edit, and export pixel art and animated sprites, offering 104 tools across 17 categories.
Canvas & Layer Management
Create new sprites with custom dimensions
Add, rename, duplicate, reorder, delete, and group layers; set visibility, opacity, and blend modes (19 modes)
Add and navigate frames, set frame durations
Drawing
Plot individual pixels, draw lines, rectangles, circles, ellipses, polygons, and paths
Flood-fill areas and apply linear gradient fills to rectangular regions
Target specific layers/frames, with optional cel creation
Animation
Add, delete, copy, and duplicate frames and frame ranges
Copy and propagate cels across frames and layers
Tween cel positions, opacity, and scale with easing; oscillate positions using sine-wave motion
Create and manage animation tags (forward, reverse, pingpong)
Configure onion skin settings
Palette & Color
Get and set the sprite palette; apply retro presets (Game Boy, PICO-8, C64, etc.)
Generate color ramps with hue shifting, quantize to palette, remap colors
Switch color modes (RGB, grayscale, indexed)
Effects & Transforms
Add outlines, replace colors, adjust HSL, apply ordered dithering
Flip layers horizontally/vertically, rotate (90°/180°/270°), resize, and crop the canvas
Slices & Tilemaps
Create named slice regions with 9-patch centers and pivot points
Create tilemap layers, edit tileset tiles, place tiles on a grid
Export & Import
Export to PNG, GIF, JPG, and sprite sheets (with metadata)
Per-layer/per-tag exports, import images as layers, duplicate sprite files
Inspection & Analysis
Read individual pixel colors or rectangular regions (RGBA/hex)
Get full sprite metadata (size, layers, frames, tags, durations)
Render onion skin ghosts, diff frames, get color histograms
Quality & Scene Tools
Validate scene consistency, audit animations for overlaps and out-of-range activity
Sanitize animation layer order and coverage
Copy layers between different sprite files
Preview, Workflow & Scripting
Start/stop a local HTTP preview server for exported files
Retrieve a step-by-step animation workflow guide for LLMs
Execute arbitrary Lua scripts as an escape hatch for unsupported operations
Provides tools for interacting with the Aseprite API, enabling management of sprites, animations, and layers.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Aseprite MCP create a new 256x256 sprite and draw a simple tree"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Python MCP server that gives AI assistants full control over Aseprite for creating pixel art and animated sprites.
104 tools across 17 categories — canvas, drawing, layers, animation, palettes, effects, slices, tilemaps, exports, visual-feedback/analysis tools, and a raw Lua escape hatch. The tool set is designed so an LLM has everything it needs to produce good pixel art, not just primitives: shading ramps with hue shifting, ordered dithering, outlines, retro palette presets with quantization, onion-skin renders, and frame diffing for animation work.
Both were created end-to-end by Claude Fable 5 through this server's MCP tools — drawing, checking its own work with scaled export_frame previews and render_onion_skin, then exporting. The tasks recreate the benchmark from Draw Me a Swordsman by Lj Miranda, whose findings inspired this server's expanded toolset.
Related MCP server: Aseprite-MCP
Category | Tools | Description |
6 | Create sprites, manage layers/frames, set the active state | |
14 | Pixels, lines, rectangles, circles, ellipses, polygons, paths, fills, gradients | |
3 | Draw and measure text with bitmap sprite-sheet or TrueType fonts | |
7 | Delete, rename, duplicate, reorder, blend modes, merge, flatten | |
4 | Move, copy, and erase rectangular regions or colors | |
5 | Outlines, color replacement, HSL adjustment, ordered dithering | |
24 | Frames, cels, tags, tweening with easing, propagation | |
8 | Get/set palettes, retro presets, color ramps, quantization, color modes | |
4 | Flip, rotate, resize, crop | |
5 | Named regions, 9-patch centers, pivot points | |
5 | Tilemap layers, tileset editing, tile placement | |
7 | PNG, GIF, sprite sheets, per-layer/per-tag export, image import | |
3 | Read pixels and sprite metadata | |
3 | Onion-skin renders, frame diffing, color statistics | |
4 | Validate and sanitize animation consistency | |
1 | Copy layers between sprite files | |
3 | Local HTTP preview server, workflow guide | |
1 | Raw Lua escape hatch for anything not covered above |
Tool | Description |
| Create a new sprite with the given dimensions |
| Add a new layer, optionally inside a named group |
| Add a new (optionally nested) group layer |
| Append a new frame |
| Set the active frame |
| Set one frame's duration in ms |
| Set the active layer (optionally creating it) |
All _at variants target a specific layer/frame and can create the cel on demand. Coordinates are sprite-global.
Tool | Description |
| Plot individual pixels with per-pixel colors |
| Plot pixels on a specific layer/frame |
| Lines with thickness |
| Outlined or filled rectangles |
| Outlined or filled circles |
| Outlined or filled ellipses with separate x/y radii |
| Outlined or filled polygons from a point list |
| Polyline through a point list with thickness |
| Paint-bucket flood fill |
| Smooth linear gradient fill in a rectangle |
Aseprite's Lua API has no text drawing, so glyphs are rasterised on the server and composited into the sprite. Two font backends are supported: bitmap sprite-sheet fonts (the right choice for pixel art — glyphs are already pixels and size scales them by whole numbers) and TrueType .ttf/.otf files, rendered without antialiasing unless you ask for it.
Fonts are discovered in ~/.aseprite-mcp/fonts: a bitmap font is a directory containing font.json plus its sheet PNGs; a TrueType font is just the font file. Installed system fonts are listed too. font also accepts a direct path.
Tool | Description |
| List the bitmap and TrueType fonts available to |
| Width, height, advance and baseline extents — size a panel or centre a label without redrawing to find out |
| Draw text with anchors, faux bold, outline, drop shadow and letter spacing |
Call measure_text first when the layout depends on the text: it returns the same metrics draw_text will use, so a label can be centred or a plate sized in one pass.
measure_text(text="MODERATOR", font="minecraft", size=2, bold=1)
-> width=115 height=15 advance_width=117 above_baseline=14 below_baseline=1 left_bearing=0
draw_text(filename="badge.aseprite", text="MODERATOR", x=64, y=17,
font="minecraft", size=2, anchor="baseline", bold=1,
color="#FFFFFF", shadow_color="#14237A")Anchors are topleft/top/topright, left/center/right, bottomleft/bottom/bottomright, plus baselineleft/baseline/baselineright for pinning several labels to one baseline. Outline and shadow grow the stamp but never move the glyphs.
{
"name": "my-font",
"letter_gap": 1,
"space_width": 3,
"sheets": [{
"file": "sheet.png",
"cell_w": 8, "cell_h": 8,
"ascent": 7,
"chars": [" !\"#$%&'()*+,-./", "0123456789:;<=>?"]
}],
"overrides": {
"86": {"ascent": 7, "rows": ["#...#", "#...#", ".#.#.", "..#.."]}
}
}Each sheet carries its own ascent, so sheets with different cell sizes still share a baseline — that is how a compact ASCII sheet and a taller accented sheet combine into one run. origin shifts the cell grid when the sheet has a margin, ink_rule: "dark" reads sheets that use an opaque white background to delimit variable-width glyph boxes, and advance: "box" takes the advance from the box rather than the ink. overrides replaces individual glyphs with hand-drawn rows, which is useful when a sheet ships a glyph that is off-centre or too tall to sit on the line.
Tool | Description |
| Delete a layer by name |
| Rename a layer |
| Duplicate a layer with all cels, opacity, and blend mode, optionally into a group |
| Move a layer to a position in the stack |
| Set blend mode (multiply, screen, overlay, ... 19 modes) |
| Merge a layer into the one below it |
| Flatten all layers into one |
Tool | Description |
| Cut a rectangle of pixels and paste it elsewhere |
| Copy a rectangle to another position, layer, or frame |
| Make a rectangle transparent |
| Magic-eraser: make all pixels of a color transparent (with tolerance) |
The pixel-art toolbox: clean outlines, palette-respecting blends, and shading variants.
Tool | Description |
| Add a 1px outline around all opaque pixels |
| Replace one color with another (with tolerance), preserving alpha |
| Shift hue/saturation/lightness of a cel — palette swaps, night scenes, shadows |
| Two-color gradient using Bayer 4×4 ordered dithering |
| Uniform dithered mix of two colors at a given density |
Tool | Description |
| Append N frames with optional duration |
| Delete a frame |
| Set every frame's duration |
| Duplicate a frame range N times |
| Copy all cels of a frame to other frames |
| Cel lifecycle on a layer/frame |
| Copy selected layers' cels across a frame range |
| Place a cel at x,y |
| Set a single cel's opacity |
| Shift cels by a delta across frames |
| Linear position tween across frames |
| Position tween with easing (ease_in/out, smoothstep) |
| Opacity tween with easing |
| Scale tween with easing and anchor |
| Sine-wave motion (bobbing, breathing, hovering) |
| Animation tags with direction (forward/reverse/pingpong) |
| Layer-level visibility and opacity |
| Configure onion-skin UI prefs (see |
| Sprite metadata: size, layers, frames, durations, tags |
Tool | Description |
| Read the palette as hex colors |
| Set the palette from a list of hex colors |
| List built-in retro palettes |
| Apply a preset: |
| Build a dark→light shading ramp with hue shifting from a base color |
| Snap every pixel to the nearest palette color |
| Remap specific colors across a frame range |
| Convert between RGB, grayscale, and indexed |
Tool | Description |
| Flip a cel horizontally or vertically |
| Rotate a cel 90/180/270° |
| Scale the sprite to new dimensions |
| Crop to a rectangle |
Tool | Description |
| Create a named rectangular region |
| Set the 9-patch stretchable center |
| Set the pivot point |
| List all slices with bounds, centers, pivots as JSON |
| Delete a slice |
Tool | Description |
| Add a tilemap layer with its own tileset and tile grid |
| Paint pixels into a tileset tile (auto-appends new tiles) |
| Place tiles on the map by grid position |
| Read which tile occupies a grid cell |
| Tile size, tile count, and map dimensions as JSON |
Tool | Description |
| Export to PNG, GIF, JPG, ... |
| Export one frame as PNG with integer upscaling — the core visual-feedback loop: draw, export at 8×, look, iterate |
| Sprite sheet (horizontal/vertical/rows/columns/packed) with optional JSON metadata and per-tag filtering |
| One PNG per layer |
| Export an animation tag as GIF or PNG sequence |
| Import a PNG into a layer (references, premade parts) |
| Duplicate the .aseprite file |
Tool | Description |
| Read one pixel's RGBA |
| Read a rectangle of pixels as JSON |
| Sprite metadata (also listed under Animation) |
Batch-mode equivalents of what a human artist gets from the Aseprite UI.
Tool | Description |
| Render a frame over translucent ghosts of neighboring frames — check motion continuity without opening Aseprite |
| Diff two frames: changed pixel count, percentage, bounding box |
| Color histogram of a frame — catches palette drift and near-duplicate colors |
Tool | Description |
| Create missing cels for layers across a frame range |
| Report missing layers/cels as JSON |
| Audit frames for overlaps and out-of-range layer activity |
| Normalize layer order, coverage, and overlaps |
Tool | Description |
| Copy layers by name from one .aseprite file to another |
Tool | Description |
| Serve exported files over local HTTP |
| Returns a step-by-step workflow guide for the LLM |
Tool | Description |
| Execute arbitrary Aseprite Lua (API docs) in batch mode. The escape hatch when no dedicated tool fits: one script can batch many operations into a single Aseprite launch. Remember to |
Plan the palette first: generate_color_ramp for each material (skin, armor, blade), or apply_palette_preset for a retro look.
Build in layers: background / body / equipment / effects, so parts can be animated and edited independently.
Draw coarse to fine: silhouette with draw_rectangle_at / draw_ellipse_at / fill_area_at, then refine with draw_pixels_at.
Look at your work: export_frame at 8×, inspect, fix, repeat. Use get_color_stats to keep the palette tight.
Shade with intent: adjust_hsl for shadow layers, apply_dither_gradient for blends, outline_cel for readability.
Animate with the cel tools: propagate_cels, then tween_cel_positions_eased / oscillate_cel_positions; verify with render_onion_skin and compare_frames; export with export_tag.
Build and run the Docker image:
docker build -t aseprite-mcp:latest .
docker run -it --rm aseprite-mcp:latestOr use the provided build scripts:
Linux/macOS: chmod +x build-docker.sh && ./build-docker.sh
Windows: .\build-docker.ps1
# Production
docker-compose up aseprite-mcp
# Development mode
docker-compose --profile dev up aseprite-mcp-devSee DOCKER.md for detailed Docker setup instructions.
To have the container install Aseprite via SteamCMD at startup, provide Steam credentials:
# Create a .env with STEAM_USERNAME/STEAM_PASSWORD (and optional STEAM_GUARD_CODE)
# Then
docker run --rm -i --env-file .env aseprite-mcp:latestIf installed, the binary will be at /opt/steamapps/common/Aseprite/aseprite and ASEPRITE_PATH will be picked up automatically.
Python 3.13+
uv package manager
Aseprite (set ASEPRITE_PATH in .env if it is not on your PATH)
{
"mcpServers": {
"aseprite": {
"command": "/opt/homebrew/bin/uv",
"args": [
"--directory",
"/path/to/repo",
"run",
"-m",
"aseprite_mcp"
]
}
}
}Add a new frame to the Aseprite file.
Args: filename: Name of the Aseprite file to modify
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description provides no behavioral details beyond the basic action. Missing information about side effects, constraints (e.g., file must exist), or whether frames are appended.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two clear sentences. It is front-loaded with the action. However, it could include more structured information like argument format without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a minimal tool with one parameter and no output schema, the description covers the basic purpose. However, it omits context about the resulting frame (e.g., position, duration) and any required file state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains that 'filename' is the name of the Aseprite file to modify, which adds meaning beyond the schema's type definition. However, it lacks specificity (e.g., path format, file extension) and does not explain any additional parameters (none provided, but schema has 1 parameter).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a new frame') and the resource ('Aseprite file'), which is distinct from siblings like 'add_frames' (plural) and 'copy_frame'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'add_frames' for multiple frames, or 'copy_frame'). No context about prerequisites or intended use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add multiple frames to a sprite and optionally set their duration.
Args: filename: Name of the Aseprite file to modify count: Number of frames to add duration_ms: Optional duration for each new frame in milliseconds
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| count | Yes | ||
| duration_ms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the mutation (adds frames) and optional duration, but does not detail side effects, file modification behavior, or return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-line description plus argument list is efficient and front-loaded; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation with 3 parameters and no output schema, the description covers purpose and key constraints; lacks mention of frame insertion position but is otherwise adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It clarifies each parameter's role and adds unit context for duration_ms (milliseconds), which is beyond schema specs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds multiple frames to a sprite and optionally sets duration, distinguishing it from sibling 'add_frame' which adds a single frame.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'add_frame' or other frame manipulation tools; usage is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new layer to the Aseprite file.
Args: filename: Name of the Aseprite file to modify layer_name: Name of the new layer
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states the action but does not disclose side effects (e.g., what happens if layer already exists), success/failure conditions, or any required permissions. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with clear argument listing. However, it could be more structured by presenting the purpose in a single sentence upfront and using a more standard parameter format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not mention return values, error handling, or preconditions. For a mutation tool, this leaves significant gaps in understanding what the agent should expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description is the only parameter documentation. It provides a brief one-line description for each parameter but lacks details like file path format, layer naming constraints, or default values. Adequate but minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a new layer to an Aseprite file, specifying the action, resource, and target. However, it doesn't differentiate from similar sibling tools like set_layer or ensure_layers_present, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks any context about prerequisites, when not to use it, or how it relates to other layer manipulation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Normalize animation consistency and optionally apply fixes.
layer_frame_ranges format: ["layer:1-8,17-24", "clouds:1-12"] out_of_range_action: "set_opacity_zero", "delete_cels", "none" ignore_full_canvas_overlaps: skip overlap checks when a cel is full canvas Returns JSON for AI consumption (summary, layer_stats, alerts, overlaps).
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| start_frame | No | ||
| end_frame | No | ||
| layer_names | No | ||
| layer_order | No | ||
| layer_frame_ranges | No | ||
| ensure_layers | No | ||
| overlap_pairs | No | ||
| report_bounds | No | ||
| max_overlaps | No | ||
| ignore_full_canvas_overlaps | No | ||
| out_of_range_action | No | set_opacity_zero | |
| out_of_range_opacity | No | ||
| report_only | No | ||
| include_stats | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions that fixes can be applied optionally and returns JSON, but it does not disclose whether the tool is destructive, requires authentication, or its idempotency. Behavioral traits are minimally conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose. It includes necessary format examples without excessive verbosity. However, it could be better structured with bullet points or grouping.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, no output schema), the description lacks completeness. It does not explain the function of many parameters, return value details, or error handling. Significant gaps remain for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains three parameters (layer_frame_ranges, out_of_range_action, ignore_full_canvas_overlaps) with format examples, leaving 12 parameters undocumented. This is insufficient for a tool with 15 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Normalize animation consistency and optionally apply fixes.' It provides specific examples of parameter formats and mentions that it returns JSON for AI consumption. However, it does not explicitly differentiate from sibling tools like audit_animation or validate_scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking and fixing animation consistency, but it does not provide explicit guidance on when to use this tool versus alternatives. No when-not-to-use or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a concise English guide for optimized animation workflows.
| Name | Required | Description | Default |
|---|---|---|---|
| use_case | No | character |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description is minimal—it does not disclose what the guide covers, its format, or that it is a read-only informational tool, leaving behavioral traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words, but it could include more detail without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a single undocumented parameter, the description is too sparse—it omits what the guide contains, acceptable use_case values, and return format, making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the only parameter 'use_case' beyond its default 'character'; schema provides no description, and the tool fails to add meaning, leaving valid values ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a concise guide for optimized animation workflows, distinguishing it from sibling action tools like add_frame or draw_pixels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied as a reference for workflows, but no explicit when-to-use or when-not-to-use instructions are provided; siblings are all action tools, so it is distinct but lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a linear gradient fill to a rectangle.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| frame_index | Yes | ||
| x | Yes | ||
| y | Yes | ||
| width | Yes | ||
| height | Yes | ||
| color_start | Yes | ||
| color_end | Yes | ||
| horizontal | No | ||
| create_if_missing | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only says 'apply a linear gradient fill', which implies mutation but lacks details on side effects, error handling, or behavioral constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (8 words) but lacks necessary detail. It is efficient but overly terse for a tool with many parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and no annotations, the description is far too minimal. It does not cover return values, side effects, or usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the tool description provides no information about any of the 11 parameters. Parameters like color_start, horizontal, or create_if_missing remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'apply' and the objects 'linear gradient fill' and 'rectangle'. It is specific enough to distinguish from sibling tools like fill_area or draw_rectangle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No mention of prerequisites, when not to use, or relation to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit animation frames for overlaps and out-of-range layer activity.
overlap_pairs format: ["layerA,layerB", "layerC:layerD"] layer_frame_ranges format: ["layer:1-8,17-24", "clouds:1-12"] Returns JSON for AI consumption (summary, overlaps, out_of_range, optional cels).
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| start_frame | No | ||
| end_frame | No | ||
| layer_names | No | ||
| overlap_pairs | No | ||
| layer_frame_ranges | No | ||
| report_cels | No | ||
| report_bounds | No | ||
| max_overlaps | No | ||
| max_out_of_range | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions it returns JSON for AI consumption, implying a non-destructive audit. However, without annotations, it does not explicitly state whether the tool is read-only or if it has any side effects. The behavioral disclosure is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus format examples) and front-loaded with the purpose. The examples add necessary detail, but the overall structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and no annotations, the description is incomplete. It lacks explanations for most parameters, usage context, and clear behavioral guarantees, making it insufficient for an agent to fully understand the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It provides format examples for overlap_pairs and layer_frame_ranges, explaining their expected structure. However, the other 8 parameters (end_frame, start_frame, max_overlaps, etc.) are not explained, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audits animation frames for overlaps and out-of-range layer activity. The verb 'audit' and specific resources 'overlaps' and 'out-of-range' precisely define its purpose, distinguishing it from sibling tools like validate_scene or animation_sanitize.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when-not to use, or comparisons to related tools, leaving the agent without decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a cel on a layer/frame.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| frame_index | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only states the action without disclosing effects (e.g., destructive, irreversible), permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence. However, it lacks structure and may be too terse at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three required parameters and no output schema, the description is incomplete. It omits parameter details, prerequisites, and return information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds no meaning to the three parameters (filename, layer_name, frame_index). Does not explain their roles or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('delete') and the resource ('a cel on a layer/frame'). It distinguishes from sibling tools like delete_frame or copy_cel, but lacks definition of 'cel' and context on layers/frames.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines provided. The description does not indicate when to use this tool versus alternatives like copy_cel, delete_frame, or set_cel_opacity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Copy a cel from one frame to another.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| source_frame | Yes | ||
| target_frame | Yes | ||
| replace | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral details like whether the copy is destructive, if it includes all cel properties, or the effect of the 'replace' parameter. The tool is a mutation but this is not clarified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one sentence) but omits essential details, making it under-specified rather than efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and no output schema, the description is severely incomplete. It does not explain what a cel is, prerequisites, return behavior, or the role of 'filename'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% description coverage. The description does not explain any parameter, including the critical 'replace' boolean or the ambiguous 'filename' parameter. An agent cannot infer correct usage from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (copy) and the resource (cel) and the context (from one frame to another). It distinguishes from siblings like 'copy_frame' or 'clear_cel' by specifying the cel-level operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'copy_frame' or 'create_cel'. The description lacks 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.
Copy all cels from a source frame to a target frame (or append).
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| source_frame | Yes | ||
| target_frame | No | ||
| overwrite | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It mentions copying and appending but does not explain the 'overwrite' parameter or what happens if the target frame already has cels. The phrase 'or append' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. However, it could be slightly more structured by separating copying and appending actions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no annotations, and no output schema, the description is minimal. It does not mention prerequisites (e.g., frames must exist), return value, or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It adds meaning for source and target frames but does not explain 'filename' or 'overwrite'. The parameter semantics are mostly left to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool copies all cels from a source frame to a target frame, using a specific verb and resource. It distinguishes from sibling tools like 'copy_cel' which copies individual cells.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'copy_cel' or 'duplicate_frame'. The description does not provide context for when copying entire frames is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Copy layers by name from a source sprite to a target sprite.
Args: source_filename: Source .aseprite file target_filename: Target .aseprite file layer_names: List of layer names to copy replace: Overwrite existing cels in target layers create_missing_frames: Add frames to target if needed
| Name | Required | Description | Default |
|---|---|---|---|
| source_filename | Yes | ||
| target_filename | Yes | ||
| layer_names | Yes | ||
| replace | No | ||
| create_missing_frames | No |
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 mentions replace and create_missing_frames, but lacks details on prerequisites (files must exist, target must have matching layers), error handling, or whether operation is destructive. For a tool with no annotations, this 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus bullet-point parameter list. Every word adds value, no fluff. Front-loaded with the purpose, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description covers basic operation and parameter meanings. However, it lacks important context like return value, error cases, and prerequisites (e.g., source and target files must be open). Completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It provides brief but functional explanations for each parameter (e.g., 'replace: Overwrite existing cels in target layers'). However, it omits constraints like file path format or layer existence requirements, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool copies layers by name from a source sprite to a target sprite. The verb 'copy' and resource 'layers' are specific, and the target/source distinction differentiates it from siblings like duplicate_layer (same sprite) or copy_sprite (entire sprite).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like copy_sprite or duplicate_layer. The description lacks exclusions or context that would help an agent decide between similar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Copy a sprite to a new Aseprite file.
Args: filename: Name of the Aseprite file to copy output_filename: Name of the output .aseprite file overwrite: Whether to overwrite if output exists
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| output_filename | Yes | ||
| overwrite | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It states 'copy a sprite to a new file' but does not mention whether the original is modified, what happens if the output file exists without overwrite, or any side effects. The overwrite parameter is listed but its effect is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point, with a clear list of arguments. It is well-structured and avoids unnecessary words, though it could benefit from a short sentence about each parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete. It does not mention return values, error cases, prerequisites (e.g., file existence), or any constraints. For a file copy operation, more detail is needed for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It lists parameter names but provides no additional details beyond the schema (e.g., no format hints for filenames, no explanation of overwrite behavior). The defaults are not clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool copies a sprite to a new Aseprite file. The verb 'copy' and resource 'sprite' are specific, and the tool distinguishes itself from siblings like copy_cel or copy_frame by operating on the entire sprite and creating a new file. However, no explicit differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like copy_cel or copy_layers_between_sprites. There is no mention of prerequisites, conditions, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Aseprite canvas with specified dimensions.
Args: width: Width of the canvas in pixels height: Height of the canvas in pixels filename: Name of the output file (default: canvas.aseprite)
| Name | Required | Description | Default |
|---|---|---|---|
| width | Yes | ||
| height | Yes | ||
| filename | No | canvas.aseprite |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It states it creates a new canvas but does not discuss overwrite behavior if the file exists, error handling for invalid dimensions, or side effects like file system writes. The return value is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one introductory sentence followed by a clear list of arguments. No extraneous information, and each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool, the basics are covered, but it lacks details on what happens on success (e.g., is the canvas opened in the UI?), error cases, and file overwrite policy. With no output schema, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema properties have no descriptions (0% coverage). The description compensates by explaining each parameter: width and height are pixels, filename defaults to 'canvas.aseprite'. This adds essential meaning beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new Aseprite canvas with specified dimensions. The verb 'Create' and resource 'canvas' are specific, and the tool is distinct from siblings like 'crop_canvas' or 'resize_canvas' which modify existing canvases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates creation of a new canvas, but does not provide explicit guidance on when to use vs. alternatives like importing an image or modifying an existing canvas. No conditions or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an empty cel on a layer/frame.
Args: filename: Name of the Aseprite file to modify layer_name: Layer name to target frame_index: Frame index starting at 1 x: X position in pixels y: Y position in pixels
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| frame_index | Yes | ||
| x | No | ||
| y | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must bear the burden of behavioral disclosure. It only states 'create an empty cel' without mentioning side effects (e.g., overwriting cels), permissions required, or error scenarios. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence followed by a structured parameter list. It front-loads the purpose and uses a clear format. It earns a high score but not perfect because the parameter list is somewhat sparse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations. The description does not explain return value, prerequisites (file/layer/frame existence), or error handling. It minimally covers the creation action but omits important usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds value by listing each parameter and its role (e.g., 'filename: Name of the Aseprite file to modify'). However, it provides minimal detail beyond the schema's names and types, no constraints or formatting rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create an empty cel') and the scope ('on a layer/frame'). It is specific and distinguishes from siblings like `clear_cel` or `copy_cel`. However, it assumes familiarity with the term 'cel' and does not explicitly differentiate, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like `copy_cel`, `clear_cel`, or `set_cel_opacity`. There is no indication of prerequisites (e.g., file must exist) or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crop the canvas to the given rectangle, discarding content outside it.
Args: filename: Aseprite file to modify x: Left edge of the crop area y: Top edge of the crop area width: Width of the crop area height: Height of the crop area
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| x | Yes | ||
| y | Yes | ||
| width | Yes | ||
| height | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions 'discarding content outside it', indicating destructive behavior. However, lacks details on irreversibility, what happens to other layers, or whether it modifies the file in-place. With no annotations, the description carries the burden but is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one sentence explaining purpose followed by a minimal Args list. No redundant or unnecessary text. Front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and parameters, but missing details like return value (if any), error conditions, or behavior edge cases (e.g., invalid rectangle). For a straightforward tool with no output schema or annotations, slightly more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description compensates with an Args section listing each parameter and a brief description (e.g., 'filename: Aseprite file to modify'). These add basic meaning beyond the schema titles, though they are terse.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Crop the canvas to the given rectangle, discarding content outside it', defining the verb (crop), resource (canvas), and effect (discard outside). Distinguishes from siblings like resize_canvas and create_canvas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. For example, it doesn't mention that resize_canvas might be preferred for non-destructive resizing. The description assumes the user already knows when to crop.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draw a circle on the canvas.
Args: filename: Name of the Aseprite file to modify center_x: X coordinate of circle center center_y: Y coordinate of circle center radius: Radius of the circle in pixels color: Hex color code (default: "#000000") fill: Whether to fill the circle (default: False)
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| center_x | Yes | ||
| center_y | Yes | ||
| radius | Yes | ||
| color | No | #000000 | |
| fill | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions drawing a circle but does not disclose whether it overwrites existing content, blends, or creates new layers. The side effects (e.g., modifying the file) are implicit but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence plus a parameter list. It is well-structured and avoids unnecessary words, though the parameter list could be integrated more naturally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of drawing tools among siblings, the description is minimal. It does not mention the current layer or frame context, nor does it describe the return value or success conditions. The default values for color and fill are provided, but more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides meaningful explanations for each parameter (e.g., 'center_x: X coordinate of circle center'), which the input schema lacks (schema coverage 0%). This adds value beyond the schema properties that only have titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool draws a circle on the canvas, specifying the verb and resource. However, it does not differentiate from sibling tools like draw_circle_at, which likely has a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., draw_ellipse_at, draw_rectangle). There is no mention of prerequisites or context such as current layer or frame.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draw a circle on a specific layer/frame.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| frame_index | Yes | ||
| center_x | Yes | ||
| center_y | Yes | ||
| radius | Yes | ||
| color | No | #000000 | |
| fill | No | ||
| create_if_missing | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully needs to disclose behavioral traits such as side effects, creation behavior (create_if_missing), or overwrite behavior, but it provides none. It only repeats the 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and very concise, but it is under-specified. Important information is missing, so conciseness trades off completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters (6 required), no output schema, and no annotations, the description is severely lacking. It does not cover the most critical aspects: coordinates, color, fill, or layer/frame creation behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate by explaining key parameters. It does not mention center_x, center_y, radius, color, fill, or create_if_missing, leaving the agent to infer from names, which may be ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Draw), resource (a circle), and context (on a specific layer/frame). The name 'draw_circle_at' reinforces targeting a specific location, distinguishing it from sibling 'draw_circle' which likely draws without specifying location.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'draw_circle' or 'draw_ellipse_at'. There is no mention of prerequisites, edge cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draw a line on the canvas.
Args: filename: Name of the Aseprite file to modify x1: Starting x coordinate y1: Starting y coordinate x2: Ending x coordinate y2: Ending y coordinate color: Hex color code (default: "#000000") thickness: Line thickness in pixels (default: 1)
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| x1 | Yes | ||
| y1 | Yes | ||
| x2 | Yes | ||
| y2 | Yes | ||
| color | No | #000000 | |
| thickness | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose side effects, coordinate system, or behavior when parameters are out of bounds. Minimal transparency beyond the 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Succinct first sentence followed by a well-organized Args list. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides parameter details but lacks behavioral context (e.g., pixel replacement, canvas bounds). With no output schema, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section thoroughly explains each parameter, including defaults for color and thickness, and the meaning of filename. This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Draw a line on the canvas,' specifying the verb and resource. Among many drawing sibling tools, this uniquely identifies the action of drawing a line.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like draw_path or draw_rectangle. No prerequisites or contextual cues provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draw a line on a specific layer/frame.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| frame_index | Yes | ||
| x1 | Yes | ||
| y1 | Yes | ||
| x2 | Yes | ||
| y2 | Yes | ||
| color | No | #000000 | |
| thickness | No | ||
| create_if_missing | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'draw a line'. It does not disclose any side effects, coordinate system, behavior if layer/frame missing (despite a create_if_missing parameter), or whether it overwrites existing lines. The description is insufficient for an agent to anticipate tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that directly states the core purpose. It is front-loaded and contains no filler. Every word earns its place, though it could be expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters, 7 required, and no output schema or annotations. The description is minimal and does not explain return values, coordinate system, interaction with existing content, or error conditions. Given the tool's complexity, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate but doesn't describe any parameters. While parameter names like x1,y1,x2,y2 are intuitive, the description adds no context about formats (e.g., color hex format, thickness units, create_if_missing implications). The agent relies solely on schema titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (draw a line) and the target context (specific layer/frame). This distinguishes it from similar sibling tools like 'draw_line' (which likely uses current layer/frame) and other draw-at tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool over alternatives, nor any prerequisites or conditions. Siblings like 'draw_line' are not mentioned, and there is no hint about when to choose this tool vs others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draw a path using a polyline on a specific layer/frame.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| frame_index | Yes | ||
| points | Yes | ||
| color | No | #000000 | |
| thickness | No | ||
| create_if_missing | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions drawing on a specific layer/frame but does not clarify behavior when layer/frame is missing (despite create_if_missing parameter), whether it overwrites or appends, or any side effects like modification of existing content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is concise but under-specifies; it is not overloaded but lacks necessary detail for a tool with 7 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, 7 parameters, and many sibling tools, the description is incomplete. It does not explain return values, error behavior, or how the tool interacts with existing drawing or animation state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no explanation of parameters (filename, layer_name, frame_index, points, color, thickness, create_if_missing). The agent must rely solely on parameter names and types, which is insufficient for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Draw' and resource 'path using a polyline on a specific layer/frame,' which distinguishes it from other drawing tools like draw_circle or draw_line. However, it could be more precise about whether 'path' means a continuous polyline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use draw_path vs alternatives such as draw_line, draw_polygon, or draw_pixels. Lacks context for selection among many similar sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draw pixels on the canvas with specified colors.
Args: filename: Name of the Aseprite file to modify pixels: List of pixel data, each containing: {"x": int, "y": int, "color": str} where color is a hex code like "#FF0000"
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| pixels | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It fails to disclose whether pixels overwrite or blend, what happens with out-of-bounds coordinates, or if any prerequisites exist. The description is too minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence for purpose followed by a clean Args list. No unnecessary words, and the structure is front-loaded and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers parameter usage adequately. However, it lacks behavioral context (e.g., layer interaction, result feedback) that would help an agent use it correctly in complex workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description clearly documents both parameters, including the expected structure for pixels (x, y, color with hex format). This adds significant value beyond the schema's bare titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it draws pixels on a canvas with specified colors, using a verb and resource. It distinguishes from siblings like draw_circle or draw_line by specifying it draws individual pixels from a list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like draw_pixels_at or draw_line. Missing context on when it's appropriate to use pixel-level drawing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draw pixels on a specific layer/frame.
Args: filename: Name of the Aseprite file to modify layer_name: Layer name to target frame_index: Frame index starting at 1 pixels: List of pixel data with x/y/color create_if_missing: Create cel if it does not exist
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| frame_index | Yes | ||
| pixels | Yes | ||
| create_if_missing | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies a write operation but does not disclose side effects (e.g., overwrite vs. blend), coordinate system, or color format. The create_if_missing parameter hints at behavior but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief and includes an args section with parameter names. It is appropriately sized for a simple tool, but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description lacks critical information: return value, coordinate system, color format, and behavior on missing cel. This is insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds minimal meaning: 'pixels: List of pixel data with x/y/color' provides some context, but other parameters (filename, layer_name, frame_index) are self-explanatory. Overall, low additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Draw pixels on a specific layer/frame', which specifies the action and target, distinguishing it from siblings like draw_pixels (likely current layer/frame).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., draw_pixels, draw_line_at). The description only lists parameters without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draw a polygon on a specific layer/frame.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| frame_index | Yes | ||
| points | Yes | ||
| color | No | #000000 | |
| fill | No | ||
| create_if_missing | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It fails to mention whether the polygon is auto-closed, how points are interpreted, or side effects like overwriting. This 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy, but it is too brief and omits essential guidance. It is concise but at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 7 parameters with 0% description coverage, the description fails to provide adequate context about return values, error handling, or parameter constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description adds no meaning to parameters like point format (required integer keys?), color format, fill behavior, or create_if_missing. The agent must guess from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Draw a polygon on a specific layer/frame' clearly states verb and resource, and distinguishes from sibling drawing tools like draw_line, draw_rectangle, draw_circle, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., draw_rectangle) or when not to use it. There is no context for filling, color, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draw a rectangle on the canvas.
Args: filename: Name of the Aseprite file to modify x: Top-left x coordinate y: Top-left y coordinate width: Width of the rectangle in pixels (must be > 0) height: Height of the rectangle in pixels (must be > 0) color: Hex color code (default: "#000000") fill: Whether to fill the rectangle (default: False)
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| x | Yes | ||
| y | Yes | ||
| width | Yes | ||
| height | Yes | ||
| color | No | #000000 | |
| fill | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does not disclose behavioral traits such as whether the rectangle is drawn on the current layer, what happens with out-of-bounds coordinates, or if previous pixels are overwritten. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring with a clear purpose sentence followed by a parameter list. It is concise and front-loaded, with no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no annotations, and no output schema, the description is incomplete. It omits return value/confirmation, error conditions, and the tool's effect on the sprite state (e.g., which layer/frame is affected).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description lists parameters with brief explanations (e.g., 'Width of the rectangle in pixels (must be > 0)') and defaults. This adds moderate value beyond the schema's type definitions, but many parameters lack deeper details (e.g., coordinate system origin).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Draw a rectangle on the canvas') with a specific verb and resource. It distinguishes from sibling tools like draw_circle or draw_line, which have similar but different shapes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., draw_rectangle_at, fill_area). There is no mention of when not to use it or what prerequisites are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draw a rectangle on a specific layer/frame.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| frame_index | Yes | ||
| x | Yes | ||
| y | Yes | ||
| width | Yes | ||
| height | Yes | ||
| color | No | #000000 | |
| fill | No | ||
| create_if_missing | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether the rectangle is filled, outlines, replaces existing content, or uses current styles. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no extraneous words. It is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no output schema, and no parameter descriptions, the description is too minimal. It does not explain drawing behavior, error cases, or coordinate system, leaving the agent without enough context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter explanations. The description adds no value beyond parameter names. For a tool with 10 parameters, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (draw a rectangle) and the target (specific layer/frame). It distinguishes from sibling tools like draw_rectangle which may not target a layer/frame. However, it could be more precise about the coordinate system or units.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like draw_rectangle or draw_circle. There is no mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Duplicate a frame range and append copies to the end.
Args: filename: Name of the Aseprite file to modify start_frame: Starting frame index (1-based) end_frame: Ending frame index (1-based, inclusive) times: Number of times to append the range (default: 1)
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| start_frame | Yes | ||
| end_frame | Yes | ||
| times | No |
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 action (duplicate and append) and parameter details (1-based, inclusive, default). However, it does not disclose potential side effects like frame shifting or whether original frames are preserved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single action sentence followed by a clean Args list. Each parameter is explained in one line. No redundant information, but the structure could be slightly improved by separating the overview from parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description covers the core functionality and parameter semantics adequately. It lacks details about return value or side effects, but given the tool's simplicity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by clarifying that start_frame is 1-based, end_frame is inclusive, and times has a default of 1. The schema only provides types and titles, so the description provides necessary context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Duplicate' and the resource 'frame range', specifying the action 'append copies to the end'. This distinguishes it from sibling tools like 'copy_frame' (single frame) and 'duplicate_layer' (layer-level).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for duplicating a range of frames, but does not mention when not to use it or provide comparisons with sibling tools like 'copy_frame' or 'add_frames'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ensure cels exist for layers across a frame range.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_names | Yes | ||
| start_frame | No | ||
| end_frame | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose critical behaviors: whether cels are created if missing, whether existing cels are overwritten, what happens if layers don't exist, or the return value. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is front-loaded with the key action and scope. However, it sacrifices depth for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no annotations, no output schema, and zero schema descriptions, the description is woefully incomplete. It fails to explain behavior, parameter roles, or return values. A minimal viable description would need more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no parameter detail. The tool name and description hint at what 'layer_names', 'start_frame', and 'end_frame' do, but there is no explicit explanation. For a tool with 4 parameters, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'ensure' and the resource 'cels exist for layers across a frame range'. It distinguishes from sibling tools like 'create_cel' (single cel) and 'propagate_cels' (duplication). However, it could be more precise about whether it creates cels if missing or only checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Among sibling tools like 'create_cel', 'copy_cel', 'propagate_cels', there is no indication of the specific use case. The description implies a batch operation but offers no context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the Aseprite file to another format.
Args: filename: Name of the Aseprite file to export output_filename: Name of the output file format: Output format (default: "png", can be "png", "gif", "jpg", etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| output_filename | Yes | ||
| format | No | png |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description lacks behavioral details such as whether the original file is modified, overwriting behavior, or error handling. It only mentions the export function and allowed formats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence followed by a bulleted parameter list. No unnecessary information, front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers parameters adequately for a simple export, it lacks output format details, usage context, and behavioral notes. Given no output schema and no annotations, it is minimally complete but could be more thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by explaining each parameter: filename, output_filename, and format (with default and examples). This adds meaningful context beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports an Aseprite file to another format using the verb 'Export'. It distinguishes itself from sibling tools like export_frame, export_layers, and export_spritesheet by targeting the entire sprite file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other export tools (e.g., export_frame, export_layers). The description only states what it does, not when or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill an area with color using the paint bucket tool.
Args: filename: Name of the Aseprite file to modify x: X coordinate to fill from y: Y coordinate to fill from color: Hex color code (default: "#000000")
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| x | Yes | ||
| y | Yes | ||
| color | No | #000000 |
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 merely states it uses a paint bucket tool with coordinates and color, but omits details like whether the fill is destructive, applies to all layers, or how boundaries are determined (e.g., alpha threshold). The default color of black is noted but not the effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence stating the tool's purpose, followed by a compact parameter listing in a consistent format. No unnecessary words or repetition. Front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0% schema coverage, no output schema, and no annotations, the description is incomplete. It explains parameters but fails to describe return values, error conditions, or side effects (e.g., whether the file is modified in place). A paint bucket tool typically has flood-fill semantics that are not documented. Compared to the tool's complexity, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides explanations for all 4 parameters: filename as 'Name of the Aseprite file to modify', x and y as coordinates to fill from, and color as a hex code with default. This adds meaning beyond the schema's type and title fields, though more detail on coordinate system (e.g., layer vs canvas) would improve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'fills an area with color using the paint bucket tool', specifying the verb (fill), resource (area), and method (paint bucket). This distinguishes it from sibling tools like fill_area_at which likely use a different approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or when not to use it. Sibling tools exist for similar operations but no comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill an area on a specific layer/frame.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| frame_index | Yes | ||
| x | Yes | ||
| y | Yes | ||
| color | No | #000000 | |
| create_if_missing | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It fails to mention that this is a flood fill starting at (x,y), whether it operates on the visible layer or entire frame, or if it is destructive. There is no indication of side effects, such as modifying existing pixels or requiring specific layer states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but at the expense of necessary detail. It front-loads the main action but omits essential information, making it insufficient for correct tool use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and many siblings with similar names, the description is severely incomplete. It does not explain the fill algorithm, how to interpret results, or any constraints. Users must guess the tool's behavior from the name and schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, yet the tool description adds no parameter explanations. Key parameters like 'x', 'y' (start point), 'color' (fill color), and 'create_if_missing' (behavior when layer missing) are not clarified. The description solely mentions 'layer/frame' without elaborating on any parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Fill an area on a specific layer/frame,' which identifies the action and target but is vague. It does not distinguish from the sibling tool 'fill_area' or clarify whether this is a flood fill, rectangle fill, or other operation. The purpose is clear enough but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'fill_area', 'draw_pixels_at', or other fill-related tools. There is no mention of prerequisites, context, or scenarios where this tool should be chosen over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flip a layer's image horizontally or vertically.
Args: filename: Aseprite file to modify layer_name: Layer name to flip frame_index: Frame index starting at 1 direction: "horizontal" or "vertical"
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| frame_index | Yes | ||
| direction | No | horizontal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the operation is destructive, if it modifies the file immediately, or any side effects. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a clear one-line purpose followed by a minimal parameter list. Every sentence earns its place, and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool modifies a layer and has no output schema, the description omits crucial context like return value, error conditions, prerequisites (e.g., file must exist, layer must be unlocked), and how it interacts with frame_index. It is insufficient for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists all four parameters and adds value by specifying that frame_index starts at 1 and direction accepts 'horizontal' or 'vertical'. However, detailed semantics (e.g., required format for filename, behavior of direction default) are not provided, and schema coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Flip a layer's image horizontally or vertically' clearly states the action (flip), the resource (layer's image), and the possible directions. It immediately distinguishes from sibling tools like rotate_layer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for mirroring a layer, but provides no explicit guidance on when to use this tool versus alternatives (e.g., rotate_layer, invert_colors) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the active sprite palette as a JSON array of hex colors.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the return format but does not mention potential errors (e.g., missing sprite, invalid filename), side effects (none expected), or permission requirements. The tool is read-only but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the action, resource, and output. However, it could be slightly expanded to include crucial parameter context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, no annotations, and no output schema, the description is incomplete. It fails to explain the role of the filename, potential errors, or how the palette is obtained. Given the many sibling tools, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no meaning to the 'filename' parameter. It does not explain what the filename refers to (sprite file, path, etc.) or how it relates to the palette. The description provides zero added value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('active sprite palette'), and the output format ('JSON array of hex colors'). However, it does not differentiate from siblings like extract_palette or set_palette, and the term 'active sprite' is ambiguous given the required filename parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as extract_palette, set_palette, or list_palette_presets. No context for prerequisites or exclusions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the RGBA color of a single pixel.
Args: filename: Aseprite file to read x: X coordinate y: Y coordinate layer_name: Layer to read from (uses active layer when empty) frame_index: Frame index starting at 1
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| x | Yes | ||
| y | Yes | ||
| layer_name | No | ||
| frame_index | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It explains the parameters (layer, frame) but does not mention error handling for out-of-bounds coordinates or the exact return format (though RGBA is implied). It is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear first sentence and an organized Args list. It efficiently conveys the purpose and parameter semantics without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While parameters are well explained, the return value is only implied ('RGBA color') and not explicitly stated. No output schema exists, so the description should specify the format of the returned color.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides meaningful details for all parameters, e.g., 'Layer to read from (uses active layer when empty)' and 'Frame index starting at 1.' This adds significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read the RGBA color of a single pixel,' which is a specific verb+resource. It naturally distinguishes from sibling tools like 'get_pixels_rect' or 'get_composite_pixel' that read multiple pixels or composite values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools for reading pixel data (e.g., get_composite_pixel, get_pixels_rect), explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read all pixel colors in a rectangular region.
Args: filename: Aseprite file to read x: Top-left x coordinate y: Top-left y coordinate width: Width of the region height: Height of the region layer_name: Layer to read from (uses active layer when empty) frame_index: Frame index starting at 1
Returns: JSON array of {x, y, hex, r, g, b, a} objects
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| x | Yes | ||
| y | Yes | ||
| width | Yes | ||
| height | Yes | ||
| layer_name | No | ||
| frame_index | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It states the operation is a read ('Read all pixel colors'), which implies non-destructiveness, but does not detail permissions, file existence requirements, or coordinate system origin. The return format is covered, but deeper behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a clear docstring format with Args and Returns sections, front-loading the main purpose. It is reasonably concise without extraneous content, though the return format repetition could be trimmed slightly. Overall efficient and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers return format (JSON array of pixel objects) and all parameters, which is good for a read tool. However, it omits context like coordinate origin, error handling, file must exist, and behavior when layer is missing. Given the tool's complexity (7 params, no output schema), additional contextual details would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists all 7 parameters with brief explanations (e.g., 'Top-left x coordinate'), adding some meaning beyond parameter names. However, it lacks constraints like bounds, valid file types, or input validation rules, leaving gaps in full understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read all pixel colors in a rectangular region,' specifying the verb (read) and resource (pixel colors in a region). It distinguishes from sibling tools like get_pixel_color (single pixel) and get_composite_rect (composite), so purpose is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading region pixel data via the Args list, but it does not explicitly state when to use this tool versus alternatives (e.g., get_pixel_color for single pixel). No when-not scenarios are mentioned, leaving guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return sprite info as JSON string (size, frame count, layers).
Args: filename: Name of the Aseprite file to inspect
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It implies read-only operation but does not explicitly state that no modifications occur, nor does it mention permissions, rate limits, or side effects. The return format is described, but behavioral traits beyond that are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short sentences, front-loading the purpose. It uses a clear structure with an Args section. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return value contents (size, frame count, layers) but remains vague about completeness. It does not address error cases, file not found, or other edge behaviors. For a simple info tool, it is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining the sole parameter 'filename' as 'Name of the Aseprite file to inspect'. This adds meaning beyond the raw schema, which only provides the type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns sprite info as JSON string with size, frame count, and layers. The verb 'Return' and resource 'sprite info' are specific. However, it does not differentiate from sibling info-getters like get_palette or get_pixel_color, which also retrieve sprite data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_palette or get_pixel_color. The description lacks context for selection among multiple info-retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Offset cel positions by a delta across a frame range.
Args: filename: Name of the Aseprite file to modify layer_name: Layer name to target start_frame: Starting frame index (1-based) end_frame: Ending frame index (1-based, inclusive) dx: X delta in pixels dy: Y delta in pixels
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| start_frame | Yes | ||
| end_frame | Yes | ||
| dx | Yes | ||
| dy | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It describes the action but does not disclose behavioral traits such as in-place modification, destruttiva nature, prerequisites (cel existence), return values, or error conditions. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-sentence action statement followed by a parameter list. It is front-loaded with the purpose and efficient in its layout. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 6 required parameters, no annotations, and no output schema, the description is adequate but incomplete. It covers the core action and parameters but lacks behavioral details, error handling, and prerequisites. It is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining all six parameters: filename, layer_name, start_frame (1-based), end_frame (inclusive), dx, dy. This adds meaning beyond the schema's titles. However, it lacks constraints like valid ranges or that dx/dy can be negative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool offsets cel positions by a delta across a frame range. The verb 'offset' is specific, and the resource 'cel positions' is explicit. It distinguishes itself from siblings like set_cel_position (absolute) and tween_cel_positions (animated).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists parameters but does not explicitly state when to use this tool versus alternatives like set_cel_position or tween_cel_positions. Usage is implied for shifting cels by a constant delta, but no guidance on exclusions or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Oscillate cel positions across a frame range using a sine wave.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| start_frame | Yes | ||
| end_frame | Yes | ||
| amplitude_x | No | ||
| amplitude_y | No | ||
| cycles | No | ||
| phase_deg | No | ||
| create_missing_cels | No | ||
| source_frame_index | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states 'oscillate using a sine wave' but omits crucial details: whether positions are modified in place, how missing cels are handled (despite a schema parameter), or the effect on existing keyframes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise but lacks structure. It does not front-load the most important details (e.g., required parameters, behavioral constraints). Could be more informative without increasing length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and many sibling tools, the description is vastly incomplete. It fails to explain complex interactions (e.g., how source_frame_index works, what create_missing_cels does) and leaves critical usage ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no parameter details. Critical parameters like cycles, phase_deg, amplitude_x/y, source_frame_index, and create_missing_cels are completely unexplained, making correct invocation nearly impossible without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (oscillate) and resource (cel positions) with a specific mathematical method (sine wave). This differentiates it from siblings like tween_cel_positions or offset_cel_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., tween_cel_positions_eased, offset_cel_positions). No prerequisites or exclusions mentioned, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Copy cels from a source frame to a range of frames for specific layers.
Args: filename: Name of the Aseprite file to modify layer_names: List of layer names to copy source_frame: Frame index to copy from (1-based) start_frame: Start frame index (1-based) end_frame: End frame index (1-based, inclusive) replace: Whether to overwrite existing cels (default: True)
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_names | Yes | ||
| source_frame | Yes | ||
| start_frame | Yes | ||
| end_frame | Yes | ||
| replace | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose critical behaviors such as whether source cels are deleted, behavior when replace=False (merge?), or permission requirements. Only notes 'replace: Whether to overwrite existing cels' but doesn't explain the alternative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-line summary and parameter list are concise with no redundant text. The parameter list is slightly lengthy but organized. No wasted sentences; earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description covers basic usage but omits behavioral context (e.g., what if source_frame equals a target frame? Does it error on nonexistent layers?). Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It provides clear 1-based indexing for frames, lists layer_names as a list, and explains the replace parameter. However, it lacks details like allowed values for layer_names or what happens when replace=False.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Copy cels from a source frame to a range of frames for specific layers,' which is a specific verb (copy) and resource (cels across frames for layers). It clearly distinguishes from sibling tools like copy_cel (single cel) and propagate_frame_to_range (copies frames not cels).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives guidance. The description only lists parameters, failing to differentiate from tools like copy_cel or propagate_frame_to_range. No context on when to use replace=True/False.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Copy all layers from a source frame to a range of frames.
Args: filename: Name of the Aseprite file to modify source_frame: Frame index to copy from (1-based) start_frame: Start frame index (1-based) end_frame: End frame index (1-based, inclusive) overwrite: Whether to overwrite existing cels (default: True)
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| source_frame | Yes | ||
| start_frame | Yes | ||
| end_frame | Yes | ||
| overwrite | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It reveals the overwrite behavior via the parameter but does not explicitly state that the tool modifies the file in-place or mention other side effects. The lack of annotations limits transparency, but the description gives basic 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single-line summary followed by a clean docstring listing each parameter. No redundant information; every sentence is functional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should explain return values or effects, but it does not. The description covers the basic action and parameters, but lacks detail on edge cases like when overwrite=False and cels exist. Given 5 parameters and no output schema, it is minimally adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate. The docstring provides concise explanations for all five parameters, including 1-based indexing for frames and the default for overwrite. This adds meaning beyond the schema's property titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Copy all layers) and the resource (from a source frame to a range of frames). It precisely distinguishes the tool from siblings like copy_frame and propagate_cels by specifying the destination as a range of frames.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, exceptions, or context that would help an AI agent choose this tool over existing siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remap colors in a layer across a frame range using explicit mappings.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| start_frame | Yes | ||
| end_frame | Yes | ||
| mappings | Yes | ||
| create_missing_cels | No | ||
| source_frame_index | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It does not disclose whether the operation is destructive, reversible, or requires specific permissions. 'Remap' implies modification, but details like whether it overwrites existing cels or creates new ones are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but structurally insufficient. It is front-loaded with the core action but omits critical details. Conciseness is undercut by the need for more content; an effective description would be slightly longer but more complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 5 required, no output schema, no annotations), the description is severely inadequate. It fails to explain the mappings format, behavior across frames, effect on existing cels, or return value. The agent cannot fully understand or invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description only mentions 'explicit mappings' without specifying the format of the mappings parameter (array of objects with additionalProperties). It does not explain filename, layer_name, start/end_frame, create_missing_cels, or source_frame_index.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (remap colors), the target (a layer across a frame range), and the method (using explicit mappings). However, it does not distinguish this tool from siblings like replace_color or set_palette, so it loses a point for lack of differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as replace_color or extract_palette. There is no mention of prerequisites or typical use cases. The description does not help the agent decide between this and similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scale the canvas and all its content to new dimensions.
Args: filename: Aseprite file to modify width: New canvas width in pixels height: New canvas height in pixels
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| width | Yes | ||
| height | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks details on scaling behavior (e.g., interpolation, aspect ratio, handling of pixels outside new bounds), which is critical for understanding side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one line for purpose, then a bulleted parameter list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for basic invocation, but missing return value info and edge-case behavior (e.g., scaling when new dimensions are smaller/larger, scaling algorithm). No output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds units ('in pixels') and clarifies each parameter beyond the schema, which had no descriptions. With 0% schema coverage, this compensates well but doesn't explain constraints like min/max.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Scale' and resource 'canvas and all its content to new dimensions', distinguishing it from sibling 'crop_canvas' which crops without scaling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for resizing canvas with content scaling, but no explicit when-to-use or when-not-to-use, and no alternatives like 'crop_canvas' mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rotate a layer's image 90, 180, or 270 degrees clockwise.
Args: filename: Aseprite file to modify layer_name: Layer name to rotate frame_index: Frame index starting at 1 angle: Rotation angle: 90, 180, or 270 (clockwise)
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| frame_index | Yes | ||
| angle | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond the basic action. It does not mention whether the operation is destructive, reversible, or requires specific permissions. The description is minimal and leaves the agent uninformed about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence followed by a clear bullet list of parameters. Every sentence adds value, and the structure is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple transformation tool, the description covers the necessary input parameters adequately. However, without an output schema or behavioral details, the agent may not know what to expect as a result. Slightly incomplete but acceptable given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides brief but useful descriptions for each parameter: 'frame_index starting at 1', 'angle: 90, 180, or 270 (clockwise)'. This adds constraints and clarifies the format, adding value beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Rotate a layer's image 90, 180, or 270 degrees clockwise.' It specifies a specific verb and resource, and distinguishes itself from siblings like 'flip_layer' which performs a different transformation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or scenarios where rotation is not appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a cel's position in a specific layer and frame.
Args: filename: Name of the Aseprite file to modify layer_name: Layer name to target frame_index: Frame index starting at 1 x: X position in pixels y: Y position in pixels create_if_missing: Create the cel if it does not exist source_frame_index: Optional frame to copy the cel image from
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| frame_index | Yes | ||
| x | Yes | ||
| y | Yes | ||
| create_if_missing | No | ||
| source_frame_index | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details beyond the basic action. It does not disclose that the tool can create cels if create_if_missing is true, or that it can copy from another frame via source_frame_index. With no annotations, the description should explain these side effects and requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear front-loaded sentence. The Args section lists parameters but is somewhat verbose; however, it is structured and readable. It could be more concise by integrating parameter details into prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters (5 required) and no output schema, the description should explain return values, prerequisites (e.g., file must exist), and overall effect. It only states 'set a cel's position', leaving many contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It provides minimal explanations (e.g., 'in pixels', 'starting at 1'), which is baseline but not comprehensive. Key parameters like create_if_missing and source_frame_index are only listed without elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Set a cel's position in a specific layer and frame,' which clearly specifies the verb (Set), resource (cel's position), and scope. This distinguishes it from sibling tools like create_cel, copy_cel, and offset_cel_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not mention when to use set_cel_position vs tween_cel_positions or offset_cel_positions. There are no when-to-use or when-not-to-use directives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the active frame by index (1-based).
Args: filename: Name of the Aseprite file to modify frame_index: Frame index starting at 1
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| frame_index | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for disclosing behavior. It fails to mention side effects (e.g., changing current view), constraints on frame_index range, error handling for invalid inputs, or return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one-purpose sentence followed by clear parameter definitions. No unnecessary words or information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool, but missing behavioral details like error behavior, state change permanence, and output. With no output schema, description should clarify what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds basic meaning per parameter: filename as file to modify and frame_index as index starting at 1. Lacks constraints like valid range or file state prerequisites.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool sets the active frame by a 1-based index, using clear verb and resource. It distinguishes from frame-manipulation siblings like add_frame, delete_frame, and copy_frame.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as add_frame or set_frame_duration. The description provides no context about appropriate scenario or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the duration of a frame in milliseconds.
Args: filename: Name of the Aseprite file to modify frame_index: Frame index starting at 1 duration_ms: Duration in milliseconds
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| frame_index | Yes | ||
| duration_ms | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Indicates it modifies an Aseprite file (mutation), but without annotations the description should state if changes are reversible, require saving, or have side effects. Adequate for a straightforward operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Brief and structured as an args list. No unnecessary words. Could be slightly more informative but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, 0% schema coverage. Description provides basic info but lacks constraints (e.g., valid duration range, error handling). Sufficient for simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It does: filename, frame_index (starting at 1), duration_ms (milliseconds). Adds meaning beyond type and required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool sets the duration of a frame in milliseconds, with specific verb and resource. Distinguishes from siblings like 'set_frame_duration_all' which targets all frames.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'set_frame_duration_all' or 'set_frame'). Does not mention prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the duration of all frames in milliseconds.
Args: filename: Name of the Aseprite file to modify duration_ms: Duration in milliseconds
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| duration_ms | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states the action without disclosing side effects, permissions, or reversibility. For a mutation tool, this 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus argument bullets with no wasted words. Perfectly sized for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool with two required parameters and no output schema. Could mention error conditions or that it modifies the file, but the core action is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning beyond the schema by specifying 'name of the Aseprite file' for filename and 'duration in milliseconds' for duration_ms, compensating for 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the duration for all frames in milliseconds, distinguishing it from the sibling tool 'set_frame_duration' which targets a specific frame.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'set_frame_duration'. Does not mention context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the active layer by name.
Args: filename: Name of the Aseprite file to modify layer_name: Layer name to activate create_if_missing: Create layer if it does not exist
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| create_if_missing | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the primary behavior (setting active layer) and the optional creation behavior, but lacks details on error handling, side effects, or installation context. With no annotations, more context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus three parameter lines with no fluff. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with no output schema, the description covers the core functionality and parameters. Missing details like return value or error behavior, but adequate for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It provides clear, concise explanations for all three parameters, effectively compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the active layer by name, using a specific verb and resource. It distinguishes from sibling tools like add_layer and rename_layer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention that add_layer creates a new layer or rename_layer renames, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set layer opacity by name (0-255).
Args: filename: Name of the Aseprite file to modify layer_name: Layer name to target opacity: Opacity value 0-255
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| opacity | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the opacity range but does not disclose side effects (e.g., modification in-place, file saving, error handling for missing layers), leaving behavioral traits largely hidden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence plus args list, front-loaded with purpose. No wasted words, efficient for the limited information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too sparse. Missing return value info, error cases, and whether the tool persists changes. Inadequate for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so compensation needed. The description adds minimal meaning: clarifies opacity range (0-255) which is absent from schema, but filename and layer_name descriptions merely echo the field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action: 'Set layer opacity by name (0-255)'. The verb 'set' plus resource 'layer opacity' with scope 'by name' distinguishes it from sibling tools like set_cel_opacity and set_layer_blend_mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like set_cel_opacity. Does not mention when to use or exclude, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set layer visibility by name.
Args: filename: Name of the Aseprite file to modify layer_name: Layer name to target visible: Whether the layer should be visible
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| visible | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It fails to disclose what happens if the layer does not exist, whether changes are reversible, or any side effects. The description is minimal and does not add context about behavior beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured as a docstring with an Args section. It is front-loaded with the key purpose. However, it could be equally concise while including more useful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values or error conditions, nor what happens when the layer is not found. The visible parameter default is true, but this is not explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no descriptions in the JSON schema). The description gives one-line explanations for each parameter (e.g., 'Name of the Aseprite file to modify'), which adds some meaning beyond the titles, but it does not compensate for the lack of schema descriptions. The explanations are minimal and do not clarify details like the format of filename or expected layer name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set layer visibility by name', which is a specific verb (set) and resource (layer visibility) with scope (by name). It distinguishes itself from sibling tools like set_layer_blend_mode and set_layer_opacity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives. It does not mention prerequisites, such as whether the layer must exist, or when not to use it. The sibling list includes many layer-related tools, but no differentiation is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure onion skin settings for Aseprite.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| enabled | No | ||
| before | No | ||
| after | No | ||
| opacity | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden but only says 'Configure onion skin settings,' which omits behavioral details like whether it modifies live settings or requires a sprite to be open. No side effects or prerequisites are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it underspecifies the tool's function given the number of parameters. It could be restructured to include key parameter details without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, no annotations, and 0% schema coverage, the description is highly incomplete. It does not explain the return value, effect on the sprite, or any related concepts, making it insufficient for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond the parameter names from the schema. It does not explain what 'after', 'before', 'opacity' etc. do, leaving the agent without semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures onion skin settings for Aseprite, using a specific verb and resource. It is distinct from sibling tools that deal with other settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'render_onion_skin' or other configuration tools. The context of onion skin settings is not explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the active sprite palette using a list of hex colors.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| colors | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description gives no behavioral details beyond the fact that it sets the palette. It does not disclose side effects (e.g., replacing entire palette), validation, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise, but it sacrifices necessary detail. It could be improved by adding parameter explanations without significant length increase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two required parameters and no output schema or annotations, the description is too minimal. It fails to provide context for the 'filename' parameter, any constraints, or expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'colors' parameter (list of hex colors) but does not explain the 'filename' parameter at all. With 0% schema description coverage and only one of two parameters clarified, the description is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set), the target (active sprite palette), and the method (using a list of hex colors). It distinguishes from siblings like 'get_palette' and 'apply_palette_preset' by specifying the input format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites or context provided. The agent must infer usage from the bare description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update an animation tag on the sprite.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| name | Yes | ||
| from_frame | Yes | ||
| to_frame | Yes | ||
| direction | No | forward |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden but fails to disclose side effects such as whether an existing tag with the same name is updated or replaced, or any constraints on tag creation. The term 'update' implies idempotency, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it very concise. However, it lacks sufficient detail to be effective, sacrificing substance for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, and many sibling tools), the description is incomplete. It does not explain the effect of the direction parameter, what constitutes a valid tag, or the consequence of creating vs updating.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any of the five parameters (filename, name, from_frame, to_frame, direction). With 0% schema description coverage, the description adds no meaning beyond the parameter names in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates or updates an animation tag on the sprite, which is a specific verb+resource. However, it does not differentiate from sibling tools, and the concept of 'tag' could be elaborated for clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like set_frame or add_frame. There is no context on prerequisites, conditions, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a simple HTTP server to preview exported sprites.
Args: directory: Directory to serve port: Port to bind (default 8000)
| Name | Required | Description | Default |
|---|---|---|---|
| directory | Yes | ||
| port | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions it's a 'simple HTTP server' but does not disclose whether it is blocking, returns a URL, allows multiple instances, or how to stop. Missing critical behavioral traits for a network service.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences plus an arg list. It front-loads the purpose and wastes no words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 params, no output schema), the description still lacks key details: how to access the server (URL), that it runs until stopped, concurrency limits, and error handling. This is a network tool and needs more behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains both parameters: 'directory: Directory to serve' and 'port: Port to bind (default 8000)'. This adds meaning beyond the type and default, clarifying purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a simple HTTP server to preview exported sprites. It is specific about the action and resource, but does not explicitly differentiate it from sibling tools like `stop_preview_server` or other server-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'to preview exported sprites' but provides no guidance on when not to use, prerequisites, lifecycle (e.g., must call stop_preview_server), or alternatives. The sibling `stop_preview_server` exists but is not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the preview HTTP server for a given port.
Args: port: Port to stop (default 8000)
| Name | Required | Description | Default |
|---|---|---|---|
| port | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action without discussing side effects, error conditions, or prerequisites like the server running.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one sentence and an argument list. Every part adds value, and the main action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool without output schema, the description is nearly complete. It could be improved by noting that the server must be running on that port, but overall it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'port' parameter and its default value, adding meaning beyond the schema's type and default. Schema coverage is 0%, so this compensation is valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stops a preview HTTP server for a specific port. It distinguishes itself from the sibling 'start_preview_server' tool by providing the opposite action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It implicitly relates to starting a server but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tween cel opacity with easing across a frame range.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| start_frame | Yes | ||
| end_frame | Yes | ||
| start_opacity | Yes | ||
| end_opacity | Yes | ||
| easing | No | smoothstep | |
| create_missing_cels | No | ||
| source_frame_index | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core behavior (tween opacity with easing across frames) but omits important details: what opacity range is assumed, what happens if cels are missing (despite a create_missing_cels parameter), what easing functions are available, and the role of source_frame_index. This lack of disclosure makes it harder for an agent to anticipate outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words. It is appropriately short for a purpose statement. However, it could include a bit more context without becoming verbose, but it earns a 4 for being efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters (6 required), no annotations, no output schema, and no parameter descriptions, the description is severely incomplete. It does not address prerequisites (e.g., file must exist), return behavior (likely void or success indicator), or side effects (modifies cel opacity on multiple frames). The description alone does not enable correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no parameter-level meaning. It does not explain that filename, layer_name, start_frame, end_frame, start_opacity, end_opacity are required, nor what valid values for opacity are (e.g., 0-255 vs 0-100). The optional easing, source_frame_index, and create_missing_cels are not mentioned at all. The description fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'tween' and resource 'cel opacity', and explicitly mentions 'with easing' and 'across a frame range'. This clearly distinguishes it from sibling tools like tween_cel_positions_eased and tween_cel_scale_eased, and makes the animation intent unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for animating opacity across frames, but provides no explicit guidance on when to use this tool versus alternatives like set_cel_opacity (immediate) or other tween tools. No when-not examples or conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tween cel positions linearly across a frame range.
Args: filename: Name of the Aseprite file to modify layer_name: Layer name to target start_frame: Starting frame index (1-based) end_frame: Ending frame index (1-based, inclusive) start_x: Starting X position in pixels start_y: Starting Y position in pixels end_x: Ending X position in pixels end_y: Ending Y position in pixels create_missing_cels: Create missing cels during tween source_frame_index: Optional frame to copy the cel image from
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| start_frame | Yes | ||
| end_frame | Yes | ||
| start_x | Yes | ||
| start_y | Yes | ||
| end_x | Yes | ||
| end_y | Yes | ||
| create_missing_cels | No | ||
| source_frame_index | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It mentions linear interpolation but does not disclose side effects (e.g., file modification, overwriting behavior, or creation of missing cels beyond the create_missing_cels parameter). Lacks detail on what happens to existing cels.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence followed by a parameter list. No redundant information; each element serves a clear purpose. Efficiently communicates the tool's action and parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no output schema, and no annotations, the description covers the main action and all parameters. However, it does not specify return values, error conditions, or when the operation might fail (e.g., missing layer). Adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description adds minimal clarification for each parameter (e.g., 'start_x: Starting X position in pixels'). However, these are largely self-explanatory from parameter names. The descriptions are functional but not enriched beyond basic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Tween cel positions linearly across a frame range', which is a specific verb-resource pair. It distinguishes from siblings like offset_cel_positions (relative offset) and tween_cel_positions_eased (eased interpolation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Sibling tools like set_cel_position, offset_cel_positions, and tween_cel_positions_eased are not mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tween cel positions with easing across a frame range.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| start_frame | Yes | ||
| end_frame | Yes | ||
| start_x | Yes | ||
| start_y | Yes | ||
| end_x | Yes | ||
| end_y | Yes | ||
| easing | No | smoothstep | |
| create_missing_cels | No | ||
| source_frame_index | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only states basic purpose. It omits details like what happens to existing cels, coordinate system, or prerequisite state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no wasted words. However, it could include more helpful information without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters and no output schema, the description is far from complete. Key parameters like 'source_frame_index' and 'create_missing_cels' are unexplained, making the tool hard to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no parameter details. While parameter names like start_x are somewhat self-explanatory, values like 'easing' type and 'source_frame_index' lack clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tween cel positions with easing across a frame range' clearly states it tweens cel positions with easing, distinguishing it from the sibling 'tween_cel_positions' which likely lacks easing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidelines are provided. The description implies it should be used for animating cel positions with easing, but does not discuss alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tween cel scale with easing across a frame range.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| layer_name | Yes | ||
| start_frame | Yes | ||
| end_frame | Yes | ||
| start_scale | Yes | ||
| end_scale | Yes | ||
| easing | No | smoothstep | |
| anchor | No | center | |
| replace | No | ||
| create_missing_cels | No | ||
| source_frame_index | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It fails to mention key behaviors such as whether existing cels are replaced (parameter 'replace'), whether missing cels are created ('create_missing_cels'), or how the source frame index affects the tween. The minimalist description leaves the agent uninformed about side effects or assumptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, but it sacrifices completeness. It does not provide enough information to earn its place; it essentially restates the tool name with minor elaboration. For a tool with 11 parameters, this is under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, 6 required, many sibling tween tools), the description is severely incomplete. It lacks an overview of tween behavior, relationship to other tween tools, and explanation of keyframe concepts. The absence of output schema further increases the need for descriptive completeness, which is unmet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning beyond the schema. It does not explain any of the 11 parameters, including critical ones like start_scale, end_scale, easing, or anchor. The agent must rely entirely on parameter names, which may be insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool tweens cel scale with easing across a frame range, specifying the verb 'tween', resource 'cel scale', and context 'with easing across a frame range'. It is distinguishable from siblings like tween_cel_opacity_eased, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as tween_cel_opacity_eased or tween_cel_positions_eased. There is no mention of prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate presence of layers and cels across a frame range.
Returns JSON with missing layers and missing cels.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| required_layers | Yes | ||
| start_frame | No | ||
| end_frame | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states it 'validates' and 'returns JSON', but does not indicate if it is read-only (likely safe), performance implications, or whether it modifies state. No mention of error cases or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) with no fluff, but it is under-specified. It earns its place by stating purpose and return value, but lacks important details, making it less efficient for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 0% parameter descriptions, the description is incomplete. It mentions the return format (JSON with missing layers and missing cels) but not its structure. It fails to cover the parameters or provide enough context for a tool with 4 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does not explain any parameter (filename, required_layers, start_frame, end_frame). The user cannot infer parameter semantics from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: validate presence of layers and cels across a frame range and return missing items. The verb 'validate' and the resource 'layers and cels' are specific. It partially distinguishes from sibling tools like 'audit_animation' but lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'ensure_layers_present', 'audit_animation'). No prerequisites, context, or when-not-to-use instructions are provided. The usage scenario is implied 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0add_frameadd_framesadd_layeranimation_sanitizeanimation_workflow_guideapply_gradient_rectaudit_animationclear_celcopy_celcopy_framecopy_layers_between_spritescopy_spritecreate_canvascreate_celcrop_canvasdraw_circledraw_circle_atdraw_linedraw_line_atdraw_pathdraw_pixelsdraw_pixels_atdraw_polygondraw_rectangledraw_rectangle_atduplicate_frame_rangeensure_layers_presentexport_spritefill_areafill_area_atflip_layerget_paletteget_pixel_colorget_pixels_rectget_sprite_infooffset_cel_positionsoscillate_cel_positionspropagate_celspropagate_frame_to_rangeremap_colors_in_cel_rangeresize_canvasrotate_layerset_cel_positionset_frameset_frame_durationset_frame_duration_allset_layerset_layer_opacityset_layer_visibilityset_onion_skinset_paletteset_tagstart_preview_serverstop_preview_servertween_cel_opacity_easedtween_cel_positionstween_cel_positions_easedtween_cel_scale_easedvalidate_sceneScored across 59 tools
Many tools have overlapping purposes, e.g., draw_circle vs draw_circle_at, propogate_cels vs propogate_frame_to_range, and multiple animation audit/sanitize tools. The '_at' and 'eased' variants add confusion without clear distinct use cases.
Most tools follow verb_noun pattern, but there are exceptions like 'animation_workflow_guide' (noun_noun) and mixing of 'at' and 'eased' suffixes. Overall pattern is readable but not fully consistent.
59 tools is excessive for an MCP server; it suggests insufficient scoping and many niche operations. The count makes it hard for agents to navigate and select appropriately.
Obvious gaps exist: no delete layer or delete frame tools, no layer ordering or merging, and limited color manipulation beyond pixel drawing. The surface misses basic CRUD operations for layers and frames.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create AI animations and export transparent sprite sheets, alpha video, frames, and game assets.
Generate game assets with AI for 2D games, including sprites, tilesets, and animations.
AI game assets for agents: consistent sprites, 2D animations, tiles, maps, music and engine exports.
Give your AI agents the tools to build, manage, and run automation workflows.
