Skip to main content
Glama

VNyan pendulum chains

vnyan_pendulum

Control pendulum chains for VNyan avatar physics: create new chains, adjust their position or rotation, delete them, and list existing chains.

Instructions

'list' (disk, always readable) reads the pendulum chains configured in VNyan's UI (settings.json 'Chains' - spring-physics bone chains like ear/tail wiggle, each with input/output bindings). '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. See vnyan_guide topic:'pendulum-tuning' for the full physics explanation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inertNoHow 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.
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.
Behavior5/5

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

With no annotations provided, the description fully carries the transparency burden. It discloses that runtime chains are separate, don't persist, and are handled via numeric handles. It explains parameter clamps, defaults, and subtle behaviors like elasticity affecting floppiness vs snap-back, and notes VNyan's lack of per-bone distribution curves.

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-organized paragraph that front-loads the action summary and clearly separates the two chain groups. Every sentence adds value, and there is no unnecessary repetition or fluff.

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?

Despite lacking an output schema, the description covers all essential aspects: it explains what the tool does, the two distinct use cases, parameter behaviors, and offers a pointer to a guide for deeper physics. For a complex tool with 8 parameters, this is comprehensive.

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

Parameters5/5

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

Although schema coverage is 100% (baseline 3), the description adds significant context beyond the schema: defaults, ranges, clamps, per-action applicability (e.g., 'value' behavior differs for setPosition vs setRotation), and detailed physics explanations. This greatly enhances understanding.

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 distinguishes between the 'list' action for reading UI-configured chains from the other actions that manage runtime-only chains. It specifies the verb 'reads' for list and 'manage' for others, and explicitly states they are not the same. This differentiation helps the agent select the correct action.

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 provides clear context for when to use 'list' versus the other actions by separating them into two groups: disk-based vs runtime. It also references a guide for further physics explanation. However, it does not explicitly mention when not to use the tool or name alternative tools among siblings.

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

Install Server

Other Tools

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