Skip to main content
Glama

Author a VNyan node graph

vnyan_graph_write

Builds a node graph from a spec and exports it as a JSON file for live import into VNyan, or writes directly to a graph slot when VNyan is closed.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slotNoAdvanced/fallback: write directly into this slot instead of exporting a file. REQUIRES VNyan closed.
nodesYesEvery node in the graph
graphNameYesDisplay name for the graph tab
connectionsNoExecution-flow wiring. Most action nodes have ZERO execOut sockets (check vnyan_node_schema) - they are terminal, not links in a chain. To run several actions off one event, add one connection per action from that same event node, rather than chaining action-to-action.
exportFileNameNoFile name for the export (default: graphName + '.json'), written under the configured export directory
valueConnectionsNoData-flow wiring between value sockets - see valueConnections.toIndex for the critical type-safety rule.
Behavior5/5

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

No annotations provided, so description carries full burden. Discloses destructive nature of slot write, backup behavior, requirements (VNyan closed), runtime type safety, terminal nature of most action nodes, and limitations on file-path literals.

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?

Well-structured with clear sections, bold for key constraints, and front-loaded purpose. Some redundancy with schema descriptions but overall efficient for complexity.

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?

Covers all aspects: workflows, prerequisites, side effects, type safety, limitations, and references to related tools. No output schema but description explains return behavior (file or slot write). Complete for a complex authoring tool.

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?

Schema coverage is 100%, baseline 3. Description adds critical context: explains two modes via slot parameter, clarifies id not written to file, value strings encoding, type safety for valueConnections.toIndex, and alternative for file paths.

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?

Clearly states it builds a node graph from a spec, with two modes (export and slot write). Distinguishes from sibling tools like vnyan_graph_list and vnyan_graph_read by focusing on authoring/writing.

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?

Provides explicit when-to-use guidance: default export for general use, slot mode for advanced cases requiring VNyan closed. Warns about NodeGraphCount and refers to vnyan_settings_get and vnyan_guide. Differentiates from vnyan_graph_read lag.

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