vnyan-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VNYAN_WS_URL | No | VNyan's built-in WebSocket (native port passthrough). Default: ws://127.0.0.1:8000/vnyan | |
| VNYAN_OSC_HOST | No | VNyan's OSC receiver host. Default: 127.0.0.1 | |
| VNYAN_OSC_PORT | No | VNyan's OSC receiver port. Default: 28569 | |
| VNYAN_REST_URL | No | VNyan's built-in REST API (native port passthrough). Default: http://127.0.0.1:8069/ | |
| VNYAN_PROFILE_DIR | No | VNyan's profile directory (settings, colliders, node graphs). Default: resolved from running plugin or fallback path. | |
| VNYAN_MCP_BRIDGE_URL | No | The plugin's HTTP bridge. Default: http://127.0.0.1:8071/rpc | |
| VNYAN_MCP_GRAPH_EXPORT_DIR | No | Where authored/exported node graphs are written. Default: <resolved profile dir>\Exports |
Capabilities
Features and capabilities supported by this server
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| vnyan_statusA | 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. |
| vnyan_paramA | 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). |
| vnyan_dictB | 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). |
| vnyan_triggerA | 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. |
| vnyan_avatarA | Whether an avatar is currently loaded. Source: plugin (live, read-only). |
| vnyan_blendshapeA | 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). |
| vnyan_boneA | 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'. |
| vnyan_pendulumA | '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. |
| vnyan_propA | 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). |
| vnyan_colliderA | 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. |
| vnyan_spoutA | 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. |
| vnyan_stretchboneA | '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. |
| vnyan_vnyannetA | 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). |
| vnyan_uiA | 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). |
| vnyan_plugin_listA | 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. |
| vnyan_api_fireA | 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>). |
| vnyan_ws_sendA | 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. |
| vnyan_osc_paramA | 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. |
| vnyan_settings_getA | 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. |
| vnyan_settings_setA | 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. |
| vnyan_expressionA | 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. |
| vnyan_gestureA | 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. |
| vnyan_graph_listA | Lists the node-graph tabs (redeems.json, redeems1.json, ...) with their name, active flag, and node count. Source: disk, always readable. |
| vnyan_graph_readA | 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. Source: disk, always readable. |
| vnyan_node_schemaA | Looks up a node type's socket layout (exec-in/out and value-in/out counts, field names in socket order, and the |
| vnyan_graph_writeA | 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). Pass 'slot' instead to write directly into that graph slot (redeemsN.json + its asredeemsN.json mirror), REPLACING its contents - this REQUIRES VNyan closed (same guard as vnyan_settings_set) and backs up the slot first; use it only when VNyan is already closed for other reasons. 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. 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'. |
| vnyan_bridge_graphA | 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. |
| vnyan_effectA | 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. |
| vnyan_lightA | 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. |
| vnyan_guideA | 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/. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| guide-node-authoring | How to author VNyan node graphs with vnyan_graph_write: socket model, the runtime type-safety rule and converter nodes, terminal-node fan-out, encrypted file paths, NodeGraphCount gating, Load Graph persistence timing, and a worked example. |
| guide-bone-names | The full UnityEngine.HumanBodyBones name list accepted by vnyan_bone. |
| guide-settings-keys | Which settings.json keys fall under each of the six vnyan_settings_get areas, generated from the live file. |
| guide-pendulum-tuning | What damping/elasticity/stiffness/inert actually do in VNyan's pendulum chains, with real tuned values. |
| guide-restart-policy | Which VNyan MCP operations require closing VNyan vs. work with it running. |
| guide-known-limits | Write-only areas, the SunLightNode bug, and which capabilities depend on reflection that can break on a VNyan update. |
| node-schema | Full socket layout for every known node type - the same data vnyan_node_schema serves. |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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