Skip to main content
Glama
midarikawa

Aseprite MCP Tools

by midarikawa
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Related Servers

Alternatives to Aseprite MCP Tools

No user-submitted related servers found.

    Related Servers

    • mnehmos.aseprite.mcp

      Mnehmos
      A
      license
      Not graded
      quality
      C
      maintenance
      Enables AI agents to create, inspect, edit, and export pixel art, sprites, animations, and spritesheets using headless Aseprite, and to convert arbitrary images into indexed pixel art.
      MIT

    • aseprite-mcp

      VukasinTheProgrammer
      A
      license
      Not graded
      quality
      B
      maintenance
      Enables AI assistants to drive Aseprite for pixel-art creation, including sprite setup, grid-based drawing, layer/frame/tag management, reference image import, and export, with rendered previews after every mutation.
      MIT

    • Pixel Art AI

      stereomp3
      A
      license
      Not graded
      quality
      B
      maintenance
      Enables AI coding agents to create, draw, and refine Aseprite documents through deterministic canvas, layer, frame, tag, and palette tools, with pixel analyzers, style validation, and preview/diff visual feedback. It also supports spritesheet and animated GIF export, producing multi-layer game-ready assets.
      1
      MIT

    • Aseprite-MCP

      iborymagic
      A
      license
      C
      quality
      D
      maintenance
      Enables AI assistants to automate Aseprite tasks such as sprite sheet export, frame extraction, and Lua scripting for sprite manipulation.
      21
      42 npm
      1
      MIT
    Deploy Server
    One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

    TDQS

    B3.1/5.0

    Scored across 116 tools

    Disambiguation3/5

    The set contains many near-duplicate pairs distinguished only by an `_at` suffix (draw_pixels vs draw_pixels_at, draw_line vs draw_line_at, draw_rectangle vs draw_rectangle_at, fill_area vs fill_area_at) plus overlapping variants like adjust_hsl vs adjust_hsl_native, outline_cel vs outline_native, add_frame vs add_frames, copy_cel vs copy_frame, propagate_cels vs propagate_frame_to_range, and tween/oscillate variants. The descriptions do clarify the active-canvas vs explicit layer/frame distinction, so an agent can disambiguate, but the boundaries are subtle and misselection is easy.

    Naming Consistency4/5

    The overwhelming majority follow a consistent snake_case verb_noun pattern (set_palette, create_layer, delete_frame, draw_circle, export_frame). A few deviate (animation_workflow_guide is a noun phrase, animation_sanitize inverts order, some `_native`/`_at`/`_all` suffixes), but these remain readable and predictable overall.

    Tool Count1/5

    116 tools far exceeds a workable surface for an agent and lands squarely in the extreme-mismatch range (50+). Many of these could be consolidated (e.g. the parallel `_at` variants, multiple tween/export/propagate functions), and the sheer size makes correct tool selection costly.

    Completeness5/5

    The surface covers the full pixel-art lifecycle: canvas/frame/layer/cel/tag management, drawing primitives, palette handling, filters, tilemaps, slices, text, exports, and animation validation/audit. The inclusion of run_lua_script as an escape hatch guarantees no operation is a true dead end.

    Maintenance

    ActivityMaintained
    ResponsivenessNo issues

    Resources