<p align="center">
  <img src="docs/media/spine-mcp-intro.webp" alt="spine-mcp" width="100%">
</p>

<p align="center">
  <b>Let an AI agent read, measure, see and safely edit your Spine 4.3 animations.</b><br>
  Spine has no scripting API. spine-mcp works through the official channels anyway (the Spine CLI, the Spine JSON
  format and the official runtimes) and proves every change: each write is backed up, re-exported and verified, and
  rolls back on any mismatch.
</p>

<p align="center">
  <img src="https://img.shields.io/badge/Spine-4.3.26-5B6CFF" alt="Spine 4.3.26">
  <img src="https://img.shields.io/badge/MCP-38%20tools-4FF3E0" alt="38 MCP tools">
  <img src="https://img.shields.io/badge/node-%E2%89%A522-339933" alt="Node 22+">
  <img src="https://img.shields.io/badge/platform-macOS%20%7C%20Windows-lightgrey" alt="macOS and Windows">
  <img src="https://img.shields.io/badge/tests-535%20passing-brightgreen" alt="535 tests passing">
  <a href="LICENSE"><img src="https://img.shields.io/badge/license-MIT-blue" alt="MIT license"></a>
</p>

<p align="center">
  <a href="#quick-start"><b>Quick start</b></a> ·
  <a href="#feature-tour">Feature tour</a> ·
  <a href="#what-it-can-do">What it can do</a> ·
  <a href="#highlights">Highlights</a> ·
  <a href="#how-a-write-stays-safe">Safety</a> ·
  <a href="docs/REFERENCE.md"><b>Reference</b></a> ·
  <a href="docs/USAGE.md">Usage guide</a>
</p>

<p align="center">
  <a href="docs/media/spine-mcp-launch.mp4"><img src="docs/media/spine-mcp-launch.webp" alt="spine-mcp demo: Bolt's PSD layers become a rig with bones, then walk, turn and hop-squash rendered by Spine, verified writes and Unity's render next to Spine's" width="100%"></a>
</p>
<p align="center"><sub>22-second demo: PSD → rig → animation → Unity, every shot a real result · plays inline · <a href="docs/media/spine-mcp-launch.mp4">MP4 with sound</a></sub></p>

## Feature tour

Ten short videos, one per area. Every clip, picture and number in them comes from the real spine-mcp server, on Bolt (the demo character) and on Esoteric's example characters ([`scripts/make-feature-media.mjs`](scripts/make-feature-media.mjs) makes them again). Click one for the MP4 with sound.

