SpriteShip
SpriteShip for Cursor

An AI sprite generator Cursor can drive

Cursor reads project rules from .cursor/rules — drop the SpriteShip rule there and Composer can fetch art the same way it fetches a package.

Connect

Point Cursor at the MCP server.

40 tools over one endpoint — list, read, export, curate frames, generate. Same key, same guardrails as the REST API, and paid tools preview their cost before they run.

Add to .cursor/mcp.json
{
  "mcpServers": {
    "spriteship": {
      "url": "https://spriteship.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:SPRITESHIP_API_KEY}"
      }
    }
  }
}

Project-scoped in .cursor/mcp.json, or ~/.cursor/mcp.json for every project. The ${env:…} form is Cursor’s own idiom for keeping the secret out of a committed file — which matters here, because .cursor/ is committed.

Key + smoke test
# 1. Point your agent's shell at your key
export SPRITESHIP_API_KEY="ss_live_..."

# 2. Confirm it works
curl -sS -H "Authorization: Bearer $SPRITESHIP_API_KEY" \
  https://spriteship.com/api/v1/me

# 3. Teach the agent the API — the skill ships an AGENTS.md
cat <spriteship-skill>/AGENTS.md >> AGENTS.md
Optional, and worth it

Add the skill too.

MCP gives Cursor the tools. The skill gives it the recipes — how to sync into a project tree, how to re-sync only what changed, and the protocol it must follow before spending a credit. They compose.

Add the project rule
# The skill ships an AGENTS.md — drop it in as a project rule:
mkdir -p .cursor/rules
cp <spriteship-skill>/AGENTS.md .cursor/rules/spriteship.mdc

# Cursor also reads AGENTS.md at the repo root — either works.

Cursor’s Project Rules live in .cursor/rules as .mdc files. Cursor also reads AGENTS.md at the repo root, so either location works — the rules folder is preferred because you can scope the rule to your assets directory. <spriteship-skill> is the SpriteShip agent skill — getting the skill →

Why it fits

Built for how Cursor works.

Composer closes the loop

Because generation and code live in one session, Cursor can fetch a walk cycle and register it in your animation config in the same turn — the sprite and the code that plays it never drift apart.

Scope the rule to your asset folder

An .mdc rule can carry a glob, so the SpriteShip instructions only load when Cursor is working under assets/ — no context budget spent on it while you are editing unrelated code.

The lock file survives Composer

spriteship.lock.json records contentVersion per entity. When you revise a sprite in the dashboard, the next sync pulls only that one — Cursor does not re-download the whole project.

Worked example

One ask, start to finish.

"my player sprite looks wrong at 64px — pull the downscaled variant instead"

  1. 01Reads the lock file to find the character id already in the project
  2. 02Re-exports at ?size=64 — a free re-package, not a regeneration
  3. 03Overwrites the sheet and atlas in place, coordinates rescaled
  4. 04Updates the Phaser loader call to match the new frame size
The actual loop

The full loop, once.

Every agent runs the same shape — resolve, preview the cost, confirm, generate, poll, write the files, wire the code.

Session
you › the knight needs a dodge-roll animation, then wire it into the player state machine

  agent › GET /api/v1/characters?name=knight
          → chr_8fq2… · contentVersion 4a1c… · 6 animations

  agent › POST /api/v1/characters/chr_8fq2…/generate-pose  { dryRun: true }
          → 400 credits · balance 1,500 → 1,100

  you   › go ahead

  agent › POST /api/v1/characters/chr_8fq2…/generate-pose
          Idempotency-Key: 7c1f-…
          → job_2b9e… queued
  agent › GET /api/v1/jobs/job_2b9e…            → running
  agent › GET /api/v1/jobs/job_2b9e…            → done · 400 credits charged

  agent › GET /api/v1/characters/chr_8fq2…/export?engine=phaser&format=json
          → wrote assets/spriteship/knight/spritesheet.png
            wrote assets/spriteship/knight/atlas.json
            wrote spriteship.lock.json  (contentVersion 91be…)

  agent › edited src/player/PlayerStateMachine.ts
          + case 'dodge': this.play('dodge_roll'); break;

done — dodge_roll is registered and playable. 400 credits spent.
Guardrails

Handing an agent a budget, safely.

An agent that can spend money needs more than an API key. Every one of these is enforced server-side — not a convention the agent is trusted to follow.

Scoped keys

Four scopes, granted separately: assets:read, account:read, assets:write, credits:spend. A read-only key physically cannot spend money.

Per-key spend caps

Every key carries a daily credit ceiling — 5,000 by default, 50,000 maximum. Accounting is gross, so refunds restore your balance but never hand the key back headroom.

Over MCP, paid tools preview by default

Every paid MCP tool defaults to a dry run: it returns the exact credit cost and your resulting balance, and executes nothing. The agent has to deliberately re-call with dryRun:false to spend. Accidental spend is not a thing it can stumble into.

Idempotency keys

Paid writes require an Idempotency-Key header. A retried request replays the original job pointer instead of starting — and paying for — a second generation.

Busy-entity guard

A write against an entity that already has a job running answers ENTITY_BUSY rather than racing it, so two agents (or one confused agent) cannot corrupt the same character.

Re-sync signals

Every read carries contentVersion or updatedAt. The agent diffs those against its lock file and re-downloads only what actually changed after you edited something in the dashboard.

Presigned binaries

Every sheet, atlas, zip and preview URL is presigned and expiring. Nothing in an API response is a permanent public link.

Kill switch

Revoking a key cancels its in-flight jobs and refunds their unfinished charges. Leaked keys found by GitHub secret scanning are revoked automatically and you get an email.

What lands in your repo

Output an agent can actually use.

A folder of PNGs makes an agent guess. Every SpriteShip export explains itself, so the agent wires it up instead of improvising.

Self-describing bundles

Every export zip carries a manifest (tizo-export.json), a JSON Schema of its own shape, a README, a runnable preview and a SKILL.md — so an agent can consume the output without you explaining the format.

Native engine files

Phaser atlases, Godot 4 .tres resources, Unity sliced sprites with stable GUIDs, GameMaker sprite strips and Tiled tilesets. Not a folder of PNGs the agent has to guess at.

Collision, not bounding boxes

Authored collision bodies and ground footprints ride through the API and into every export, so the agent builds the real collider instead of defaulting to the sprite rectangle.

Mount points

Per-frame anchor points for weapons, hands and heads travel with the animation, so the agent can parent a projectile spawn to the right pixel on the right frame.

Questions

Cursor, specifically.

MCP or the REST API?

MCP is the fast path — one config block and Cursor has 40 typed tools it can discover on its own. The REST API is the same surface underneath, and stays available if you would rather have Cursor just call it. Both use the same key, the same scopes and the same spend cap.

Where does the key live?

In your shell environment as SPRITESHIP_API_KEY, never in the rules file. The rule tells Cursor which env var to read; it never contains the secret. Anything in .cursor/rules is committed, so a key there would be a key in your git history.

Point Cursor
at your art.

1,500 free credits, no card. Reading and re-syncing never cost anything.

Start free — 1,500 credits