Related Servers

Each tool maps to a distinct VNyan subsystem (params, dictionaries, triggers, blendshapes, bones, pendulum, prop, collider, spout, effects, lights, graphs, settings, expressions) with explicit source and write-semantics annotations in every description. The only mild ambiguities are within the graph-authoring family (vnyan_graph_write vs vnyan_bridge_graph both export graph files and accept a 'slot' option) and among the fire-and-forget senders (vnyan_api_fire, vnyan_ws_send, vnyan_osc_param), but the detailed descriptions delineate these clearly.

All tools share the vnyan_ prefix with uniform lowercase snake_case, providing a consistent subsystem-level pattern. However, action encoding is split: some tools bake the verb into the name (vnyan_graph_write, vnyan_settings_get, vnyan_plugin_list, vnyan_api_fire, vnyan_ws_send) while others are bare subsystem nouns that take action strings as their first argument (vnyan_pendulum, vnyan_collider, vnyan_expression, vnyan_bridge_graph, vnyan_prop). The convention is readable but not consistently applied.

30 tools sits above the threshold where tool counts start to feel bloated and presents a heavy selection surface for an agent. The count is nonetheless defensible because it tracks VNyan's genuine breadth of roughly 25 distinct subsystems, each tool covers a different subsystem with minimal overlap, and several tools bundle multiple sub-actions internally (pendulum, collider, expression, bridge_graph).

The surface covers the full lifecycle for most subsystems: graph authoring has list/read/write/schema, settings have guarded get/set, params/dicts/triggers/blendshapes/bones have live read-write, and pendulums have create/delete/reposition. Notable gaps are narrow — no way to delete expression entries or persisted pendulums/props, no persisted collider writes, and effect/light have no read-back — but these are mostly documented VNyan platform limitations rather than oversights.