AI Powered Animation
Unity CLI Unity 6.0+ recommended
Unity now ships a command-line tool, unity, and a companion
package (com.unity.pipeline) that lets it drive a running Editor. With that
package installed, LLM Hooks registers the same three juicebox_* operations —
read, writescene, writeshared — as CLI commands.
Unity is steering everyone here, and its CLI supersedes the MCP server described in the
next section.
Nothing to switch on per tool: installing the package is the whole setup. From the project root,
unity pipeline install # once, if the package is not already there
unity command juicebox_read # confirms the hooks are live
Any agent with a terminal can drive JuiceBox that way — no MCP client, no relay:
unity command juicebox_writescene --content '{"jbxInsertVersion":1, ...}'
To hand the same three commands to a client as MCP tools instead, let the CLI write the config:
unity mcp configure claude-code # or cursor, vscode, windsurf, codex, ...
Run unity mcp configure --list for the full client list. The CLI's MCP
server publishes one tool per command, so juicebox_read,
juicebox_writescene, and juicebox_writeshared arrive alongside
Unity's own — same names, same payloads, and the same split by reach described below. The
Setup window shows the Pipeline server's port when it is running, so you can confirm this
Editor is reachable before pointing a client at it.
Optional, and unrelated to JuiceBox: unity skill install <client>
teaches an agent the unity command surface in general. JuiceBox's own agent
instructions come from Set up agent access in the Setup window.
Unity's MCP server and AI Assistant Unity 6.0+
On Unity 6 with the AI Assistant package
(com.unity.ai.assistant), LLM Hooks registers three native
juicebox_* tools with Unity's MCP Server — read,
writescene, and writeshared. Agents connected to the Editor —
Claude Desktop, Claude Code, Cursor — call JuiceBox directly to survey,
dump, create, patch, place an animation on an object, and copy or fork one.
Unity has superseded this server with the CLI above. It is documented and supported here because it still works and plenty of projects are still on it — but if you are setting up fresh, use the Unity CLI instead. Nothing about your animations, your payloads, or the tool names changes between the two.
The two write tools are split by reach, so you decide how much to allow:
writescene only edits an open scene — and never saves it for you — while
writeshared writes shared definition assets. You can permit one without the
other.
One-time setup:
- Open Edit › Project Settings › AI › Unity MCP Server and check the bridge is running.
- In the tools list, enable the JuiceBox group — new tools start disabled, so this one-time step switches them on.
- Under Integrations, click Configure next to your
client. If your client asks you to point at the server yourself, use Unity's relay
executable in
~/.unity/relay/(Unity fills this in for you when it writes the client's config). Then restart the client. - Back in Unity, approve the pending connection when it appears. Approval is remembered.
Unity writes the connection into your client's own MCP config — for Claude, an
mcpServers.unity entry in ~/.claude.json that points at the relay
executable. It lives outside your Unity project, and you can remove that entry to
disconnect.
Unity's built-in Assistant (the chat inside the Editor) reaches JuiceBox too: it reads the shipped contracts and drives the same safeguarded operations through its command path. Everything below about tokens and rejection applies to it equally.
Recommended: tell the Assistant about JuiceBox up front via its
custom instructions (Project Settings › AI › Assistant, the
Custom Instructions box). The Setup window's first section has a one-line pointer that
tells the Assistant to drive animation work through the JbxOps functions and
points it at the shipped contracts (JBX-CONTRACT.md /
JBXPATCH-CONTRACT.md) for the full schema. Custom instructions are your
project's single slot — the pointer is
meant to sit alongside whatever else you keep there. Copy to clipboard
lets you paste it in yourself; Add for me appends it to your assigned
instructions file (or creates and assigns one only if the slot is empty — it never
replaces what you have).
The native tools need Unity 6.0+, the AI package, and a Unity Cloud project link. The in-editor Assistant panel (the chat) also requires a Unity AI subscription. On earlier Unity versions — or with no AI setup at all — the paths below do the same work.
Coding agents in your project folder Any Unity
For agents that work in your repository — Claude Code, Cursor, Codex,
Copilot — open Tools › JuiceBox › LLM Hooks › Setup… and click
Set up agent access. It writes
AGENTS.md and CLAUDE.md into your project root, plus a
self-contained skill package, so your agent discovers JuiceBox on its own. Existing files
are never overwritten — a JuiceBox section is appended once.
"Give the coin a bouncy pickup animation."
The agent reads AGENTS.md, learns the format, and does the rest.
The file bridge Fallback
The backup path: a watched folder. Anything that can write a file can drive JuiceBox through it — useful for agents with no Editor connection, CI, or unusual setups. It is off until you create its folders; if you are using the paths above, you never need this.
To turn it on, open Tools › JuiceBox › LLM Hooks › Setup… and click Set up file bridge. That creates:
YourProject/
Assets/
JuiceBoxAgent/
in/ <- work goes here
out/ <- answers appear here
in/processed/ <- inputs are archived here after they run
Drop a .jbx (create), .jbxpatch (modify),
.jbxinsert (place on a scene object), or .jbxownership (copy,
fork, or extract) into in/; Unity picks it up within a second — or the next time
the Editor regains focus — applies it, and writes the verdict to
out/<name>.report.json. After a successful change the asset is re-dumped
automatically; that is what an agent reads before its next edit.
Because an agent writes directly to your animation assets, keep your project under
source control (Git or similar) so any change is easy to review and roll
back. The JuiceBoxAgent/ folder itself is machine traffic, not project
content — setup drops a .gitignore in it so it stays out of your commits.
It will not clobber your work
Every change is all-or-nothing. A patch either applies completely, or the asset is left byte-identical.
Each patch carries tokens describing the exact state it was written against. If you edited the animation in the meantime — even a sequence the patch never mentions — it is refused rather than applied over the top of you.
Ctrl+Z reverts an applied patch. And the file watcher runs only if you created its folders; the native tools run only if you enabled them.
When a patch is rejected
A rejection is the system working. The usual cause is that the animation changed after the agent last read it. The fix is always the same: re-read, then re-write — the agent takes a fresh dump and authors the patch again. Never hand-edit a token to make a patch apply; the token is the only thing standing between an agent and your work.
The Setup window
Everything lives behind one menu item — Tools › JuiceBox › LLM Hooks › Setup… — which opens a window holding the paths above plus a quick check. It also opens by itself the first time you load a project with LLM Hooks installed.
| In the window | Does |
|---|---|
| Unity CLI | Reports whether the Pipeline server is running and on which port, so you can confirm this Editor is reachable (Unity 6+). |
| Unity MCP server & Assistant | Opens Project Settings › AI so you can enable the JuiceBox tools and configure a client (Unity 6+). |
| Set up agent access | Writes the discovery docs and skill package for coding agents. The window flags when they are missing or out of date and offers to refresh them. |
| Set up file bridge | Creates the watched JuiceBoxAgent/
folders, then lets you toggle the watcher on or off. |
| List animations in this project | Confirms the hooks are live by listing your JuiceBox definitions. |
What it can and cannot do
Agents can create sequences and effects, retune them, reorder them, wire combiners, and link one sequence's output to another's input — everything the graph exposes. That covers definition assets and animations embedded directly on a component alike: agents survey the open scenes, address an embedded animation by its object id or hierarchy path, and edit it in place.
They can also place an animation onto a GameObject that doesn't have one yet — linking a shared definition or embedding its own copy — and make ownership moves: copy an animation onto another object, extract an embedded one into a new shared definition, or make an instance unique to fork it off the definition it shared. (Creating the GameObject itself stays Unity's job; the agent only adds the animation.)
Two behaviors worth knowing. If a component uses a shared definition, edits are pointed at the definition asset — so every instance follows. A read reports how many objects share a definition, and editing a shared one warns you; to give a single instance its own variant, an agent forks it first (make unique, or copy) and edits the fork. And when a scene animation is edited or placed, the scene is marked dirty exactly like a hand edit — you see the usual unsaved star and save with Ctrl+S (or undo, or discard). JuiceBox never saves the scene for you.
Three honest limits.
Scenes are never opened behind your back. Anything that touches a scene object — reading or editing an animation embedded on a component, or placing or copying one onto an object — needs that object's scene already open; an address into an unopened scene is refused with a pointer, never loaded silently. Definition assets carry no such limit — an agent reaches them any time.
Method names bound by relative descriptors resolve against your components at runtime, so a typo in one cannot be caught at import — it surfaces when you press Play. The import report flags every such binding so you know which ones are unverified.
Pieces nothing is attached to are tidied away when the graph next opens. A runtime parameter no effect reads, or a combiner no sequence feeds into, does nothing when the animation plays, so reopening that animation in the graph editor drops it rather than drawing a node with nothing on the other end. Your editing session is left alone, and so is an agent's patch — a parameter can be declared in one step and wired up in the next. It is only the trip through the graph window that clears the ones still left unattached.
