Checks whether the VNyanMcp plugin bridge is reachable and reports per-system health (props/colliders/spout2/stretchbones), the full list of registered bridge RPC methods, which VNyan profile directory the disk-backed tools are reading (and how it was found - env var, the running plugin, or the conventional path), and the VNyan/Unity version the bundled node schema was generated from. No directory is hardcoded - this is the one place to confirm what this server actually resolved on your machine. Source: plugin + disk.

Get or set VNyan's numeric/text parameters and expand [bracketed] parameter references in a string. These are the same parameters SetParamNode/FilterParamNode read and write in node graphs. Source: plugin (live, read+write).

Get/set/clear entries in VNyan's named dictionaries - the same store JsonDictionaryNode and GetDictionaryValueNode use in node graphs, and where the REST API's payload lands. Source: plugin (live, read+write).

Call, queue, or reset VNyan's named Triggers (global across all node graphs - a TriggerNode with this name fires), and read recently-observed trigger calls. Source: plugin (live, read+write). 'recent' only sees calls made since the plugin loaded.

Whether an avatar is currently loaded. Source: plugin (live, read-only).

Read live blendshape values (all, or one by name) and set/clear override values that take priority over tracking - the same mechanism as the Blendshape node. Source: plugin (live, read+write).

Read a humanoid bone's current position/rotation (the composed pose from tracking/other layers, before this plugin's own overrides), or set/clear a rotation override for it (Euler degrees). Bone names are UnityEngine.HumanBodyBones values, e.g. 'Head', 'LeftUpperArm', 'Spine'. Source: plugin (live, read+write). Note: reading a bone you just overrode still shows the pre-override value - it reflects the incoming pose, not your own pending change. Full valid bone-name list: vnyan_guide topic:'bone-names'.

'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.

List configured props (disk, always readable), or set/toggle an existing prop's visibility by name (plugin, live - the same as the Toggle Prop node / a prop's Twitch redeem).

Read or set the current avatar's head/torso/hand collider size and offset - 'get'/'set' are live (plugin) and take effect immediately, VNyan re-applies these every frame. 'diskList' (disk, always readable) lists every per-avatar override file under colliders\, since the currently-loaded avatar's filename isn't otherwise exposed - compare against 'get' to see whether the running values match a saved override.

List Spout2 output cameras, or add a new one. Source: plugin (live, read+write). There is no safe runtime way to remove a Spout2 camera - do that from VNyan's own Spout2 Cameras panel.

'list' (disk, always readable) reads the persisted stretch bones (settings.json 'StretchBones'). 'add' (plugin, live, write-only) adds one at runtime - there is no live read-back for these, only the persisted list. All clamp/scale/move/offset params are multipliers or local-space offsets on the stretch bone's transform, not absolute world positions. Any field you omit uses VNyanStretchBone's own default, listed on each param below.

Read connected players and their slot transform, send an RPC to the lobby, and read recently observed RPCs/connection events. Source: plugin (live, read+write). Returns empty results, not an error, when VNyanNet isn't configured (VNyanNetServerUrl unset).

Read the active color theme, or open a native load/save file dialog to resolve a real local file path (blocks until the user responds - use a generous timeout expectation). Source: plugin (live).

Lists DLLs in Items\Assemblies and reads their IVNyanPluginManifest metadata where present. Source: plugin, read-only. Read-only inventory - installing a plugin DLL stays a user action.

POSTs {action, payload} to VNyan's built-in REST API (http://localhost:8069) to trigger a matching API Message node in a node graph. Source: native port, no plugin required. Fire-and-forget: no return value, payload values must be strings (binds to Dictionary<string,string>).

Sends a plain-text ' ' frame to ws://127.0.0.1:8000/vnyan to trigger a matching WebSocket Command node. Source: native port, no plugin required. Fire-and-forget, no JSON.

Sends a UDP OSC message to 127.0.0.1:28569 to directly set a VNyan parameter (/VNyan/Param/Float or /VNyan/Param/String depending on the value type). Source: native port, no plugin required. Fire-and-forget, no graph node needed.

