CommunityActive· 1mo★ 4.3by diivi

Aseprite MCP

Controls the Aseprite pixel art editor over its API so agents can create, edit, and export sprite sheets for games.

View repo

Safety & Trust

Delv Safety Grade: C

Score 58/100 · assessed 2026-04-28

Maintainer40

Permissions55

Supply chain45

Transparency75

Incidents100

Aseprite MCP is a community project by solo developer diivi that bridges Claude to the Aseprite pixel art editor via its scripting API. The server enables programmatic control of a desktop application, which inherently carries elevated risk: it can create, modify, and export files through Aseprite's capabilities. The maintainer appears to be a single developer with limited public profile, creating bus factor concerns. Installation requires cloning and running via uv, bypassing standard package registries and their review processes. The repository is open source with reasonable documentation, which aids transparency. No security incidents are known. The core risk is desktop application control: whilst scoped to Aseprite's API, this still grants filesystem write access and potential for unintended modifications to project files. Suitable for users who already trust Aseprite and understand the implications of programmatic editor control, but requires caution in production environments.

Lethal Trifecta (prompt-injection exposure)

CLEAR

Private dataNo

Reads secrets, credentials, private files

Untrusted inputNo

Ingests web pages, PRs, issues, emails

External commsNo

Can send data outbound

Local pixel art editor.

Green flags

Open source with clear documentation of capabilities
Scoped to Aseprite's API rather than arbitrary shell access
No environment secrets required
Specific use case (pixel art) limits attack surface
No known security incidents

Red flags

Solo maintainer with limited public track record
Desktop application control enables broad filesystem manipulation
No package registry distribution, clone-and-run install only
Aseprite API access could modify or delete existing project files

Permissions requested

Desktop controlRead filesWrite filesDelete files

Assessed by Delv Editorial using public metadata. Grades are advisory and update as the ecosystem changes. They do not replace your own review of permissions and code before granting an agent access to sensitive systems.

Install

uv --directory . run -m aseprite_mcp

Review

Aseprite MCP bridges Claude to the Aseprite pixel art editor, letting agents create and manipulate sprites through Aseprite's scripting API. It's a direct control layer: you describe what you want, Claude sends commands, Aseprite executes them. No image generation models here, just programmatic access to a proper pixel art tool. I'd reach for this when prototyping game assets or iterating on sprite sheets without leaving the Claude conversation. The workflow is surprisingly tight: ask Claude to create a 32x32 character sprite, define a palette, add animation frames, export as a sheet. Aseprite does the rendering, so you get proper indexed colour, dithering, and all the pixel-level control the editor is known for. It's not replacing an artist, but it's excellent for roughing out placeholders or automating tedious sprite sheet tasks. The main quirk is that Aseprite must be running and configured to accept API requests. You're not controlling a headless service; you're remote-controlling a GUI app. This means you need Aseprite installed, licensed if you're using the official build, and set up to listen on a local port. The MCP handles the protocol, but you're responsible for the Aseprite side. Documentation assumes you know your way around Aseprite's scripting environment, so if you've never touched a .lua script or the app's extension system, expect a learning curve. Palette editing is where this shines. Claude can read existing palettes, suggest modifications, and apply them across frames. For anyone building retro-style games with strict colour limits, this is a genuine time-saver. Sprite sheet export is similarly practical: define grid sizes, spacing, and output formats without clicking through menus. Who shouldn't bother: if you don't own Aseprite or work with pixel art, this is useless. If you want AI-generated art from prompts, you're in the wrong place. This is for developers who already use Aseprite and want to script it through Claude instead of writing Lua by hand. It's a niche tool for a specific workflow, and it does that workflow well.

Verdict

Install this if you're already using Aseprite for game dev and want to automate sprite tasks through Claude. Skip it if you don't work with pixel art or don't have Aseprite configured for API access. It's a solid bridge between two tools, not a standalone solution.

Good at

Direct control of Aseprite's full feature set, including palettes, layers, and animation frames.
Excellent for automating sprite sheet exports and batch operations without manual clicking.
Works with Aseprite's native file formats, so you keep all metadata and editability.
Tight integration for game dev workflows where pixel art is already part of the pipeline.

Watch out

Requires Aseprite installed, running, and configured for API access, which adds setup friction.
Useless if you don't work with pixel art or don't own an Aseprite license.
Documentation assumes familiarity with Aseprite's scripting model and API structure.
No fallback if Aseprite crashes or the API connection drops mid-task.

Use cases

pixel art generation
sprite sheet export
palette editing
game asset pipelines

Getting started

1. Install Aseprite and configure it to accept API requests (check Aseprite's scripting docs for enabling the HTTP server). 2. Run `uv --directory . run -m aseprite_mcp` to start the MCP server. 3. Add the server to your Claude Desktop config under `mcpServers` with the appropriate command path. 4. Restart Claude Desktop and verify by asking Claude to create a new sprite in Aseprite. 5. Watch out: if Aseprite isn't running or the API port isn't open, commands will fail silently until you check the MCP logs.

Works with

Claude DesktopClaude CodeCursor