Product reference

SpriteRelay technical reference

A tool count means nothing without the rule behind it. This page gives you the numbers, how each one was counted, the Aseprite versions they were measured against, and the exact way to undo anything the assistant does. If you are deciding whether SpriteRelay belongs in your pipeline, everything worth checking is here.

  • Six tools eachBoth products expose exactly six MCP tools, not a sprawl of endpoints your agent has to sift through.
  • 166 or 216 operations166 CLI public inventory entries; 216 in Live, including the same 166 plus 50 Live-specific entries. Reserved entries and capability gates limit availability.
  • Two write boundariesLive edits the open document as one undoable step. CLI touches your project files only when you commit.

The two products

What you actually get

SpriteRelay ships as two separate products. They share an operation language but solve different problems, and you can buy either one alone or both as Complete.

Live — for the sprite you have open right now

Live works on the document already open in Aseprite. You ask, the change appears, you keep it or press undo. Six tools, 216 public operation inventory entries, and an important detail: a patch against an existing document is grouped into one labelled native Aseprite transaction. Not fourteen undo steps to unpick — one. Creating a brand-new document is the stated exception, since it falls outside the existing document's history.

The server runs outside Aseprite and reaches the editor through the matched Bridge extension over a token-authenticated localhost connection. It never saves your document to disk on its own, so closing without saving is always available to you.

CLI — for the files you cannot afford to break

CLI does not need Aseprite open. It launches your licensed copy in batch mode against a copy of your file, which is why it suits build steps and scripted work. Six tools, 58 named modes, 166 public operation inventory entries, and one rule that does most of the work: file_commit is the only tool allowed to write a path you chose. Patch, export, and preview write into managed staging workspaces; doctor and inspect write nothing at all.

That means you can let an agent iterate as long as it likes and still decide, at the end, what reaches your repository.

Choosing

Which one fits your work

The honest split is about when you want to see the result.

Pick Live if you are drawing and want an assistant beside you — recolouring, adding frames, fixing timing, trying an idea and undoing it. The feedback is immediate because the change lands in the editor you are already looking at.

Pick CLI if the work is repetitive or the files are precious: batch exports, sprite-sheet recipes, palette variants across a directory, anything you want to preview and verify before it becomes permanent. Aseprite does not need to be open, so it fits build steps and scripted pipelines.

If your work spans both, Complete bundles the two products and the matched Bridge under one licence for $14.99 — $4.99 less than buying them separately. The pricing section has the side-by-side comparison and the current prices.

The interface

Every tool, and what it is for.

Six tools per product group typed operations behind a compact interface. This design aims to reduce tool-definition overhead and make operation selection clearer. Actual token use and selection accuracy depend on the client, model, and task; no measured improvement is claimed.

CLI toolWhat it doesSurface
aseprite_doctorFinds your Aseprite, validates the version and Lua environment, probes what the installation can actually do, and reports it.2 modes
sprite_inspectReads sprites, directories, manifests, recipes, rendered pixels, and the operation catalog — so the agent looks before it edits.18 modes
sprite_patchValidates an ordered operation list and applies it to a staged copy.166 inventory entries
sprite_exportProduces staged image, document, palette, mask, metadata, batch, atlas, and variant artifacts.14 modes
sprite_previewRenders a still image or animated GIF you can review inline before committing to anything.12 modes
file_commitPromotes staged artifacts, verifies them, manages journals, and rolls back. The only tool that writes where you told it to.12 modes
Live toolWhat it doesSurface
live_doctorChecks the server, the Bridge, and that their versions match.5 modes
live_sessionAttaches to a document, reports status, undoes, redoes, and reads editor state.52 modes
live_inspectReads context from the document you have open.23 modes
live_patchEdits the attached document. One patch, one native undo step — new-document creation excepted.216 inventory entries
live_previewRenders the active frames and tags.19 modes
live_exportStages, commits, and rolls back exports.4 modes

Show your working

How we count

Operation counts are easy to inflate — count aliases twice, count every option as a feature, count the same thing in two products. So here is the rule behind every number on this page. You can hold us to it.

  • Six tools per product. Top-level MCP tools exposed over stdio. New capability goes into an existing tool as a mode, operation, or option; it never becomes a seventh tool to make the list look longer.
  • 58 CLI modes. The named modes on the five mode-based tools: 2 + 18 + 14 + 12 + 12. sprite_patch is excluded because it takes operations rather than modes, and the legacy aseprite_doctor.action field is an alias for two modes already counted — not two more.
  • 166 CLI operations. The public inventory of sprite_patch operations, partitioned into 16 families: canvas and document, layers, layer organization, drawing and palette basics, timeline and tags, animation tag workflows, cels, import, native tools, slices, selections and masks, filters and colour, tileset management, tilemap layers, tile-cell mutation, and user data and properties.
  • 216 Live operation inventory entries. The same 166 shared entries, plus 50 Live-specific entries. These totals count public vocabulary, including reserved entries, rather than universally runnable operations. pixel_perfect_line_cleanup is unsupported in both runtimes; set_ink_type is unsupported in CLI. Other operations depend on the capability gates below. We do not add the two products together to advertise 382.
  • 28 capability flags. What aseprite_doctor reports about your Aseprite. These describe your environment, not features you are buying.

