spriteloom-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SPRITELOOM_OUT | No | Legacy output directory variable; equivalent to SPRITELOOM_OUTPUT_DIR. | |
| SPRITELOOM_URL | No | Explicit WebSocket connection to an existing engine. This mode does not start or stop the engine. Use a trusted connection. | |
| SPRITELOOM_PORT | No | Local engine port. Default is 127.0.0.1:8765. | |
| SPRITELOOM_OUTPUT_DIR | No | Output directory. Legacy SPRITELOOM_OUT also works. | |
| SPRITELOOM_ENGINE_ROOT | No | Absolute path to the spriteloom-mlx engine checkout with its .venv and model cache. If omitted, the server assumes the engine repository is in the same parent directory. | |
| SPRITELOOM_IDLE_SECONDS | No | Idle shutdown delay in seconds; 0 disables it. Default is 600 (ten idle minutes). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| spriteloom_statusA | Read the local SpriteLoom service state. This never starts the model and returns state, backend, WebSocket URL, process ID, and ownership. |
| generate_spriteB | Generate one or more pixel-art sprites from a prompt. Width and height are 1..512 pixels. Each result is saved in a unique output directory and returned as a PNG preview. |
| edit_spriteB | Edit an existing sprite with an instruction. The source dimensions are used when width or height is omitted. preserve_palette keeps the source palette unless set to false. The source file is never changed. |
| inpaint_spriteB | Inpaint a selected region of an existing sprite. image_path and mask_path must have equal dimensions. The returned patch is clipped to the original binary mask, then composited with source pixels outside the mask preserved. Set overlay_path to save transparent patch PNGs as well as composite PNGs. |
| rotate_spriteB | Re-view a sprite from a requested direction with SpriteLoom's instruction mode. Provide the subject and view explicitly. This uses the model; it does not rotate pixels. image_path is never changed. |
| list_generationsB | List recent MCP-owned generation metadata. Only metadata files with the SpriteLoom MCP ownership marker are read; arbitrary directories and files are ignored. |
| stop_serviceA | Explicitly stop the shared headless SpriteLoom service. Generation tools share the service; it also stops after ten idle minutes by default. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Six of seven tools are cleanly separated by action: generate, edit, inpaint, rotate, list, stop, status. The main risk is edit_sprite vs rotate_sprite, since both take an existing image plus an instruction; the rotate description explicitly says it re-views rather than rotates pixels, which mitigates but does not eliminate the overlap.
Most tools follow a consistent verb_noun pattern (generate_sprite, edit_sprite, inpaint_sprite, rotate_sprite, list_generations, stop_service). spriteloom_status breaks the pattern by being noun-first with a vendor prefix, a minor deviation within an otherwise predictable set.
Seven tools is well-scoped for a sprite generation service: four generation/editing operations plus lifecycle and listing helpers. No tool appears redundant or superfluous.
Core lifecycle is covered: generate, modify (edit/inpaint/rotate), list, status, stop. Minor gaps exist — no delete/cleanup of generated outputs, no get-by-id detail fetch for a single generation, and no explicit service start — but these are workable around the filesystem.