Which integrations are available for this server?

Generates Spine 4.2 rigs and procedural animations (idle, walk, run, jump, attack, hit) from PSD files, producing .json skeleton files ready for the Spine editor. Produces Unity-ready .json, .atlas, and .png files with import instructions for spine-unity, enabling use of generated animations in Unity projects.

How do I use spine-anim-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@spine-anim-mcp convert character.psd to Spine rig with idle and walk animations" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

spine-anim-mcp

by K-ulucay

Overview Schema Related Servers Score Discussions

Python

Local

spine-anim-mcp

An MCP server that turns a layered PSD character into a Spine 4.2 rig and generates deterministic, parametric 2D/2.5D animations — idle, walk, run, jump, attack, hit — ready for the Spine editor and Unity.

Most PSD→Spine tools stop at rigging — they hand you a skeleton and leave the animation to you. This one generates the animations too, with pure math: same parameters in → byte-identical output. Reproducible, diffable, no broken AI-guessed poses.

PSD ──▶ rig (bones + slots + atlas) ──▶ procedural animations ──▶ .json + .atlas + .png

Why deterministic instead of AI?

Generative pose prediction produces anatomically broken results that cost more time to fix than to author by hand. Every animation here is a sampled mathematical function — a walk cycle is antiphase leg sines with opposing arm swing and a 2× vertical bob, not a guess. The trade-off is explicit: this tool owns locomotion and combat basics; expressive one-off animation stays in the Spine editor where an artist's eye belongs.

Related MCP server: aseprite-mcp

Features

PSD → joint-correct rig. Layers named after body parts (head, torso, arm_left, leg_right, …) become a topologically-ordered Spine 4.2 skeleton with anatomical pivots (upper-arm rotates at the shoulder, not the image center).
Six procedural generators, each fully parametric (see table below).
Loop-correct cycles. idle/walk/run are authored so frame 0 == frame N — seamless Spine looping, no popping.
Validated before write. Structural invariants the runtime reader assumes (single root, topological bone order, resolvable references, monotonic keyframe times) are checked at generation time, so failures are clear errors instead of silent import breakage.
Idempotent output. Identical inputs overwrite with byte-identical content and touch no other file in the output directory.
Unity-ready. Emits .json + .atlas + .png; full import guide in docs/UNITY.md.

Validation status

Phase 1 — implemented and validated end-to-end on two PSDs: a synthetic stick rig (examples/hero) and a real stylized 2D character (examples/adventurer) — a shaded adventurer with tunic, pants, and boots, split into 17 convention-named layers.

Real character, posed by the procedural engine

Live animations (looping GIFs), all from the same rig with no hand-keying:

Source PSD → idle → walk (static reference):

showcase

Per-animation keyframe breakdowns: examples/adventurer/walk_cycle.png, attack_sequence.png, jump_sequence.png.

Testing against a real character surfaced — and fixed — several issues that flat rectangles hid: limb parts must overlap at joints to avoid gaps when bent; a bone-hierarchy bug had the foot parented to the upper leg instead of the shin, so it tracked the wrong segment and detached when the knee bent; and the walk now uses 2-bone analytic IK foot-lock — the ankle is placed on a plant/swing path (planted on the ground through stance, arcing forward in swing) and the leg is solved to reach it. Because the foot is the IK target, it stays locked to the shin through the entire stride. No detachment.

Recommended before shipping art: open the generated .json in the actual Spine 4.2 editor and import into spine-unity to confirm against the real runtime. The headless renderer (examples/render_posed.py) solves forward kinematics independently — useful, but it is not the Spine runtime itself.

Animation catalog

