Skip to main content
Glama

rig_serpent

Rig fish, eels, snakes, dragons, or tentacles with a traveling wave along a bone chain to generate swim, idle, turn, and reach clips for Spine animations.

Instructions

Fish, eel, snake, dragon body or tentacle: ONE long chain along the body layer with a travelling wave.

Layers by name (case-insensitive): body (required, one long layer), head + eye*/jaw/mouth (ride the first bone), fin* (2-bone strands with physics on the nearest body bone), tail_fin / fluke (strand on the last bone).

Physics: y(s,t) = A(s) sin(2 pi (s/lambda - f t)) head -> tail, amplitude growing toward the tail (head_amp = the head's share). speed (body lengths/s) sets the beat like a fish: f = speed / (0.7 lambda); the tail amplitude follows Strouhal St = 0.3 (x exaggerate) unless amp (fraction of length) is given; the head recoils sideways and thrust surges the body at 2f. Clips: swim (exact loop, cycles beats, event sfx_swim per beat), idle_float (slow hover wave + heave), turn (fish C-start: curl, tail kick, spring decay; sfx_turn). mode="tentacle": the root is the base (root_end auto = the bottom), wave 1.3 lengths, plus 2-bone reach IK on the tip and a reach clip (wind-up, constant-curvature strike on an exact spring, grab; sfx_reach). reach = [x, y] in the tentacle's frame (x along it from the base). Clips merge by name into existing ones.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ampNo
modeNoswim
nameNoserpent
sideNo
slotNo
clipsNo
reachNo
speedNo
cyclesNo
parentNo
n_bonesNo
projectYes
head_ampNo
root_endNoauto
exaggerateNo
turn_angleNo
wavelengthNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses generated clips (swim, idle_float, turn, reach), emitted events (sfx_swim/sfx_turn/sfx_reach), the exact-loop/cycles behavior, and that clips merge by name into existing ones. Remaining gaps (permissions, what project objects are created, reversibility) are not addressed but the mutation surface is unusually well described.

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

Conciseness3/5

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

It is front-loaded with the correct one-line classification, but the body leans heavily on physics exposition (the y(s,t) formula, Strouhal number, thrust surge) that is only marginally relevant to tool selection. Information density is high, but the text is a wall of unbroken prose with no parameter listing or structure.

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 complex rig tool with no annotations, no output schema, and 17 mostly-undocumented parameters, the description covers modes, clips, events, layer naming, and key physics controls adequately. It does omit the meaning of side/slot/parent and does not state what it returns or where the rig lands in the project.

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?

Schema coverage is 0% across 17 params, so the description must compensate, and it explains a large fraction: amp (fraction of length), cycles (beats), speed (body lengths/s), head_amp, root_end (auto for tentacle), exaggerate, wavelength, mode, clips, and reach ([x,y] in the tentacle frame). It leaves side, slot, parent, n_bones, turn_angle, name, and project unexplained, so it is thorough but not complete for a 17-parameter tool.

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

Purpose4/5

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

The opening line states a concrete resource and scope: 'ONE long chain along the body layer with a travelling wave' for fish/eel/snake/dragon/tentacle bodies. It clearly positions itself against the strand-based fin constructs it mentions. It stops short of naming competing siblings (rig_strand, rig_creature) to route the agent explicitly.

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 is implied through required layer naming ('body (required...)'), the mode switch, and clip names, but there is no explicit when-to-use/when-not guidance or comparison to sibling rigging tools like rig_strand or rig_creature. The agent must infer that this is the tool for a single continuous body chain.

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