<table>
  <tr>
    <td width="50%" valign="top"><a href="docs/media/spine-mcp-rig.mp4"><img src="docs/media/spine-mcp-rig.webp" alt="From a PSD: layers into a Spine project checked against the art, then a starting rig posed by Spine" width="100%"></a><br><b>From a PSD.</b> 13 layers into a Spine project (Spine's render matches the PSD, 0.99), an art check, then a starting rig: 18 bones, 13 meshes, 4 IK chains, posed by Spine.</td>
    <td width="50%" valign="top"><a href="docs/media/spine-mcp-animate.mp4"><img src="docs/media/spine-mcp-animate.webp" alt="Animation from the rig: walk, run, turn, hop-squash, breathe, look, follow-through and blocking to spline, rendered by Spine" width="100%"></a><br><b>Animation from the rig.</b> Walk and run through the rig's leg IK, a 2.5D head turn, squash and stretch, breathing, a look, follow-through, blocking to spline. Each one written and verified.</td>
  </tr>
  <tr>
    <td width="50%" valign="top"><a href="docs/media/spine-mcp-derive.mp4"><img src="docs/media/spine-mcp-derive.webp" alt="Variants: a mirrored wave, a bigger slower hop with its numbers, overlap and baked physics" width="100%"></a><br><b>Variants.</b> A mirrored wave, a bigger and slower hop measured in numbers, overlap, physics baked into keys. The originals stay untouched.</td>
    <td width="50%" valign="top"><a href="docs/media/spine-mcp-review.mp4"><img src="docs/media/spine-mcp-review.webp" alt="Review: onion skin, arcs and curves, a review cut, transition pops, the budget and timing from a reference video" width="100%"></a><br><b>Review like a lead.</b> Onion skin, arcs and curves, a labelled review cut, transition pops, the draw budget, and timing read from a reference video (1.21× slower, found).</td>
  </tr>
  <tr>
    <td width="50%" valign="top"><a href="docs/media/spine-mcp-safety.mp4"><img src="docs/media/spine-mcp-safety.webp" alt="Safe writes: a refused write, a verified write, the step log and the Spine version conformance suite" width="100%"></a><br><b>Safe writes.</b> A bad key refused before Spine sees it, a good one backed up and verified, the step log for picking up later, and every Spine release checked by 24 probes.</td>
    <td width="50%" valign="top"><a href="docs/media/spine-mcp-ship.mp4"><img src="docs/media/spine-mcp-ship.webp" alt="Ship: a mobile export with its atlas report, Unity and spine-webgl renders next to Spine's" width="100%"></a><br><b>Ship it.</b> A mobile export with its atlas report, then Unity (built-in and URP) and spine-webgl next to Spine's own render, every bone within 0.0001 units.</td>
  </tr>
  <tr>
    <td width="50%" valign="top"><a href="docs/media/spine-mcp-faces.mp4"><img src="docs/media/spine-mcp-faces.webp" alt="Faces: a blink generated from the artist's own shut pose next to the artist's blink, blinks placed over head moves, eye darts" width="100%"></a><br><b>Faces.</b> A blink built from the artist's own shut pose (10 lid and brow bones, eyes hidden while shut), blinks placed where the head moves, eye darts that stay in range.</td>
    <td width="50%" valign="top"><a href="docs/media/spine-mcp-game.mp4"><img src="docs/media/spine-mcp-game.webp" alt="In the game: an Animator transition popping in Unity and fixed, layered tracks and a UI render in Unity, texture memory per packing" width="100%"></a><br><b>In the game.</b> An Animator transition that pops in Unity (38.8 units in one frame) and the keys that fix it, layered tracks and a UI render checked in Unity, 1 draw call, texture memory per packing.</td>
  </tr>
  <tr>
    <td width="50%" valign="top"><a href="docs/media/spine-mcp-parts.mp4"><img src="docs/media/spine-mcp-parts.webp" alt="Painted parts: a folder of PNGs and a layout placed on the painting, a bad cut caught, two characters rigged and breathing" width="100%"></a><br><b>Painted parts.</b> No PSD: a folder of PNGs and a layout, checked against the painting they were cut from. A slipped part and stray pixels are caught, then two characters get one rig and an idle.</td>
    <td width="50%" valign="top"><a href="docs/media/spine-mcp-production.mp4"><img src="docs/media/spine-mcp-production.webp" alt="Production files: a file Spine would refuse fixed on the way in, a bake cleaned from 183 keys to 12, a team profile's rules reported" width="100%"></a><br><b>Production files.</b> A file another tool wrote, which Spine's import would refuse, fixed on the way in. A bake cleaned from 183 keys to 12 on whole frames. A team's rules checked on every export.</td>
  </tr>
</table>

## Why

Animators spend hours on work that is precise but not creative: checking loops, offsetting overlap bone by bone, mirroring a gesture, baking physics, re-exporting at three scales, hunting the key Spine dropped without a word. spine-mcp gives an agent such as Claude Code the tools to do that work **with numbers and pictures instead of guesses**, while the artistic decisions stay with you: every edit is a new animation under a new name, and nothing is written without a backup and a verified re-export. Around that core it covers the rest of the pipeline a 2D animator touches: a PSD into a project or a starting rig, new art into an existing project, walk and run cycles, idle layers and lip sync, review cuts and frame-by-frame video checks, and the hand-off into Unity.

<picture>
  <source media="(prefers-color-scheme: dark)" srcset="docs/media/flow-dark.svg">
  <img src="docs/media/flow-light.svg" alt="AI agent → spine-mcp → Spine CLI, Spine JSON, spine-core, Unity → your .spine project" width="100%">
</picture>

## What it can do

<picture>
  <source media="(prefers-color-scheme: dark)" srcset="docs/media/pillars-dark.svg">
  <img src="docs/media/pillars-light.svg" alt="Start from a PSD, check, see and review, edit and ship safely" width="100%">
</picture>

| | |
| --- | --- |
| **Understand a project** | Project summary straight from the CLI, a change-aware JSON export cache, structure, raw sections or the exact keys of one animation. **Pick up where you left off**: an instant status (no CLI call) with the last steps spine-mcp took on the project and whether the file changed since. |
| **Catch problems** | Keys Spine drops on import without a warning (missing bones, slots, attachments, constraints, events), bad mesh and weight indices, loop seams and single-frame pops, **transition pops** played through AnimationState like a game, a **performance budget** in the terms of Spine's Metrics view, **rig QA** (names, unused parts, weights, missing images, weights that fold when a bone turns, joints that open), **mesh folds** and **joints opening** inside animations, **skin combinations** and a **folder audit** for CI. |
| **Measure motion** | Per bone: rotation range, extent, angular speed, holds, seam step. Per animation: key poses, pose intervals, the ease of every segment. A/B comparisons in numbers and pictures. |
| **Start from a PSD** | A layered PSD (an artist's file or an automatic decomposition), or a folder of PNG parts with a layout (See-through, a cut-and-fill tool), becomes a new Spine project: every layer placed, draw order kept, bones from groups, PhotoshopToSpine tags read, masks baked, checked against the PSD, with an **art check** (joints that will open a gap, covered parts, specks, oversized art). Or a **starting rig**: suggested joints, meshes traced from the art, smooth weights at knees and elbows, IK, checked in test poses. |
| **Animate from the rig** | **Walk and run cycles** (feet planted through stance, IK every frame or your rig's own leg and arm IK, footstep events; a front view for characters drawn facing the camera), **blocking from poses** (a pose library sampled from your animations) and a **spline pass** that never overshoots, **breathing idles, look-ats, follow-through**, **faces**: blinks with lids sliding to your shut pose and lashes hidden, placed over an idle's pose changes the way animators hide them, eye darts with a drift, (spine-core's physics baked onto bones that have none), **lip sync** from a dialogue file (phonemes with Rhubarb Lip Sync, or loudness), a **2.5D head turn** and **volume-preserving squash and stretch** by mesh deform (bones on the deformed parts, such as an antenna or the shoulders, move with them). |
| **Edit animations** | Built on the server, so large animations never pass through the chat: scale, retime, overlap and follow-through with exact bezier splits, loop fixes, easing, slot colors / attachments / mesh deform, a world-space **mirror** (deform included), leg swaps, **repeat**, **physics baked into keys**, event keys at detected foot contacts. |
| **Take in foreign files** | JSON written by another tool or an older version: weight order, stretched regions, 4.2 constraints, clips and key hygiene are reported, and fixed on the way in. |
| **Keep keys clean** | Generators key on whole frames with fitted bezier curves and round values. The `clean` operation does the same for baked timelines and reports the drift: a production intro went from 1,553 keys to 949 with bones within 1.6 units. |
| **Team rules** | One `SPINE_MCP_PROFILE` JSON holds default arguments, atlas limits, Unity texture and SkeletonGraphic settings and sprite slices. Unity checks can run on the exact spine-unity commit a game has locked. |
| **Edit the rig, in a new file** | Bones, setup pose, IK and physics constraints, events, skins, removing a constraint: written into a new `.spine` with a report of everything Spine's JSON round trip changed. The original is never touched. |
| **Move animations** | To another character or project by name (exact, mapped, case/separator-insensitive), with optional size retargeting and a report of every key that could not move. |
| **Guard art re-imports** | Snapshot first, then see what the re-import broke (lost or silently hidden keys, wiped weights, meshes turned into regions), what changed, and where each animation now plays differently. Or skip the re-import: **new PSD art goes straight into the image files**, cut to the frames the project already draws them in, with the art each mesh would cut off reported before anything is written. |
| **Ship and verify** | Runtime export (JSON / binary + atlas at several scales) for a target (mobile, desktop, web presets, one atlas per skin, atlas fill and texture memory) checked in spine-core; then imported with **spine-unity in a headless Unity** (built-in or URP, Gamma or Linear) and rendered there and with **spine-webgl in headless Chrome**, compared bone by bone and picture by picture with Spine's own render, the atlas measured under **ASTC and ETC2 device compression**, and the **CPU and garbage per skeleton** measured in a headless player, with and without spine-unity's threaded update, and a UI fade through a **CanvasGroup** checked against the right blend. **Into your Unity project** as a SkeletonAnimation, UI SkeletonGraphic or SkeletonMecanim prefab with the mix durations you validated. |
| **Show it** | Spine's own renderer, contact sheets the agent can look at (cached while nothing changed), and labelled WebP / GIF / MP4 showcases in one call. |
| **Review like a lead** | A review cut (real time, then half speed, every frame labelled, audio under the real-time pass), onion skin, arcs with a dot per frame (the spacing chart) and value curves with keys marked, timing read from a **reference video** and compared with your animation, and **frame-by-frame inspection of any video** (showreels, breakdowns, captures). |
| **Stay safe** | Dry-run by default, sha256 backups, animation-only imports, re-export comparison, automatic rollback, one write per project at a time, a step log per project, restore anything. **Works with the editor open**: writes then go to a verified side copy you bring in with Import Project. **Checked on every Spine release**: a conformance suite re-runs the CLI behaviour the write path relies on. |

All 38 tools with what each one does and writes: [Reference › Tools](docs/REFERENCE.md#tools).

## Highlights

Real outputs from the server, on Bolt (the demo character in [`demo/bolt`](demo/bolt), art and rig made for this repository) and on Esoteric's example characters. Each one in full, with its numbers: [Reference › In depth](docs/REFERENCE.md#in-depth).

<p align="center"><img src="docs/media/bolt-showcase.webp" width="640" alt="Bolt idle, wave and hop side by side, made with spine_showcase"></p>

### Edit, then prove it

> **You:** Make Bolt's hop bigger and 20% slower, with the arms lagging a bit. Dry-run first. … Looks good, apply it.

```jsonc
// spine_derive_animation: scaleValues 1.35 (rotate), retime 1.2, offsetBones upper-arm(s) 0.06 s
→ { "mode": "applied", "backup": { "id": "2026-11-06T09-47-50-939Z" },
    "verification": { "animationMatches": true, "otherAnimationsUnchanged": true, "structureUnchanged": true, "differences": [] } }
```

| `hop` | `hop-big`, written by spine-mcp | |
|:---:|:---:|---|
| <img src="docs/media/bolt-hop.gif" width="200" /> | <img src="docs/media/bolt-hop-big.gif" width="200" /> | upper-arm range 67.0° → 92.0°<br>duration 1.00 s → 1.27 s<br>key poses 5 → 10 |

### Animation from the rig

Walk and run through the rig's own leg IK, a 2.5D head turn, squash and stretch, breathing, a look, follow-through and blocking to spline, each written into the project and verified. Watching them frame by frame found bugs a test now measures (arms held still by IK, crossed legs on a front-facing walk).

<p align="center"><img src="docs/media/bolt-generated.png" width="100%" alt="Eight generated animations rendered by Spine: walk, run, turn, hop-squash, breathe, look, look-follow and blocking-spline"></p>

### Mirror in world space, deform included

Every bone lands exactly on its partner's mirror image (checked frame by frame in spine-core); mesh deform follows vertex by vertex. The owl's `left` look, mirrored by spine-mcp (middle), next to the artist's own `right`:

<img src="docs/media/examples/owl-left-mirrored-right.png" width="100%" alt="Owl: left, left mirrored by spine-mcp, right" />

### Physics baked into keys

Spine does not bake physics. `bakePhysics` simulates like a game, writes the result as keys, closes the loop and checks itself against the live simulation: worst difference 0.05 units on Bolt's hop, as bezier keys on whole frames.

### Faces

A blink built from the artist's own shut pose (10 lid and brow bones), placed where the head moves the way animators hide a pose change, eye darts that stay inside a clamped look range; and a face audit for animations already made.

<p align="center"><img src="docs/media/face-blinks.png" width="100%" alt="Close-ups: the artist's blink, a blink generated from the artist's shut pose (open, closing, shut, opening), and eye darts"></p>

### Checked in the game

Exports are imported with spine-unity in a headless Unity and with spine-webgl in headless Chrome, then compared bone by bone (within 0.0001 units) and frame by frame with Spine's own render. Animator transitions are played the way SkeletonMecanim plays them: on Bolt, hop → idle snaps the antenna 38.8 units in one frame, and `setupKeys` adds the keys that fix it.

<p align="center"><img src="docs/media/bolt-unity-vs-spine.png" width="560" alt="Bolt: Spine's render, Unity's render and their difference" /></p>
<p align="center"><img src="docs/media/mecanim-transition.png" width="680" alt="Antenna tip height through a 0.25 s transition: SkeletonMecanim in Unity drops and jumps 38.8 units at the end; after setupKeys it follows AnimationState"></p>

### Review like a lead

Onion skin, arcs with a dot per frame and value curves with the numbers behind them; timing read from a reference video (it finds a 1.21× speed ratio and lines up 6 peaks within a frame); any video gone through frame by frame.

<p align="center"><img src="docs/media/bolt-motion.png" width="680" alt="Bolt hop: onion skin and arcs with a dot per frame, and rotation curves with keys marked"></p>

### From a PSD to a rig

13 layers into a Spine project whose render matches the PSD (overlap 0.99), an art check, then a starting rig: suggested joints, traced meshes, smooth weights, IK, posed by Spine in two test poses.

<p align="center"><img src="docs/media/bolt-auto-rig.png" width="680" alt="Left: suggested bones drawn over Bolt's parts; then Spine's render of the new rig in its setup pose and in two test poses with knees, elbows and the neck bent"></p>

### This logo is a Spine rig

<table>
  <tr>
    <td width="40%" align="center"><img src="docs/media/logo-animated.webp" width="260" alt="The spine-mcp logo animating in Spine: bones grow along the S, joints pop, the plug clicks in"></td>
    <td>

A 13-bone skeleton generated by [`demo/logo/build.mjs`](demo/logo/build.mjs) from the same parametric art as [`logo.svg`](docs/media/logo.svg), so its last frame is the logo, pixel for pixel. The idle's overlap down the chain was added with spine-mcp's own `offsetBones`. Rendered by Spine.

</td>
  </tr>
</table>

## Use cases

Where it saves the most time, and what to ask.

| Use case | Ask something like | What you get |
| --- | --- | --- |
| **Delivery check** before a character goes to the game | *"Check hero.spine before I ship it: our transitions are idle→run→jump, mix 0.2 s, mobile budget 1 draw call."* | Dropped keys and seams, popping transitions with causes, the performance budget, a verified export and a Unity / web render comparison, in one report. |
| **Polish pass** on existing animations | *"Add follow-through to the tail in walk and ease the landing in jump. Show me before and after."* | New animations next to the originals, A/B numbers and a side-by-side render to approve. |
| **Variants** without redoing work | *"Make a 20% faster, bigger hop; mirror wave for the other arm; make idle a 2-cycle loop."* | `hop-big`, `wave-mirrored`, … written and verified, originals untouched. |
| **A walk or run from the rig** | *"Give the robot an in-place walk and a run, through its leg IK, with footstep events. It faces the camera."* | Planted feet through stance, hip bob and arm swing, the rig's own leg and arm IK targets keyed, a `footstep` event at each contact; facing the camera, a march in place with foreshortened legs; then a render to judge. |
| **Safe art updates** | *"Snapshot it, I'm re-importing the PSD."* … *"What broke?"* | Lost or hidden keys, wiped weights, meshes turned into regions, and which animations now look different. |
| **Engine handoff** | *"Put the hero into my Unity project with idle as the start animation and the mixes we checked; then make sure it looks the same there."* | The SkeletonDataAsset, a SkeletonAnimation prefab and the mix durations in your project, verified bone by bone; later art updates replace the data in place (scenes stay linked). Plus a render comparison that catches premultiplied-alpha mistakes. |
| **Matching a reference** | *"Here is the capture of the attack I'm matching; crop to the character and compare my attack."* | Motion peaks, holds and cuts of the reference as a frame table and contact sheet, and how your timing differs: speed ratio, start offset, frames per accent. |
| **Picking up the next day** | *"Where were we on hero.spine?"* | The last steps spine-mcp took (written, staged, rolled back, restored), whether the project was saved in the editor since, backups and what still waits in the staging copy, instantly. |

24 use cases with tips: [Reference › Use cases](docs/REFERENCE.md#use-cases) · step-by-step recipes: [USAGE](docs/USAGE.md#workflows).

**Not the right tool for:** production rigging of an existing character, or the first creative pass on an acting shot. Those stay with you in the editor; spine-mcp checks, measures, varies and ships what you made.

## How a write stays safe

```mermaid
flowchart LR
  A[validate the new animation<br/>missing refs block it] --> V{older Spine<br/>major.minor?}
  V -- "yes, no allowUpgrade" --> X[refuse]
  V -- no --> B{project changed<br/>since read?}
  B -- yes --> X
  B -- no --> C[sha256-verified backup]
  C --> D["Spine CLI: -a NAME --to SKELETON -r<br/>(animation-only import)"]
  D --> E[re-export + compare<br/>timelines / behaviour]
  E -- any warning or mismatch --> R[restore backup]
  E -- identical --> OK[applied]
  OK --> L[step log<br/>spine_status]
```

With a Spine editor window open, the same steps run on a staging copy instead of the project ([how](docs/REFERENCE.md#with-the-editor-open)).

- Only animation import is used: a full JSON re-import would drop editor-only data, `-a` changes nothing else ([research](research/phase0/RESULTS.md)).
- Spine exits with code 0 even when it drops keys; spine-mcp treats every such warning as a failure. One case prints nothing at all: a key to an attachment the animation's own skeleton does not have becomes a silent "hide" key (G91), so the validator refuses it before the CLI is called.
- One write per project at a time. The `.spine` binary is never parsed or patched.
- Each Spine call starts Spine headless (about 3 s) and exits; reads come from an export cache while the project is unchanged.

Also: [writes with the editor open](docs/REFERENCE.md#with-the-editor-open), [a step log to pick up where you left off](docs/REFERENCE.md#where-you-left-off), and [every Spine release checked by 24 probes](docs/REFERENCE.md#every-spine-release-checked).

## Tested

| | |
|---|---|
| **535 tests** | 445 unit (every derive operation against spine-core frame by frame, generators measured, rollback paths, platform layer), 71 against the real Spine 4.3.26 CLI, 19 in a headless Unity with spine-unity; on Windows with Spine and Unity all pass except two mesh-fit checks that fail there on 0.56.0 too ([STATUS](docs/dev/STATUS.md)) |
| **Every tool, end to end** | All 38 tools through the real MCP server over stdio, 75 calls on copies of Bolt and spineboy, writes and restores included |
| **36 official projects** | A full sweep over 213 animations: export, validation, derive invariants, physics bake accuracy, rig QA, a real write + verify + restore and a render per project |
| **Every Spine release** | 24 probes of the CLI behaviour the write path relies on, against a saved baseline |
| **CI** | macOS, Linux and Windows, including a non-ASCII folder |

What each suite covers and how to run it: [Reference › Tested](docs/REFERENCE.md#tested).

## Quick start

Requirements: macOS or Windows, Node 22+ and your own [Spine 4.3 Professional license](https://esotericsoftware.com/spine-purchase) (spine-mcp does not include Spine; reading an exported JSON works without it). Optional: Unity Hub, Google Chrome, ImageMagick, ffmpeg, [Rhubarb Lip Sync](https://github.com/DanielSWolf/rhubarb-lip-sync) (which tool needs which: [Reference › Setup](docs/REFERENCE.md#setup)).

```bash
git clone https://github.com/berkanisk/spine-mcp.git && cd spine-mcp
npm install
npm run build
claude mcp add --scope user spine -- "$(command -v node)" "$PWD/dist/index.js"
```

Use a stable absolute `node` path (with fnm: `~/.local/share/fnm/aliases/default/bin/node`). Any other MCP client takes the same command:

```json
{ "mcpServers": { "spine": { "command": "/absolute/path/to/node", "args": ["/absolute/path/to/spine-mcp/dist/index.js"] } } }
```

Then, in a new session:

> Inspect `/absolute/path/to/spine-mcp/demo/bolt/bolt.spine` and show me `wave`.

Windows (PowerShell), environment overrides and optional tools: [Reference › Setup](docs/REFERENCE.md#setup).

## Limits

- **Existing rigs are never rewritten in place**: rig edits go into a new file; meshes and weights of an existing rig stay with the editor.
- **No live editor link**: with Spine open, writes go to a verified side copy you bring in with Import Project.
- **Spine Professional is needed** for everything that calls the CLI; reading an exported JSON works without it.
- **Generated motion is a starting point**: it reads the rig and is measured, but knows nothing about the character's intent.
- **Field testing** on artist PSDs, real dialogue and real game captures is still to come. Windows with a licensed Spine and Unity is field tested (research/06: all 7 checks), and so are See-through PSDs and a game's own `.skel.bytes`.

All of them, with what was verified: [Reference › Limits](docs/REFERENCE.md#limits) · [Roadmap](docs/REFERENCE.md#roadmap).

## Docs

- [Reference](docs/REFERENCE.md): every tool, use cases, each area in depth, safety, setup, tests, limits
- [Usage](docs/USAGE.md): prompts, every tool parameter, derive operations, workflows
- [Architecture](docs/ARCHITECTURE.md): modules and the write path
- [Changelog](CHANGELOG.md)
- [Working notes](docs/dev/): status, backlog, decisions, verified Spine pitfalls and a one-page summary (mostly Turkish)
- [Research](research/): survey of 16 existing Spine MCP repos, Phase 0 experiments, [audit](research/02-audit-2026-10-17.md), [capability and gap analysis](research/03-capability-gap-analysis.md) against Spine users' reported problems (Turkish)

## Contributing

Issues and pull requests are welcome: see [CONTRIBUTING.md](CONTRIBUTING.md). Security reports: [SECURITY.md](SECURITY.md).

## License

The code is under the [MIT license](LICENSE). That does not cover Spine or Esoteric's art:

- **You need your own [Spine license](https://esotericsoftware.com/spine-purchase).** spine-core and spine-webgl are npm dependencies under the [Spine Runtimes License](https://esotericsoftware.com/spine-runtimes-license), which requires one for each user.
- **Raptor, owl, mix-and-match and spineboy** in the media are © Esoteric Software, redistributed with their license files, and may not be used commercially.
- Demo music is by Sascha Ende (CC BY 4.0) and UI sounds are by Kenney (CC0).

Details: [THIRD_PARTY_NOTICES.md](THIRD_PARTY_NOTICES.md). Bolt and the logo rig were made for this repository. Videos made with [HyperFrames](https://hyperframes.heygen.com).

Spine is a product of Esoteric Software. This project is independent and not affiliated with or endorsed by Esoteric Software.