Type	Loops	Method	Key parameters (defaults)
`idle`	✓	sine breathing on chest/torso, half-freq head sway, arm drift	`duration` 2.0, `breath_amp` 2.0, `sway_amp` 1.0
`walk`	✓	antiphase leg sine, opposing arm swing, 2× bob, torso counter-rotate	`duration` 1.0, `stride` 28, `arm_swing` 22, `bob` 3
`run`	✓	walk with larger amplitudes + constant forward lean	`duration` 0.6, `stride` 45, `arm_swing` 40, `bob` 7, `lean` 8
`jump`	✗	crouch → launch → apex → land → settle pose keys, eased	`duration` 0.9, `crouch` 18, `rise` 40
`attack`	✗	windup → stepped strike → follow-through; `hand` picks arm	`duration` 0.5, `windup` 35, `swing` 80, `hand` "right"
`hit`	✗	sharp recoil on root/torso/head then settle	`duration` 0.35, `knockback` 14

Generators are rig-agnostic within the humanoid convention: a 4-bone stick figure and an 18-bone character both animate; roles the rig lacks are silently skipped.

Install

git clone https://github.com/K-ulucay/spine_anim_mcp.git
cd spine-anim-mcp
pip install -e .          # pulls mcp, pydantic, Pillow, psd-tools

Requires Python 3.11+.

Run the tests

python3 tests/test_pipeline.py

Run the MCP server

spine-anim-mcp            # or: python -m spine_anim_mcp.server

Then point an MCP client (Claude Desktop / Claude Code) at it.

Quickstart

Given hero.psd with layers named head, neck, chest, torso, hip, arm_upper_left, arm_lower_left, leg_upper_right, … ask your MCP client to call:

import_psd_to_spine(
  psd_path = "hero.psd",
  animations = [
    { "type": "idle" },
    { "type": "walk", "params": { "stride": 34, "bob": 4 } },
    { "type": "run" },
    { "type": "attack", "name": "slash", "params": { "hand": "left", "swing": 95 } }
  ]
)

Output (in hero_spine/):

hero.json     # skeleton + idle, walk, run, slash animations
hero.atlas    # texture atlas
hero.png      # packed atlas page

Import into Unity per docs/UNITY.md (note: rename hero.atlas → hero.atlas.txt, spine-unity requires the .txt extension).

MCP tools

Tool	Purpose
`import_psd_to_spine(psd_path, animations?, out_dir?, name?)`	Full pipeline: PSD → rig + animations → files. Defaults to `idle` + `walk`.
`animate_existing(skeleton_json_path, animations, out_dir?)`	Add animations to an existing Spine skeleton (bones auto-mapped by name).
`list_animation_types()`	List available generators.
`describe_animation_type(type)`	Tunable parameters + defaults for one type.

animations is a list of { type, name?, params? }. type selects the generator; optional name renames the produced animation; params overrides defaults from the catalog above.

Layer naming

Layer names are matched to roles flexibly (lowercased, separators normalised), so Left Arm, arm_l, upperarm.L, and arm_upper_left all resolve to the same role.

Region	Roles
Spine	`root`, `hip`, `torso`, `chest`, `neck`, `head`
Left arm	`arm_upper_left`, `arm_lower_left`, `hand_left`
Right arm	`arm_upper_right`, `arm_lower_right`, `hand_right`
Left leg	`leg_upper_left`, `leg_lower_left`, `foot_left`
Right leg	`leg_upper_right`, `leg_lower_right`, `foot_right`

Full alias table: src/spine_anim_mcp/psd/conventions.py.

Project layout

src/spine_anim_mcp/
  server.py            FastMCP server + tool definitions
  pipeline.py          orchestration; idempotent file writes
  psd/parser.py        PSD -> flat part list (+ spec fallback for tests)
  psd/conventions.py   hierarchy, name->role aliases, pivot fractions
  spine/schema.py      Pydantic models = source of truth for Spine 4.2 JSON
  spine/builder.py     parts -> bones/slots/attachments (world->local transform)
  spine/writer.py      JSON serialiser + structural validator
  anim/generators.py   the procedural animation engine
  atlas/writer.py      shelf packer -> .atlas text + composite PNG
docs/
  SPECIFICATION.md     architecture, Spine 4.2 contract, animation math, roadmap
  UNITY.md             spine-unity 4.2 import + scripting guide
tests/
  test_pipeline.py     end-to-end test on a synthetic 18-bone humanoid

