Skip to main content
Glama

VNyan pendulum chains

vnyan_pendulum

Manage VNyan pendulum chains: create, delete, list, set position/rotation. Resolve output-target conflicts to prevent overlapping writers, and control spring parameters for realistic motion.

Instructions

'list' (disk, always readable) reads the pendulum chains configured in VNyan's UI (settings.json 'Chains') and reports every output target written more than once in 'sharedOutputTargets'. 'create'/'delete'/'setPosition'/'setRotation'/'chains' (plugin, live) manage a SEPARATE set of chains created at runtime via this API, addressed by the numeric handle 'create' returns - they are not the same chains as 'list' and don't persist across a VNyan restart. CRITICAL CONSTRAINT: only ONE pendulum may write a given output target directly. VNyan assigns rather than accumulates on all three output paths, so a second writer overwrites the first every frame and the motion cancels out - a routing problem no damping/elasticity tuning will fix. The granularity differs per kind: blendshapes key on NAME (and a name counts as written whether it appears as an output's 'blendshape' or its 'negative'); GameObjects key on (name, transform axis), so the same object on DIFFERENT axes does NOT clash; parameters key on name, so two outputs must never share a 'param'. To layer several pendulums on one target: clear the direct output field on each, give each output its own unique 'param', sum those in a node graph, and apply the total with a single node - ObjectRotNode for transforms (set all three axes together, it zeroes omitted ones), or for a SIGNED blendshape pair a FilterParamNode sign split into two BlendshapeNodes, since one BlendshapeNode cannot drive two different shapes. Read vnyan_guide topic:'pendulum-composition' for the verified recipe and the full field-by-field data model BEFORE changing a chain's outputs. See vnyan_guide topic:'pendulum-tuning' for the spring params.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inertNoHow rigidly the chain FOLLOWS the avatar's own movement, 0-1 (hard-clamped). Default 0. Reads backwards from the name, so mind the direction: DynamicBone integrates 'position += velocity*(1-damping) + gravity + objectMove*inert', i.e. the object's motion is ADDED to each particle in proportion to inert. 1 = the chain travels with the avatar, so moving or turning it induces NO swing; 0 = the chain ignores the avatar, so avatar motion produces MAXIMUM swing. Raise it when head movement shakes a chain that should only react to its own input value. For 'create', at runtime creation time only.
valueNoDrive value for setPosition/setRotation - setPosition makes the pendulum swing back and forth as this value changes over repeated calls; setRotation swings it to this angle and holds it there.
actionYesWhich pendulum operation to perform
handleNoHandle from a prior 'create' (required for all but 'create')
dampingNoHow fast motion decays, 0-1 (hard-clamped by VNyan). Default 0.1. Higher = settles sooner. For 'create', at runtime creation time only.
boneCountNoFor 'create'. Typical chains use 2-4 bones. Default 4
stiffnessNoResistance to being rotated away from the rest orientation, 0-1 (hard-clamped). Default 0.1. For 'create', at runtime creation time only.
elasticityNoRestoring force pulling each bone back to its rest position, 0-1 (hard-clamped). Default 0.1. LOWER = floppier / more swing-bounce; higher = snaps back fast - it's a return-strength, not a bounce-amount, so low values look bouncier. Applies uniformly across the whole chain (VNyan does not use per-bone distribution curves), though motion naturally accumulates toward the chain tip. For 'create', at runtime creation time only.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changedv0.4.0
    • changedInput schema / properties / inert / description
      Previous value: -"How much of the avatar's own movement is transferred into the chain, 0-1 (hard-clamped). Default 0. For 'create', at runtime creation time only."New value: +"How rigidly the chain FOLLOWS the avatar's own movement, 0-1 (hard-clamped). Default 0. Reads backwards from the name, so mind the direction: DynamicBone integrates 'position += velocity*(1-damping) + gravity + objectMove*inert', i.e. the object's motion is ADDED to each particle in proportion to inert. 1 = the chain travels with the avatar, so moving or turning it induces NO swing; 0 = the chain ignores the avatar, so avatar motion produces MAXIMUM swing. Raise it when head movement shakes a chain that should only react to its own input value. For 'create', at runtime creation time only."
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral disclosure burden. It states that runtime chains do not persist across restarts, that VNyan assigns rather than accumulates on output targets (so overwriting cancels motion), and that granularity differs by key type (name vs. axis vs. param). It also warns to read the guide before changing outputs, revealing potential side effects and constraints.

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

Conciseness4/5

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

The description is long but information-dense. It front-loads the critical constraint early and structures the content logically from overview to constraints to layering instructions. While it could be tightened, the length is justified by the tool's complexity and the need to prevent misuse.

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?

Given the 8 parameters, no output schema, and complex interplay, the description covers the essential operational aspects: the two sets of chains, the overwriting constraint, granularity differences, and layering strategy. It explicitly points to vnyan_guide for the full data model, which is good practice. However, it does not detail error conditions or the exact return format, so it is not fully complete.

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?

Schema coverage is 100%, and each parameter already has a rich description (e.g., 'inert' explains direction and effect). The description text adds little beyond the schema for individual parameters—it repeats the 'value' behavior and provides contextual constraints (like the overwriting rule) that apply globally. It does not introduce new parameter-level semantics, so a baseline score of 3 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 clearly identifies the tool's purpose: reading configured pendulum chains via 'list' and managing a separate set of runtime chains via 'create', 'delete', 'setPosition', 'setRotation', and 'chains'. It explicitly contrasts the two sets, eliminating ambiguity about what the tool operates on and is distinct from any sibling tool.

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

Usage Guidelines5/5

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

Usage guidance is explicit: it distinguishes between the always-readable 'list' and the live runtime commands, and it warns that only one pendulum may write a given output target, with an explanation of the consequences. It also provides concrete layering instructions and directs the agent to vnyan_guide topics for the full recipe, leaving no doubt about when to use this tool and how to avoid pitfalls.

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

Latest Blog Posts

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/seth-rah/vnyan-mcp'

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