Reads settings.json (tracking/output/graphics/audio/connections/misc). Source: disk, always readable regardless of whether VNyan is running. Secrets (OBS/Chaturbate/VNyanNet passwords) are redacted. Props/colliders/pendulums/stretch bones/gestures/expressions have their own dedicated tools and are not included here.

Patches specific keys in settings.json. Source: disk. REQUIRES VNyan to be closed - it triple-writes settings.json/.dat/_as.json on every save and would silently overwrite a live edit. Backs up settings.json to the backup\ folder before writing. Refuses unknown keys and keys that have a dedicated tool (props/colliders/pendulum/stretchbone/gesture/expression). settings.json is a single FLAT namespace of ~279 keys (no nesting) - call vnyan_settings_get first to see current values and exact key names for an area, or vnyan_guide topic:'settings-keys' for the full key-prefix index.

Expression Mapper entries: input blendshape value windows (AND-gated, case-insensitive match) that force output blendshape values when all inputs are in range. 'list'/'read' (disk, always readable) read settings.json 'Expressions'. 'export' writes one entry out as a standalone .vnexp JSON file. 'import' reads a .vnexp file and adds/replaces it by name in settings.json - REQUIRES VNyan closed, same guard as vnyan_settings_set.

Lists configured hand gestures (settings.json 'Gestures' - recorded per-finger curl thresholds for each hand). Source: disk, read-only: gestures are recognized from hand tracking (GestureNode/FilterGestureNode read them) but nothing in VNyan's node system or plugin API can set/fire one programmatically.

Lists the node-graph tabs (redeems.json, redeems1.json, ...) with their name, active flag, and node count. Source: disk, always readable.

Parses one graph slot and resolves every connection to (node type, socket role, index) pairs, decodes MessageBoxNode documentation text, and flags AES-encrypted local-file-path values instead of dumping their ciphertext. Also returns a 'warnings' array auditing the graph for mistakes VNyan accepts silently: a blendshape written twice on one execution path, a parameter read before the node that writes it (so it reads the previous tick), a float wired into BlendshapeNode's int value socket, and MathExpNode on a fast timer. Source: disk, always readable.

Looks up a node type's socket layout (exec-in/out and value-in/out counts, field names in socket order, and the values[] keys VNyan writes by default) - or lists all known node types plus schema provenance when 'type' is omitted. Source: bundled reference data (offline, no VNyan connection needed). How much to trust each field: socket counts and valueInFields/valueOutFields are read from real declared C# fields and are reliable. dynamicSockets lists socket kinds whose real count comes from the Unity prefab or is built at runtime (array-typed socket fields, and every 'Flex' node) - for those the count shown is a FLOOR, not a ceiling, and vnyan_graph_write will let you wire past it; confirm the true count with vnyan_graph_read on a graph that already uses the node. valuesUncertain: true means the values[] key names came from a source heuristic rather than an observed VNyan-written graph - verify them before relying on them. valuesCountMismatch is a stronger warning: that entry's field count disagrees with VNyan's own help file, so its keys are probably WRONG - confirm with vnyan_graph_read against a graph already using the node before authoring with it. possiblyIncomplete: true means values[] is shorter than the valueIn count, usually because a value socket was wired in the sampled graph (VNyan drops a wired socket's key from values[]).