Roadmap

Real-PSD round-trip through the pipeline with FK-verified rig (examples/hero)
2-bone IK foot-lock on walk/run (anim/ik.py) — feet stay planted
Confirm examples/adventurer/adventurer.json in the live Spine 4.2 editor + spine-unity
Extract real per-part PNG pixels into the atlas (currently bounds-only)
<part>[pivot] marker-layer support for per-part pivot overrides
Bezier easing on cyclic anims (currently linear/stepped) for snappier feel
Mesh-deform + skin-swap timelines (stronger 2.5D perspective)
Emit Spine IK constraints directly (so the editor re-solves), not just baked angles

Contributing

PRs welcome — especially:

Real-PSD test fixtures and Spine/Unity round-trip reports. This is the most valuable contribution right now.
New generators (add gen_<name>(rig, **params) to anim/generators.py, register in GENERATORS, document params in server.PARAM_DOCS).
Non-humanoid rig conventions (vehicles, creatures).

Generators must stay deterministic — no randomness, no model calls.

License

MIT — see LICENSE.

Available Tools

4 tools

animate_existingA

Add procedural animations to an EXISTING Spine 4.2 skeleton JSON.

The skeleton's bones are auto-mapped to canonical roles by name. Bones whose names already follow the role convention (head, leg_upper_left, ...) map directly; others are ignored by the generators. Returns JSON with the updated project path and the animations added.

ParametersJSON Schema

Name	Required	Description	Default
`skeleton_json_path`	Yes
`animations`	Yes
`out_dir`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must cover behavior fully. It discloses auto-mapping by name and ignored bones, but lacks details on side effects (e.g., file modification), permissions, error handling, or prerequisites for the skeleton file.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences, each adding value: purpose, mapping logic, ignored bones, return format. It is front-loaded and concise with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 3 parameters and no annotations. The description covers the skeleton mapping and return format, but leaves the animations array undefined, which is critical for usage. The presence of an output schema partially compensates for return value clarity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It clarifies skeleton_json_path as input skeleton and animations as what to add, but does not explain the structure of the animations array or the out_dir parameter. This is insufficient for a 3-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Add' and the resource 'EXISTING Spine 4.2 skeleton JSON', distinguishing it from siblings (describe_animation_type, import_psd_to_spine, list_animation_types) which cover description, import, and listing respectively.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when you have an existing skeleton and want procedural animations, and mentions that bones not following naming conventions are ignored, providing a context hint. However, it does not explicitly exclude alternatives or state when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

describe_animation_typeA

Return the tunable parameters and defaults for one animation type.

ParametersJSON Schema

Name	Required	Description	Default
`type`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description implies a read-only operation by stating it returns information, but does not explicitly declare non-destructiveness or other behavioral traits. No annotations are present to supplement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, clear sentence that front-loads the purpose with no extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple query tool with one parameter, the description is mostly sufficient. It could reference the sibling tool list_animation_types for valid inputs, but the output schema likely covers return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description associates the 'type' parameter with the animation type, but provides no details on valid values, format, or examples, leaving the agent to infer.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the tool returns tunable parameters and defaults for a single animation type, distinguishing it from sibling tools that animate, import, or list types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied by the name and description, but no explicit guidance on when to use or alternatives is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

import_psd_to_spineA

Convert a layered PSD into a Spine 4.2 project and generate animations.

psd_path: path to a .psd whose layers are named after body roles (head, torso, arm_left, leg_right, ...). animations: list of {type, name?, params?}. If omitted, generates a default set: idle + walk. Returns JSON with project_path, atlas_path, png_path, animations.

ParametersJSON Schema