One thing that could otherwise mislead: the operation catalog can also be searched by intent — document, drawing, pixels, selection, layer, cel, animation, palette, tilemap, slice, metadata, import, live UI. That is a search filter, a different grouping of the same operations, and it does not change the total.

Your agent never has to guess an operation's arguments either. sprite_inspect mode operation_describe returns the strict schema, working examples, prerequisites, and related operations for any operation by name.

The obvious worry

What if it does something you didn't want?

This is the question worth asking of any tool that edits your art, so here is the specific answer for each product.

In Live, you press undo

A patch against an existing document is one labelled native transaction, so Aseprite's own undo removes the whole thing in a single step. Live never saves the file for you, which means discarding the session is also a recovery path. If a change is interrupted partway, it is flagged as uncertain rather than quietly retried — you get told to look, not surprised later.

In CLI, nothing is permanent until you say so

Staged work can be thrown away outright; your project files were never touched. Once you do commit, the specifics are:

  • commit_single promotes one file atomically. Overwriting an existing file leaves a .bak beside it — a first-time write has nothing to back up, and we say so rather than implying a safety net that isn't there.
  • commit_manifest writes a durable journal before touching any destination, then promotes the batch and rolls it back on failure where it can.
  • dry_run_manifest builds and validates the identical plan without writing anything.
  • verify_commit re-checks destinations against the journal's hashes and tells you intact, drifted, or incomplete.
  • rollback_single restores a .bak; rollback_manifest restores or removes everything a past manifest commit recorded.
  • commit_quarantine puts artifacts in a guarded directory instead of their real destinations when you want to inspect first, and the journal modes list, inspect, import, and clean up the records.

These reduce risk; they do not abolish it. Hardware fails, permissions surprise people, and a client can send an instruction you did not intend. Keep your own backups and review results before you rely on them — that advice is in our licence agreement because we mean it, not as a formality.

Straight answers

Where the limits are

Version-sensitive behavior is gated rather than assumed. aseprite_doctor combines version thresholds with real behavior probes — writing and reopening files, round-tripping enum values, attempting an export — and anything that depends on a capability your build lacks fails with a clear unsupported error instead of silently producing the wrong result. Representative gates:

  • Custom sprite, layer, cel, tag, slice, tileset, and tile properties need Lua API 21+.
  • draw_path and draw_text need API 30+.
  • Layer editability and continuity, and reassigning a tilemap layer's tileset, need API 38+.
  • Diagonal cel flipping and optional undo/redo counts need API 35+.
  • Tile-cell mutation needs a probe that writes tile indices, saves, reopens, and confirms they survived.
  • PSD export needs a successful write probe, because most Aseprite builds have no native PSD writer.
  • Layer UUID references need a save-and-reopen persistence probe.

Two operations are simply unavailable rather than gated, and we would rather you read it here than discover it later. set_ink_type is editor-session state and always reports unsupported in CLI batch runs — set the ink directly on a tool stroke instead. pixel_perfect_line_cleanup is a reserved schema entry that is unsupported in both current runtimes.

Finally, the boundary on the whole thing: we cannot guarantee compatibility with future or modified versions of Aseprite, Node.js, operating systems, the MCP specification, or third-party clients. Nobody honestly can.

Trust boundary

Security, briefly

Neither product gives an agent a raw-Lua or arbitrary-code channel. Requests are typed and validated; every caller-supplied path passes a path guard; Aseprite subprocesses launch with explicit argument arrays, no shell, enforced timeouts, and bounded output buffers; and standard output is reserved for protocol traffic so logs cannot corrupt a response.

The part people usually miss is that SpriteRelay staying local says nothing about your AI client, which is separate software with its own data handling. How SpriteRelay handles local processing and recovery covers that boundary properly, along with what we do and do not claim.

Next step

Still deciding?

If the numbers above check out for your setup, the pricing section has the current one-time prices for Live, CLI, and Complete. If something here does not match your environment — an older Aseprite, an unusual client, a pipeline you are not sure about — send the details to support@spriterelay.com and get an answer before you spend anything.

Worth reading next: the Aseprite MCP workflow guide if you are new to the category, security and local processing if data handling is your concern, or the licence agreement for the terms that control all of it.