Builds a node graph from a friendly spec (nodes with caller-chosen ids + literal values, exec/value connections referencing those ids). By default (no 'slot') it EXPORTS the graph as a plain JSON file - import it into VNyan live via its own 'Load Graph' menu (replaces the currently active tab, VNyan stays running, no restart). PREFER THAT even when VNyan is closed: the 'slot' path (redeemsN.json + its asredeemsN.json mirror) REQUIRES VNyan closed and is unreliable, because VNyan persists its own in-memory copy of a tab over the file - a verified slot write has been observed silently replaced by an older graph, surviving only in the asredeemsN.json mirror. If you use 'slot', re-verify after VNyan restarts. Returns a 'warnings' array of static-analysis findings when it spots one of the mistakes VNyan itself accepts silently (a blendshape written twice on one execution path, a parameter read before the node that writes it, a float wired into BlendshapeNode's int value socket, or MathExpNode on a fast timer) - the graph is still written, so read them. Most action nodes have zero execOut sockets (check vnyan_node_schema) - they are terminal, not links in a serial chain. To run several actions off one event/trigger, fan its single execOut out to each action's execIn directly, rather than chaining action-to-action. FAN-OUT EXECUTES IN CONNECTION ORDER within a single tick (multicast delegate), so terminal nodes CAN be sequenced by wiring order - a chain of ParamOpNodes each reading the previous one's parameter resolves in one tick, with no OrderedNode and no lag. You therefore do NOT need MathExpNode to avoid ordering problems, and reaching for it on a timer is a frame-rate disaster - see vnyan_guide topic:'graph-performance'. BlendshapeNode specifics: its wired value socket is cast to int (put a DecimalToNumberNode in front of any decimal source, or the write throws and vanishes), 'bsName' splits on ';' so one node can drive several shapes from one evaluation, and bsValue '0' REMOVES the override rather than writing zero - so never zero a shape and then write it in the same tick. Branching nodes (OrderedNode, every Filter*Node, CompareTextNode, RandomNode, ...) declare their exec outputs as an array sized by the Unity prefab, so vnyan_node_schema reports a floor rather than an exact count - wiring past that floor is allowed for those types, and the sockets are created as needed. Node-value file-path fields (sound/avatar files) can't be set as literals here since VNyan encrypts them - wire a SetTextParamNode/TextReplaceNode into that value socket instead, the same pattern VNyan's own Crowd Control example graph uses. VALUE SOCKETS ARE STRONGLY TYPED AT RUNTIME despite values[] always being strings in the saved JSON - wiring a raw int/text output straight into a float/bool input throws inside VNyan and silently aborts the whole call (see valueConnections.toIndex below). If writing directly to a slot, VNyan only EXECUTES slots covered by settings.json 'NodeGraphCount' - a graph placed beyond that count loads with no error but never runs; use vnyan_settings_get area:'misc' to check it first. If using the default export+Load-Graph workflow instead, note VNyan's live Load Graph updates the running graph immediately but only writes it to redeemsN.json on VNyan's own quit - vnyan_graph_read can lag behind what's actually loaded until then. Full cookbook: vnyan_guide topic:'node-authoring'.

The bridge graph is how post-processing effects and lights become controllable with no reflection: one TriggerNode per capability (namespaced 'mcp.*'), wired to the effect/light node, callable via vnyan_trigger or the vnyan_effect/vnyan_light convenience tools. 'preview' (disk, read-only) lists the actions it would install and checks for trigger-name collisions against every existing graph - triggers are global. 'install' (disk, write) by default EXPORTS the graph as a file - import it into a spare tab via VNyan's own 'Load Graph' menu, no restart needed. Pass 'slot' instead to write directly into that slot (REQUIRES VNyan closed, backs up the slot first). Refuses on any trigger-name collision either way.

Drives a post-processing effect (bloom/vignette) via the installed bridge graph's TriggerNode. REQUIRES vnyan_bridge_graph action 'install' to have been run once. Source: plugin trigger.call (live). This node type has no getter in VNyan at any tier - the MCP tracks the value it just sent, it does not read back the actual applied state.

Drives ambient light intensity via the installed bridge graph's TriggerNode - live-parametrized. 'sunLight' is fire-only: every value-socket wired into SunLightNode crashes VNyan's trigger processing (root cause not identified, looks like a VNyan-side bug specific to this node class), so firing it just turns the sun light on at fixed defaults - 'intensity'/'toggle' are ignored for it. REQUIRES vnyan_bridge_graph action 'install' to have been run once. Source: plugin trigger.call (live). No getter exists at any tier - the MCP tracks the value it just sent, it does not read back the actual applied state.

Long-form reference documentation for this MCP - node-authoring rules and the runtime type-safety gotcha, the full bone-name list, a live settings.json key index, pendulum physics semantics, the restart policy, and known limits. Omit 'topic' to list what's available. The same content is also published as MCP resources under vnyan://guide/.