Name	Required	Description	Default
`psd_path`	Yes
`animations`	No
`out_dir`	No
`name`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the return format (JSON with project_path, atlas_path, png_path, animations) and the animation parameter structure, which is useful. However, it does not mention potential side effects, permissions, error handling, or behavior for missing parameters out_dir and name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded with the core purpose. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although output schema exists, the description omits details for two of four parameters and does not cover prerequisites, output file locations, or error conditions, leaving gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds meaning for psd_path (layer naming convention) and animations (object structure and default behavior). This is valuable, but out_dir and name are left undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool converts a layered PSD into a Spine 4.2 project and generates animations, specifying the resource and expected output. This distinguishes it from siblings like animate_existing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives (siblings) is provided. The description implies its use for converting PSDs but does not state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_animation_typesA

List the procedural animation types this server can generate.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the burden. It correctly states the tool lists types (read-only) with no destructive effects, matching expectations for a list operation. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that conveys the tool's purpose without superfluous words. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and an output schema present, the description fully covers the tool's behavior. No additional context is necessary for an agent to select and invoke this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so schema coverage is 100%. The description adds no parameter info, but none is needed; a baseline of 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List') and resource ('procedural animation types'), clearly distinguishing this from siblings like 'animate_existing' (which performs animation) and 'import_psd_to_spine' (which imports data).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for discovery (listing available animation types) but does not explicitly state when to use it versus other tools like 'describe_animation_type' or provide alternative scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv0.1.0Jun 14, 2026
- First observedanimate_existing
- First observeddescribe_animation_type
- First observedimport_psd_to_spine
- First observedlist_animation_types

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: importing PSDs, listing animation types, describing parameters, and adding animations to existing skeletons. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscores (animate_existing, describe_animation_type, import_psd_to_spine, list_animation_types), making them predictable.

Tool Count5/5

With 4 tools, the server is well-scoped for its domain (Spine procedural animations). Each tool earns its place, covering essential operations without excess.

Completeness4/5

The tool set covers the core workflows: project creation, animation type discovery, parameter lookup, and application. A minor gap is the lack of an update/delete tool for animations, but the surface is sufficient for the stated purpose.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Retro Diffusion Pixel Art A
ai.retrodiffusion
Generate authentic pixel art - sprites, animations, and tilesets - from any MCP client
Image & Video Processing AI & Machine Learning
2022
Gessa: game asset generation for AI agentsOAuth
ai.gessa
Generate game-ready 3D models, textures, and audio from natural language, over MCP.
AI & Machine Learning Image & Video Processing Audio Processing
1
mcp-flux-proOAuth
io.github.AceDataCloud
MCP server for Flux AI image generation
Image & Video Processing Multimedia Processing
23
mcp-hailuoOAuth
io.github.AceDataCloud
MCP server for Hailuo (MiniMax) AI video generation
AI & Machine Learning Image & Video Processing
21

Related MCP Servers

spine-mcp
1425sd
A
license
A
quality
D
maintenance
Local MCP server for automating Spine projects via the official CLI, enabling AI tools to inspect, export, import, and add animations to .spine files.
Updated 4 months ago (2026-05-03 15:15 UTC)
16
15
11
Apache 2.0
aseprite-mcp
Image & Video Processing Multimedia Processing
ilhamdoanggg
A
license
Not graded
quality
D
maintenance
MCP server for programmatically creating and editing Aseprite sprites, enabling AI agents to draw, manage layers and frames, and iterate until the desired result is achieved.
Updated 3 months ago (2026-06-10 11:27 UTC)
MIT
spine-mcp
Games & Gamification Multimedia Processing
yb901104-wq
F
license
B
quality
C
maintenance
MCP server for reading, validating, and modifying Spine 4.1.24 JSON animation files, with tools for animation timeline editing, validation, preview, and agent integration.
Updated 3 months ago (2026-06-18 11:32 UTC)
36
-
aseprite-live-mcp
Design Tools Developer Tools Image & Video Processing
oaktreegames
A
license
Not graded
quality
A
maintenance
An MCP server that lets AI agents draw in a live Aseprite editor or headless mode, featuring one-action Unity sprite-sheet export, art-QA sweeps, and game-dev tools.
Updated a month ago (2026-07-29 02:58 UTC)
3
MIT

Appeared in Searches

A resource for skinning and rigging 3D models

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/K-ulucay/spine_anim_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server