Skip to main content
Glama
sloplink

aseprite-mcp

by sloplink
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

View image

aseprite_view
Read-only

Render the current frame as a PNG to inspect the drawing result, with optional zoom and critique panels for color, grayscale, silhouette, and color-blindness checks.

Instructions

Renders the visible, flattened frame as an upscaled PNG so you can look at and check the result yourself. Transparency is shown as a checkerboard. Use rect to zoom into a detail. Call it once after a drawing pass, not after every step. If your client cannot show images, use aseprite_read_pixels instead. critique=true instead returns ONE small sheet for self-review: colour, grayscale (value/contrast check), black silhouette (readability) and true 1x size; add 'deutan' to panels for a colour-blindness check. Max 128x128 px (or pass rect).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
gridNoDraw a pixel grid (scale 4 or more)
rectNoOnly this [x, y, width, height] region or "selection", zoomed in (default: whole canvas)
frameNo
scaleNoDefault: automatic (~512 px)
panelsNocritique only (default ["color","gray","silhouette","1x"])
checkerNo
critiqueNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.6.0
    • addedInput schema / properties / critique
      Added value: +{
+  "default": false,
+  "type": "boolean"
+}
    • removedInput schema / properties / frame / maximum
      Removed value: -9007199254740991
    • changedInput schema / properties / frame / type
      Previous value: -"integer"New value: +"number"
    • addedInput schema / properties / panels
      Added value: +{
+  "description": "critique only (default [\"color\",\"gray\",\"silhouette\",\"1x\"])",
+  "items": {
+    "enum": [
+      "color",
+      "gray",
+      "silhouette",
+      "deutan",
+      "1x"
+    ],
+    "type": "string"
+  },
+  "maxItems": 5,
+  "minItems": 1,
+  "type": "array"
+}
    • addedInput schema / properties / rect
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "number"
+      },
+      "maxItems": 4,
+      "minItems": 4,
+      "type": "array"
+    },
+    {
+      "enum": [
+        "selection"
+      ],
+      "type": "string"
+    }
+  ],
+  "description": "Only this [x, y, width, height] region or \"selection\", zoomed in (default: whole canvas)"
+}
    • changedInput schema / properties / scale / type
      Previous value: -"integer"New value: +"number"
  2. First observedv0.2.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, and the description adds substantial behavior: transparency checkerboard, max 128x128 px output, upscaled rendering, and the exact composition of critique sheets (color, grayscale, silhouette, 1x, optional deutan). No contradictions with annotation.

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?

Six sentences pack the main purpose, transparency display, rect usage, call frequency, alternative, critique mode, and size limit with zero filler. Each sentence serves a distinct purpose, and the most important information is front-loaded.

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 invocation timing, return type (PNG vs critique sheet), use of alternatives, and output size constraints. Minor gaps such as frame parameter behavior are deducible from 'visible, flattened frame' and default annotations, and the lack of an output schema is partially offset by the explicit rendering description.

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

Parameters4/5

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

The description adds meaning for key parameters: rect is described as zoom-to-detail, critique/panels are explained including the 'deutan' option, and scale's default is implied by 'upscaled'. Schema coverage is 57%, but the description compensates for the most impactful parameters, though frame, grid, and checker details remain inferable rather than explicit.

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 a specific verb ('Renders'), resource ('visible, flattened frame'), and output ('upscaled PNG'), making the tool's purpose unmistakable. It also differentiates from aseprite_read_pixels by explicitly noting the alternative for clients that cannot display images.

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

Usage Guidelines5/5

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

It gives explicit timing guidance ('Call it once after a drawing pass, not after every step') and names the alternative aseprite_read_pixels when images cannot be shown. It also clarifies when to use critique mode, leaving no ambiguity about selection.

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

Deploy Server

Other Tools