A
licenseB
qualityC
maintenanceAn MCP server that generates pixel-art PNGs from text prompts, using a free image backend, and saves them directly to your project directory.
2
MIT
pixelart-mcp
by light-vp
The pixelart-mcp server is a local toolkit for creating, editing, animating, and exporting pixel art on PNG files, designed to be AI‑friendly by encoding artistic techniques.\n\n- Canvas Management: Create canvases up to 1024×1024 pixels (transparent or colored), duplicate, resize (grow/crop with 9‑way anchor), scale with nearest‑neighbor sampling, shift (with optional wrapping), flip/rotate, copy/composite regions within or between canvases, and view with optional grid overlays. Get canvas info like dimensions and palette.\n- Drawing & Editing: Draw individual pixels in batch (up to 4096 per call), shapes (lines, rectangles, ellipses, polygons, Bézier curves), flood fill, replace colors, draw from text grids using a color legend, and auto‑outline sprites.\n- Craft & Shading: Build color ramps from a base color, auto‑shade regions into 3D forms (sphere, cylinder, bevel), draw dithered gradients (linear/radial with Bayer or checker patterns), mirror canvases for symmetry, apply curated palettes (sweetie16, pico8, dawnbringer16, slso8, nes), snap colors to a palette, and apply sub‑pixel anti‑aliasing.\n- Animation: Onion‑skin view (up to 3 previous frames), filmstrip view, export animated GIFs with per‑frame durations and ping‑pong mode, export/pack spritesheets, and slice spritesheets back into frames.\n- Export & Preview: Export upscaled PNGs with crisp nearest‑neighbor scaling. Use pixel_batch to combine multiple operations in one call, with preview or preview_diff options to save tokens by only showing changed regions.\n- AI‑Friendly Design: Tools bundle pixel art craftsmanship (shading, anti‑aliasing, palette management) so models can produce high‑quality sprites without being artists.
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., "@pixelart-mcpcreate a 16x16 canvas with a transparent background"
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.
pixelart-mcp
A local MCP server for creating pixel art — no paid software, no external apps. Canvases are ordinary PNG files on disk, edited with Pillow. One canvas pixel is one image pixel; exports upscale with nearest-neighbor so pixels stay crisp.
The server encodes pixel-art craft in its tools, so models — including small
ones — don't have to be artists to produce good sprites: hue-shifted shading
ramps, one-call auto-shading (sphere / cylinder / bevel), dithered gradients,
symmetry mirroring, text-grid drawing and reading, curated palettes, and an
on-demand technique guide (pixel_guide) with a staged workflow
(size → palette → silhouette → flats → shading → details → finish).
Sprites animate the same way: rig one drawing into named parts and the server generates the whole cycle from it, so an 8-frame walk costs one drawing rather than eight.
Tools
Craft (color, shading, knowledge)
Tool | Purpose |
| Technique playbook: workflow, sizing, color, shading, dithering, materials, characters, scenes, animation |
| One base color → professional dark→light ramp (hue-shifted shadows/highlights) |
| Flat regions → shaded 3D form in one call: |
| Linear/radial gradients with ordered dithering ( |
| Draw from a text grid + character→color legend — the reliable way to place shapes |
| Read the canvas back as a labeled character grid with exact coordinates |
| Draw half a symmetric subject, mirror it across an axis |
| Curated, pre-harmonized palettes (sweetie16, pico8, dawnbringer16, slso8, nes) |
| Angular silhouettes from a handful of vertices (hulls, roofs, blades, mountains) |
| Quadratic/cubic Bézier strokes for organic contours (necks, tails, hair, flames) |
| Sub-pixel anti-aliasing: softens diagonal staircases; uses partial alpha on transparent backgrounds |
| Run many drawing operations on one canvas in a single call — the default way to draw |
Drawing
Tool | Purpose |
| New PNG canvas (up to 1024x1024), any background or transparent |
| Batch-set individual pixels, per-point colors supported |
| Shape primitives, filled or outlined |
| Paint-bucket fill of a contiguous region |
| Exact-match palette swap across the canvas |
| Snap all colors to the nearest entry of a given palette |
| Auto 1px outline: |
Canvas surgery
Tool | Purpose |
| Copy/composite a rect within or between canvases ( |
| Shift art by (dx, dy), optionally wrapping at edges |
| Grow/crop canvas bounds with a 9-way anchor, art unscaled |
| Nearest-neighbor rescale (squash-and-stretch friendly) |
| Flip / rotate the whole canvas |
Animation
Tool | Purpose |
| Name the movable parts of a drawn sprite, with a labelled preview that flags art no part covers |
| Generate a whole animation loop from one rigged sprite |
| Built-in cycles: |
| Start the next frame from the current one |
| Current frame over faded ghosts of up to 3 earlier frames |
| Filmstrip contact sheet of many frames in one image |
| Looping GIF with per-frame durations and ping-pong mode |
| Pack frames into a grid PNG for game engines |
| Split an existing sheet back into frame canvases |
Rigging: one drawing, N frames
Nobody draws 240 frames. Draw the character once, name its parts, and let the server composite the cycle:
pixel_define_rig → pixel_render_motion motion='walk' → pixel_export_gifEvery frame is stamped from the source pixels at new offsets, and offsets round to whole pixels — so nothing is resampled, nothing flickers, and re-rendering the same rig is byte-identical. Consistency is arithmetic, not luck.
Draw the limbs in a parts bin beside the sprite rather than on the body. A
part is a rectangle of source pixels, so limbs drawn on top of each other can
never be boxed apart — but a true side view needs them to overlap once placed.
at_x/at_y place a binned part on the body; frame_width/frame_height
keep the bin out of the rendered frames. See
benchmarks/examples/demo_walk.py for a
complete 8-frame walk from a single 48×48 sheet, and
demo_dusk.py for a full 128×96 scene —
parallax, a walking figure, a guttering lantern, flapping birds, a tumbling
leaf and twinkling stars, all 24 frames of it composited from one 224×200
sheet, driving every motion channel.
Loops close seamlessly under two rules: layers that tile scroll exactly one tile period per loop, and sprites that don't tile start and end off-frame, so the wrap lands where nobody can see it.
No arbitrary rotation. Pixel art does not survive being rotated by
anything but a multiple of 90°, so the orientation channels are flip and
rot only. For an in-between limb angle, draw that angle as its own part and
switch to it with the use channel — which is how real sprite work has always
handled it. Motion channels: dx, dy, squash (interpolated), flip,
rot, visible, use (held). Read pixel_guide topic='animation' first.
Inspection & export
Tool | Purpose |
| Render the canvas as an image; |
| Dimensions + palette report without rendering |
| Nearest-neighbor upscaled PNG export |
Mutating tools accept preview: true to return a rendered image of the result
in the same call, and preview_diff: true to return only the region that
changed (roughly 90% fewer image tokens while iterating on a detail; falls back
to the full canvas when the change is large). Colors are hex (#1a1c2c,
#1a1c2cff), CSS names (crimson), or transparent (which erases).
Related MCP server: pixscii
Design principle
Describe shapes, don't enumerate pixels. Every tool exists so a model can
express an artistic intent in one call rather than hundreds of coordinates: a
mountain is 5 polygon vertices, a dragon's neck is one Bézier, a sky is one
dithered gradient, a shaded sphere is one pixel_shade_region call. The staged
workflow in pixel_guide (silhouette → flats → shading → details → finish)
mirrors how pixel artists actually construct a piece, and pixel_apply_spaa is
the hand-finishing pass at the end.
Token cost
A finished piece is 20–30 operations. The dominant cost is not the tool schemas (~18k tokens, sent once and cached by the client) but the round trips — every separate call re-sends the whole conversation. So:
pixel_batchis the default way to draw. Send a whole stage as one call. Operations run in order, share the batch'spath, and produce output byte-identical to running them individually.preview_diff: truereturns only the region a call changed, rendered small — roughly 90% fewer image tokens while iterating on a detail.High-level tools over pixel lists. One
pixel_draw_polygoncan place thousands of pixels that would otherwise be enumerated by hand.pixel_canvas_infotakestop_nto trim its palette report.
Client-side knobs matter too and are worth setting: prompt caching (tool schemas are a stable prefix, so they cache well) and per-session tool allow-listing. Deliberately not done here: compressing the tool descriptions. They carry the craft guidance — light direction, material recipes, when to dither — that lets smaller models draw well, so shrinking them trades quality for tokens the client is already caching.
Benchmarks
benchmarks/BENCHMARKS.md defines 20 standard
subjects (detailed apple, glass bottle with water, medieval knight, Spider-Man,
Iron Man in sunlight, campfire, dragon, ice cave, ...) with per-subject
must-haves and a 7-dimension rubric — run them across models or server versions
to measure whether a tooling change actually improves the art.
benchmarks/examples/ holds reference pieces drawn with the craft toolset, and
benchmarks/runs/ holds completed runs with the script for every piece.
Setup
Requires uv. Register with Claude Code:
claude mcp add pixelart -s user -- uv --directory /path/to/pixelart-mcp run -m pixelart_mcpOr in any MCP client config:
{
"mcpServers": {
"pixelart": {
"command": "uv",
"args": ["--directory", "/path/to/pixelart-mcp", "run", "-m", "pixelart_mcp"]
}
}
}Available Tools
23 toolspixel_apply_paletteADestructiveIdempotent
Snap every opaque pixel to the nearest color in a given palette — enforce a consistent game palette across sprites or clean up stray colors.
Nearest match is by RGB distance; each pixel's alpha is preserved and fully transparent pixels are untouched. Returns JSON {"canvas", "palette_size", "pixels_changed"}; plus a rendered image when preview=true. On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses RGB distance matching, alpha preservation, transparent pixels untouched, and return format. Annotations already provide idempotent and destructive hints; description adds useful details about pixel handling and failure response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loads purpose, then details behavior and return value. Efficient and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains return format (JSON with fields and error case). Covers purpose, behavior, parameters, and return value comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema provides descriptions for all parameters; description adds value by mentioning preview returns a rendered image. The description does not repeat schema details but complements them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Cleary states the tool snaps opaque pixels to nearest color in a palette, with specific verb 'snap' and resource 'every opaque pixel'. Distinguishes from siblings like pixel_replace_color and pixel_flood_fill by describing a unique use case: enforcing a consistent game palette.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly indicates when to use (enforce consistent palette, clean up stray colors) without explicit exclusions or alternative tool names. Provides clear context of usage from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pixel_canvas_infoARead-onlyIdempotent
Report a canvas's dimensions and color palette without rendering it.
Returns JSON: {"canvas", "width", "height", "unique_colors", "has_transparency", "top_colors": [{"color", "count"}, ...]} with the up to 16 most-used colors (fully transparent pixels reported as 'transparent'). On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds value by specifying the exact JSON structure returned, the limit of top 16 colors, and the error format, going beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences, front-loaded with the core purpose, and every sentence adds value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single simple parameter, clear output schema, and comprehensive annotations, the description covers all needed details: purpose, return format, limits, and error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a description for the 'path' parameter ('Canvas file path ending in .png'), so the description does not need to add param details. The tool description adds no additional parameter guidance beyond the schema's baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Report' and clearly identifies the resource (canvas's dimensions and color palette). It distinguishes the tool from rendering tools like pixel_view_canvas by stating 'without rendering it'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for when you need metadata without rendering, and mentions error handling. However, it does not explicitly state when not to use it or provide alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pixel_copy_regionADestructiveIdempotent
Copy a rectangular region from one canvas onto another (or within the same canvas) — for moving limbs between frames, stamping repeated parts, or compositing a sprite onto a background.
mode='over' (default) respects transparency like layering; mode='replace' overwrites the destination rect including alpha. Destination coordinates may be negative or overhang; the region clips to the destination canvas. Returns JSON {"source", "canvas", "region", "pasted_at", "mode"}; plus a rendered image of the destination when preview=true. On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
TDQS
A4.2/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond annotations by explaining mode behavior ('over' composites respecting transparency; 'replace' overwrites including alpha), clipping for out-of-bounds coordinates, return JSON structure, preview feature, and error format. Annotations indicate destructive and idempotent, which the description aligns with. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of four sentences that front-load purpose and use cases, then detail mode behavior, clipping, return values, and error handling. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with modes, clipping, preview, and return values, the description covers all critical aspects. It lacks only a minor detail on the format of the rendered image when preview=true. No output schema exists, but the description compensates by detailing the JSON structure. Annotations provide additional safety context (destructive, idempotent).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all parameters (e.g., 'Source region left edge X', 'Region width in pixels', etc.), so schema coverage is high. The description does not add new parameter-specific information beyond what the schema gives. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'copy', the resource 'rectangular region', and scope 'from one canvas onto another (or within the same canvas)'. Use cases like moving limbs, stamping, compositing further clarify purpose and distinguish it from sibling tools like pixel_draw_pixels or pixel_transform_canvas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists specific use cases (moving limbs between frames, stamping repeated parts, compositing) which imply when to use the tool, but it does not explicitly mention when not to use it or compare with alternatives. No direct exclusions or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pixel_create_canvasA
Create a new pixel art canvas saved as a PNG file.
The canvas is true-size (one canvas pixel = one image pixel); keep sprites small (e.g. 16x16, 32x32, 64x64) and upscale later with pixel_export_png. Parent directories are created automatically. Refuses to replace an existing file unless overwrite=true.
Returns: JSON {"canvas", "width", "height", "background"}; plus a rendered image of the canvas when preview=true. On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: true-size canvas, automatic parent directory creation, refusal to replace without overwrite=true, and return format (JSON plus optional preview image). Annotations are sparse, so the description adds valuable transparency beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no redundant sentences. It is well-structured: purpose, size advice, behavioral notes, and return info, all front-loaded for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no output schema, the description covers essential aspects: purpose, size recommendations, automatic directory creation, overwrite behavior, preview option, and return format. It lacks details on error types and background initialization, but overall is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description mentions overwrite and preview parameters explicitly. However, it does not explain path, width, height, or background parameters, relying on the schema's own descriptions. This partial coverage limits the added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new pixel art canvas saved as a PNG file,' which is a specific verb+resource pair. It distinguishes itself from siblings like pixel_draw_pixels and pixel_export_png by focusing on canvas creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on canvas size ('keep sprites small') and suggests using pixel_export_png for upscaling later. It also clarifies that overwriting requires overwrite=true, giving clear context for when to use this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pixel_draw_ellipseADestructiveIdempotent
Draw a filled or outlined ellipse inside a bounding box on a canvas.
(x, y) is the bounding box's top-left corner; equal width and height give a circle. Drawing 'transparent' erases. Returns JSON {"canvas", "ellipse", "color", "filled"}; plus a rendered image when preview=true. On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior. The description adds that drawing 'transparent' erases, describes the return JSON structure, and notes error format. This goes beyond annotations to inform the agent about side effects and output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the main action, and covers key usage details without redundancy. Every sentence adds value, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description adequately explains the return value (JSON fields) and failure case. It covers all important aspects of a simple drawing tool, leaving no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema provides descriptions for all parameters, the tool description adds conceptual context: the bounding box meaning, the relationship between width/height and circles, and the preview toggle. This aids understanding beyond the schema's individual field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool draws 'a filled or outlined ellipse inside a bounding box on a canvas', with specific detail on how equal width/height yields a circle. This distinguishes it from siblings like pixel_draw_rect and pixel_draw_line, which draw different shapes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the bounding box coordinate system, the effect of 'transparent' color, and the preview option. While it doesn't explicitly contrast with siblings, the context is sufficient for an agent to understand when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pixel_draw_lineADestructiveIdempotent
Draw a straight line between two points on a canvas.
Endpoints may lie outside the canvas; the visible segment is drawn. Drawing 'transparent' erases. Returns JSON {"canvas", "line", "color"}; plus a rendered image when preview=true. On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true. The description adds useful behavioral details: endpoints may lie outside canvas, 'transparent' erases, and return value includes a rendered image when preview=true. These go beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, edge case/behavior, and return value. No wasted words, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description explains the return format (JSON with canvas, line, color, plus image on preview) and failure case. It covers the endpoint clipping behavior. Lacks details about modification semantics (e.g., does it update the file?), but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema property descriptions exist (e.g., 'Start X'), but overall schema description coverage is 0%. The description adds meaning: endpoints can be outside, transparent erases, and preview returns image. It does not cover thickness or path explicitly, but provides key context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Draw a straight line between two points on a canvas,' which is a specific verb+resource. It distinguishes from siblings like pixel_draw_rect and pixel_draw_ellipse by focusing on lines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. Usage is implied by the tool's purpose, but no when-not-to-use or alternative comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pixel_draw_pixelsADestructiveIdempotent
Set individual pixels on a canvas in one batch.
Each point may carry its own color; points without one use the batch
default color. Drawing 'transparent' erases pixels. Out-of-bounds points
are skipped and counted, not fatal. Batch as many points per call as
possible — one call per sprite region, not one call per pixel.
Returns: JSON {"canvas", "pixels_drawn", "skipped_out_of_bounds"?}; plus a rendered image when preview=true. On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral details beyond annotations: out-of-bounds handling, transparent color erasing, batch default color, return JSON structure, and preview behavior. It aligns with annotations (destructive, idempotent) and adds context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient: first sentence states purpose, then details. It uses bullet points for return format and examples, no redundant fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, batch behavior, preview, error handling), the description covers key behaviors. It lacks explicit mention of output schema (but none exists) and path format, but schema compensates. Sufficient for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema provides descriptions for each parameter, the tool description adds context: default color behavior, transparent as eraser, out-of-bounds skipped, and preview returns image. It doesn't cover every parameter (e.g., path format) but adds meaningful explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set individual pixels on a canvas in one batch' with a specific verb ('Set') and resource ('pixels on a canvas'). It distinguishes this tool from siblings like pixel_draw_line and pixel_draw_rect by focusing on individual pixel manipulation in batch operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises batching multiple points per call ('one call per sprite region, not one call per pixel'), providing clear usage guidance. It also mentions that out-of-bounds points are skipped, but does not explicitly state when to use alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pixel_draw_rectADestructiveIdempotent
Draw a filled or outlined rectangle on a canvas.
(x, y) is the top-left corner; width/height are in pixels. Drawing 'transparent' erases the region. Returns JSON {"canvas", "rect", "color", "filled"}; plus a rendered image when preview=true. On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: it specifies the return JSON structure, optional preview rendering, and the erasure effect of 'transparent'. It does not contradict the readOnlyHint=false, destructiveHint=true, idempotentHint=true annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (5 lines), front-loaded with the core action, and includes essential details like return format and error handling. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool, the description covers behavioral expectations, coordinate system, special color handling, output format, and error behavior. It is sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies coordinate semantics (top-left, pixels) and the effect of color='transparent'. The schema individually describes each parameter, but the description adds overarching context that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it draws a filled or outlined rectangle on a canvas, specifying behavior for coordinates and size. It distinguishes itself from sibling tools like pixel_draw_line or pixel_draw_ellipse by being rectangle-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains coordinate conventions (top-left), pixel units, and the special 'transparent' erasure behavior. It does not explicitly list when not to use this tool or mention alternatives, but the context is clear enough for typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pixel_duplicate_canvasA
Copy a canvas to a new file — the standard way to start the next animation frame from the current one, then edit only what moves.
Refuses to replace an existing file unless overwrite=true. Returns JSON {"source", "canvas", "width", "height"}. On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide minimal behavioral info (readOnlyHint=false, destructiveHint=false). The description adds value by disclosing that it refuses to overwrite unless overwrite=true, and describes the return JSON structure, which annotations do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences), front-loads the primary purpose, and includes essential behavioral details without redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated), the description adequately explains the tool's behavior and return format. It covers the key aspects for a copy tool, though it could mention that the destination must end in .png (already in schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all parameters (path, dest_path, overwrite). The description does not add further semantic detail beyond what the schema offers, so scores baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Copy' and resource 'canvas', clearly indicating the tool duplicates a canvas. It distinguishes from siblings like pixel_create_canvas (create new) by specifying it copies from an existing canvas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it is 'the standard way to start the next animation frame', giving clear usage context. Also notes the overwrite constraint. However, it does not explicitly list when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pixel_export_gifAIdempotent
Combine same-size canvas PNGs into a looping animated GIF.
Frames play in the order given at duration_ms per frame (or per-frame durations_ms). ping_pong=true plays forward then backward for seamless bounce/idle loops. Transparency is preserved as GIF binary transparency (alpha <= 128 becomes transparent). Source canvases are untouched. Returns JSON {"exported", "frames", "frames_played", "scale", "width", "height"}. On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: 'Transparency is preserved as GIF binary transparency (alpha <= 128 becomes transparent). Source canvases are untouched.' It also describes the return JSON structure and error format, which aligns with idempotentHint=true and destructiveHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the main purpose, followed by brief clarifications on behavior and return values. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers key aspects: input constraints, transparency behavior, return format, and error handling. However, it omits details on the scale parameter and out_path validation, which are present in the schema but not reinforced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage in the context signal, the input schema itself contains detailed descriptions for all properties (e.g., scale, duration_ms). The tool description adds clarity by explaining the role of ping_pong and per-frame durations, complementing the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Combine same-size canvas PNGs into a looping animated GIF.' It specifies the action (combine), input (canvas PNGs), and output (GIF), distinguishing it from sibling tools like pixel_export_png and pixel_export_spritesheet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use parameters like ping_pong for idle/bounce loops and notes that source canvases are untouched. However, it does not explicitly compare against alternatives like pixel_export_spritesheet or state when not to use this tool, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pixel_export_pngAIdempotent
Export a canvas as an upscaled PNG with crisp nearest-neighbor pixels.
The source canvas is untouched; the export is written to out_path (parent directories are created). Use scale 1 for game-ready true-size assets and larger scales for display or sharing. Returns JSON {"source", "exported", "scale", "width", "height"}. On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotentHint=true, destructiveHint=false), the description adds that the source canvas is untouched, parent directories are created, and failure returns 'Error: ...'. This provides concrete behavioral detail without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a short paragraph (3 sentences) with the core action first, then usage guidance, then return format. Every sentence adds value; no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers main purpose, key behavior, parameter usage, and return format/error. It doesn't mention file overwrite behavior, but idempotentHint implies deterministic output. Given the tool's simplicity and rich schema, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes each parameter (path, scale, out_path). The description adds context: upscale is nearest-neighbor, scale 1 is true-size, and out_path is the destination. This supplements schema descriptions without being redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool exports a canvas as an upscaled PNG with nearest-neighbor pixels. It clearly specifies the resource (canvas) and output format (PNG), distinguishing it from siblings like pixel_export_gif and pixel_export_spritesheet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using scale 1 for game-ready true-size assets and larger scales for display or sharing, which guides parameter selection. However, it does not explicitly contrast against sibling export tools or state when to choose this tool over pixel_export_gif.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pixel_export_spritesheetAIdempotent
Pack same-size canvas PNGs into a single spritesheet PNG grid.
Frames are placed left-to-right, top-to-bottom, columns per row (all in
one row if omitted), with no padding — ideal for game engines. Source
canvases are untouched. Returns JSON {"exported", "frames", "columns",
"rows", "frame_width", "frame_height", "width", "height"}. On failure
returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral traits beyond annotations: left-to-right, top-to-bottom layout, no padding, source canvases untouched, and return/error format. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs, front-loaded with purpose, no fluff, every sentence informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Thorough for a simple tool: purpose, layout, behavior, return values, and error format covered, with good annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema by explaining columns placement and return format; schema already describes parameters clearly. Good compensation for 0% coverage signal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it packs same-size canvas PNGs into a spritesheet grid, specifying layout and distinguishing from siblings like pixel_export_png and pixel_slice_spritesheet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context ('ideal for game engines') and implicitly indicates when to use, but lacks explicit 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.
pixel_flood_fillBDestructiveIdempotent
Flood-fill the contiguous region containing (x, y), like a paint bucket.
Fills all connected pixels that exactly match the seed pixel's color. Returns JSON {"canvas", "seed", "color"}; plus a rendered image when preview=true. On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
TDQS
B3.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: specifies connectivity rule ('exactly match seed'), return format ('JSON {canvas, seed, color}, plus rendered image on preview'), and failure format ('Error: ...'). Annotations already indicate destructive and idempotent; description complements without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with a third clarifying return values; no fluff. Could use more structured formatting (e.g., bulleted return fields) but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing critical detail about connectivity (4- vs 8-directional). Does not explain that the canvas file is modified (implied by destructiveHint). Return format is mentioned but key names are uncertain. For a complex operation, more precision is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning description does not formally describe parameters. While it implicitly references seed (x, y) and color in the main text, it omits path and preview. Schema provides parameter descriptions, but description should compensate for low coverage and does so only partially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes a specific verb ('flood-fill') on a specific resource ('contiguous region containing (x, y)'), explicitly distinguishing from sibling tools like pixel_replace_color or pixel_draw_pixels by naming the flood-fill algorithm and seed-based filling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs. alternatives. The phrase 'like a paint bucket' implies a use case but does not mention other tools or provide when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pixel_onion_viewARead-onlyIdempotent
Render the current frame over faded ghosts of up to 3 earlier frames — onion-skinning, the standard way to judge motion between animation frames.
List previous_paths most-recent first; ghosts fade with distance (35%, 20%, 12% opacity). Pass a tint color to show ghosts as silhouettes when frame colors overlap too much. Nothing is written to disk. Returns a text summary plus the rendered image. On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits beyond annotations: 'Nothing is written to disk', opacity percentages (35%, 20%, 12%), ordering of ghosts, tint effect for silhouettes, and return format ('text summary plus the rendered image', 'Error: ...' on failure). Annotations already indicate readOnly and idempotent, but description adds concrete details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three succinct sentences covering purpose, ordering/opacity, tint, safety (no disk writes), and return/failure format. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return value (text summary + image), error format, and core logic for a 4-parameter tool with no output schema. However, does not mention the 'scale' parameter or auto-fit behavior, which would help a user understand display size control. Overall adequate but slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning for 'previous_paths' (most-recent-first ordering, fading percentages) and 'tint' (silhouettes, prevents color overlap). However, 'scale' is not mentioned despite being optional with auto-fit behavior. Given 0% schema description coverage, the description compensates partially but not fully for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Render the current frame over faded ghosts of up to 3 earlier frames — onion-skinning, the standard way to judge motion between animation frames.' The verb 'render' and specific resource 'current frame over faded ghosts' precisely define the action, and the purpose 'judge motion' distinguishes it from siblings like pixel_view_canvas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to judge motion between animation frames ('standard way to judge motion'). It provides context but does not explicitly exclude alternative tools or state when not to use it. Sibling pixel_view_canvas exists but is not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pixel_outline_spriteADestructiveIdempotent
Draw a 1px outline around all opaque art on the canvas — the classic finishing pass that makes sprites pop against any background.
The outline occupies transparent pixels adjacent to the art; the art itself is untouched. If the sprite touches the canvas edge, grow the canvas first with pixel_resize_canvas so the outline has room. Returns JSON {"canvas", "color", "pixels_outlined"}; plus a rendered image when preview=true. On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: it explains that the outline occupies transparent pixels without altering the art itself, describes the return format (JSON with canvas, color, pixels_outlined; image on preview=true), and mentions error handling. Annotations indicate destructive and idempotent hints, which the description supports.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise: it starts with the main action, explains a key nuance (canvas edge), specifies return format, and ends with error handling. Every sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (outlining with options for corners and preview), the description covers the core behavior, an important edge case, return values, and error handling. It lacks detail on idempotency or multi-call behavior but is otherwise complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. However, the description does not address individual parameters; it only mentions return fields. The input schema already provides basic descriptions for each parameter, but the tool description adds no extra value for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb and resource: 'Draw a 1px outline around all opaque art on the canvas.' It distinguishes this tool from siblings by mentioning it as 'the classic finishing pass' and referencing a prerequisite step (pixel_resize_canvas) for edge cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use the tool ('finishing pass') and gives a clear condition for when to first use pixel_resize_canvas (if the sprite touches the canvas edge). However, it does not explicitly exclude alternative tools or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pixel_replace_colorBDestructiveIdempotent
Replace every pixel of one exact color with another across the canvas.
Useful for palette swaps and recoloring sprites. Matching is exact RGBA. Returns JSON {"canvas", "find", "replace", "pixels_changed"}; plus a rendered image when preview=true. On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint: true and idempotentHint: true. The description adds the return structure (JSON with fields and preview option) and error handling. It does not contradict annotations. However, it does not explicitly state that the canvas file is modified in place, though that is implied by 'across the canvas' and the destructive hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and well-structured: first sentence states the core action, second adds use cases, third covers return value and error. There is no fluff, and it is front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers return format and error, but does not explain whether the canvas is modified in place (though annotations indicate destructive). It also doesn't mention idempotency despite the hint. With no output schema, the description partially fills the gap by listing return fields. For a simple color replacement tool, this is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all parameters (find, path, preview, replace) with format hints. The description adds that matching is exact RGBA, which is helpful but not critical. Since schema descriptions are present and detailed, the description does not add significant new semantics beyond clarifying exact matching.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Replace every pixel of one exact color with another across the canvas') and the resource (canvas). It mentions 'palette swaps and recoloring sprites' for context, but does not explicitly distinguish from sibling tools like pixel_flood_fill or pixel_apply_palette. The purpose is clear and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a usage indication ('Useful for palette swaps and recoloring sprites') and notes exact RGBA matching. However, it lacks guidance on when not to use this tool versus alternatives, or prerequisites such as the canvas file needing to exist. No explicit when-to-use versus 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.
pixel_resize_canvasADestructive
Change the canvas bounds without scaling the art — grow the canvas (new space is transparent) or crop it, with the existing art held at the chosen anchor.
Pixel sizes are unchanged; use pixel_scale_canvas to actually rescale art. Example: after squashing a sprite, resize back to the original height with anchor='bottom' to keep it grounded. Returns JSON {"canvas", "width", "height", "anchor"}; plus a rendered image when preview=true. On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavior: existing art is unchanged, new space is transparent, anchor determines placement, and it explains the return format including JSON and preview image. Annotations already indicate destructiveHint=true, but the description adds valuable context about what exactly happens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using four sentences to convey all key information. It front-loads the core purpose and includes an example and return format without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains the return JSON structure and error handling. It covers all necessary behavioral aspects for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has descriptions for all parameters, so the description's role is lighter. However, the description adds practical context (e.g., anchor='bottom' keeps feet planted, preview returns rendered image). This adds value beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it changes canvas bounds without scaling art, using a specific verb and resource. It distinguishes itself from the sibling pixel_scale_canvas by explicitly noting that pixel sizes are unchanged, making the purpose highly specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (grow or crop canvas) and explicitly points to pixel_scale_canvas as an alternative for rescaling art. It also gives a concrete example with anchor. However, it does not explicitly state when not to use it beyond the mentioned alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pixel_scale_canvasADestructive
Rescale the canvas and its art to new dimensions with nearest-neighbor sampling (no blurring).
Integer multiples or divisors keep pixels perfectly crisp; other ratios will distort — useful deliberately for squash-and-stretch animation frames. Returns JSON {"canvas", "width", "height"}; plus a rendered image when preview=true. On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds detail beyond annotations: nearest-neighbor sampling, crispness conditions, return format including optional preview, and error message. Annotations already indicate destructive behavior, and description aligns without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, each serving a purpose: action, quality conditions, return value, error handling. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers key aspects: algorithm, quality trade-offs, return structure, optional preview, and error handling. It misses explaining in-place modification (implied but not explicit), but annotations fill part of that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover all parameters (high coverage), but the description adds value by explaining how width/height ratios affect pixel quality and the preview parameter's effect. This extra context justifies a score above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool rescales canvas and art using nearest-neighbor sampling, and distinguishes itself by specifying the algorithm and crispness conditions. However, it does not explicitly contrast with sibling tools like pixel_resize_canvas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for use in squash-and-stretch animation frames but does not specify when not to use or mention alternative tools. It lacks explicit guidance on selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pixel_shift_canvasADestructive
Shift the whole canvas by (dx, dy) pixels — quick motion between animation frames (bobbing, jumping, sliding).
Without wrap, pixels shifted past the edge are lost and vacated space is transparent; with wrap=true they re-enter from the opposite edge (good for scrolling backgrounds). Returns JSON {"canvas", "shift", "wrap"}; plus a rendered image when preview=true. On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, and the description adds detail: pixels lost at edges, vacated space transparent, wrap re-entry behavior, and return JSON structure. This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the action, then covering wrap and return. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main behavior, wrap option, preview, and return JSON. With no output schema, it explains return structure. Missing explicit mention of parameter limits but schema covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover each parameter, but the tool description adds context for 'wrap' (re-entry from opposite edge) and clarifies what happens without wrap. It also mentions preview and return value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shifts the canvas by (dx, dy) pixels and provides specific animation use cases (bobbing, jumping, sliding). It contrasts with sibling tools like pixel_transform_canvas by focusing on quick translation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete example uses (animation frames, scrolling backgrounds) and explains the wrap behavior. It does not explicitly say when not to use, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pixel_slice_spritesheetAIdempotent
Split a spritesheet PNG into individual frame canvases — the way to bring existing game assets in for editing or re-animation.
Tiles are read left-to-right, top-to-bottom on a strict frame_width x frame_height grid (partial tiles at the right/bottom edges are ignored) and written to out_dir as '_f00.png', '_f01.png', .... Fully transparent tiles are skipped unless skip_empty=false. Returns JSON {"source", "out_dir", "frames_written", "skipped_empty", "frame_paths"}. On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing the scan order (left-to-right, top-to-bottom), handling of partial tiles, naming pattern, behavior of skip_empty, and the exact JSON response structure. It adds significant value beyond the annotations, which only indicate idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only 5 sentences, front-loaded with the core purpose, then followed by concise details. Every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description fully covers input behavior, edge cases (partial tiles, transparent tiles), and output format. It also mentions error responses, making it complete for an agent to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the input schema having descriptions for all parameters, the context signals indicate 0% coverage, so the description must compensate. It explains the grid size, naming pattern, and skip_empty behavior, which adds meaning beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool splits a spritesheet PNG into individual frames, using the verb 'split' and the resource 'spritesheet PNG'. It distinguishes itself from sibling tools like 'pixel_export_spritesheet' which does the reverse operation, making the purpose very clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'the way to bring existing game assets in for editing or re-animation', implying when to use it. However, it does not explicitly state when not to use it or compare it to alternatives, which would make it a 5. Still, it provides good contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pixel_transform_canvasADestructive
Flip or rotate the entire canvas in place.
Operations: flip_horizontal, flip_vertical, rotate_90_cw, rotate_90_ccw, rotate_180. 90-degree rotations swap the canvas dimensions. Returns JSON {"canvas", "operation", "width", "height"}; plus a rendered image when preview=true. On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true), the description adds key behavioral details: 'in place' modification, dimension swap on 90-degree rotations, the return JSON structure, preview behavior, and error format. These complement the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. It uses a short list and a clear return format paragraph. However, it could be slightly more structured (e.g., using sections).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple transformation tool, the description covers operation types, side effects (in-place, dimension swap), return format on success and failure, and the preview flag. With no output schema, it adequately documents the return. It could specify whether changes persist to the file, but overall it's fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the context indicates 0% schema description coverage, the actual schema includes descriptions for path and preview. The description adds value by listing all operation enum values explicitly. However, it does not explain path or preview beyond what the schema already provides, so the added value is modest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Flip or rotate the entire canvas in place' and lists all five operations explicitly. This verb+resource pairing is very specific and distinguishes the tool from siblings like pixel_shift_canvas, pixel_resize_canvas, and pixel_scale_canvas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like pixel_shift_canvas or pixel_scale_canvas. It only describes what it does, 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.
pixel_view_canvasARead-onlyIdempotent
Render a canvas as an image so you can see its current state.
Small canvases are upscaled with nearest-neighbor (crisp pixels) to about 512px on the long edge unless an explicit scale is given. Use this after a series of edits to check your work. Returns a text summary plus the rendered image. On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral details: upscaling behavior (nearest-neighbor to ~512px), return format (text summary plus image), and error handling ('Error: ...'). This goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, with the purpose front-loaded in the first sentence. Every sentence adds necessary information: purpose, scaling behavior, usage context, return format, and error handling. No redundant or ambiguous language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple view tool with one required parameter and no output schema, the description is complete. It covers the action, when to use, scaling behavior, return type (text+image), and possible error. No gaps remain for an agent to understand and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both parameters (path and scale), so the tool description does not need to repeat them. The description mentions 'unless an explicit scale is given', which implicitly refers to the scale parameter but adds little beyond the schema's description. Given schema coverage is effectively high (schema has descriptions), baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a canvas as an image to see its current state. It uses a specific verb ('Render') and resource ('canvas'), and the sibling tools list shows other view-related tools, but this one is distinct as it shows the current state. The description also provides usage context ('after a series of edits').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool after a series of edits to check work, giving clear context. However, it does not mention alternatives or when not to use it, though the sibling tools include other view functions like pixel_view_frames. Still, the provided usage guidance is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pixel_view_framesARead-onlyIdempotent
Render several same-size canvases side by side as one filmstrip image — review a whole animation or sprite set at a glance.
Frames are laid out left-to-right, top-to-bottom on a neutral gray backdrop with thin separators, in the order given. Nothing is written to disk. Returns a text summary naming each frame position plus the rendered image. On failure returns "Error: ...".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds value by stating nothing is written to disk, describing the visual layout (neutral gray backdrop, thin separators), and specifying return format (text summary plus image) and error handling. This goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences), front-loaded with the key action and purpose. Each sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, complete schema descriptions, and annotations, the description covers purpose, behavior, output, and error format. It lacks example usage or limits on frame count beyond schema, but overall is comprehensive for a read-only operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has good descriptions for all three parameters. The tool description adds minor context (same-size constraint, order, layout detail) but does not significantly extend schema semantics. With high schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Render') and resource ('canvases as one filmstrip image') and clearly states the purpose: reviewing animations or sprite sets. It is distinct from sibling tools like pixel_view_canvas (single canvas) and pixel_export_spritesheet (export format).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reviewing animation/sprite sets 'at a glance' but does not explicitly state when to use or avoid this tool, nor does it mention alternatives like pixel_view_canvas or pixel_onion_view.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
23 tool updates
v0.2.0- First observed
pixel_apply_palette - First observed
pixel_canvas_info - First observed
pixel_copy_region - First observed
pixel_create_canvas - First observed
pixel_draw_ellipse - First observed
pixel_draw_line - First observed
pixel_draw_pixels - First observed
pixel_draw_rect - First observed
pixel_duplicate_canvas - First observed
pixel_export_gif - First observed
pixel_export_png - First observed
pixel_export_spritesheet - First observed
pixel_flood_fill - First observed
pixel_onion_view - First observed
pixel_outline_sprite - First observed
pixel_replace_color - First observed
pixel_resize_canvas - First observed
pixel_scale_canvas - First observed
pixel_shift_canvas - First observed
pixel_slice_spritesheet - First observed
pixel_transform_canvas - First observed
pixel_view_canvas - First observed
pixel_view_frames
TDQS
A4.2/5.0
Disambiguation5/5
All 23 tools have clearly distinct purposes, from creating and drawing on canvases to exporting and slicing spritesheets. Each tool's description uniquely identifies its function, and there is no overlap or ambiguity between them.
Naming Consistency5/5
All tool names follow a consistent 'pixel_verb_noun' pattern in snake_case (e.g., pixel_create_canvas, pixel_draw_pixels, pixel_export_png). This makes the tool set predictable and easy to navigate for an agent.
Tool Count4/5
With 23 tools, the server is on the higher end of the typical range, covering a broad set of pixel art operations. While each tool is justified, the count could be slightly reduced by merging some related operations, but overall it remains well-scoped.
Completeness5/5
The tool set covers the full lifecycle of pixel art creation and manipulation: creation, drawing (shapes, lines, fill), editing (color replacement, transforms, copy region), viewing, export (PNG, GIF, spritesheet), animation support (onion skinning, shift, duplicate), and import (slicing spritesheets). No obvious gaps are present.
Maintenance
ActivitySlowing
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Game-dev sprite tools: PNG/GIF to spritesheet, split, trim, animate. OAuth-authenticated MCP server.
Generate authentic pixel art - sprites, animations, and tilesets - from any MCP client
MCP server for NanoBanana AI image generation and editing
MCP server for Flux AI image generation
Related MCP Servers
- AlicenseAqualityDmaintenanceA pixel art animation MCP server for AI agents, enabling scene generation, sprite drawing, and PNG export with zero latency.19223MIT
- FlicenseAqualityDmaintenanceAn MCP server that enables AI coding agents to create pixel art programmatically by providing canvas manipulation tools and PNG export.10302-
- AlicenseNot gradedqualityBmaintenanceMCP server for generating pixel-art sprites with transparent backgrounds using any diffusers-compatible text-to-image model.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/light-vp/pixelart-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server