Skip to main content
Glama

Build RayTK expression graph

raytk_expr_graph_builder

Build editable RayTK ROP expression graphs from presets or custom nodes/edges, wiring typed connectors and exposing the output through out1 for immediate use in TouchDesigner.

Instructions

Build an editable RayTK ROP expression graph from a preset or explicit nodes/edges: copy RayTK masters live via pathsByOpType/category search, wire typed connectors, apply simple parameter values, lay out copied nodes deterministically, and expose the selected output through out1. Complements create_raytk_scene (minimal scene) and create_raytk_op (single ROP). Requires RayTK staged and loaded; offline tests validate payload/registration only, while live render/cook proof remains explicit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoName for the generated graph container.raytk_expr_graph
edgesNoCustom graph edges. Preset edges are used when nodes are omitted.
nodesNoCustom RayTK ROP graph nodes. Leave empty to use the selected preset.
presetNoStarter graph to build when nodes are omitted. Use custom with explicit nodes/edges.sphere_union_box
add_lightNoAppend pointLight and wire it into renderer input 2 when a renderer exists.
add_cameraNoAppend lookAtCamera and wire it into renderer input 1 when a renderer exists.
parent_pathNoParent COMP path to build inside./project1
add_materialNoAppend basicMat between the SDF/combine tail and renderer when absent.
add_rendererNoAppend raymarchRender3D when the graph has no output ROP.
library_pathNoOptional explicit path to the loaded RayTK library COMP. Omit to probe pathsByOpType and known namespaces live.
output_node_idNoNode id to expose through out1. Defaults to the renderer added or inferred by the tool.
capture_preview_imageNoCapture an inline preview from out1. RayTK shader compile may still be asynchronous.
Behavior5/5

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

Annotations provide only readOnlyHint=false, openWorldHint=true, destructiveHint=false; the description adds substantial behavioral detail: 'copy RayTK masters live', 'wire typed connectors', 'apply simple parameter values', 'lay out copied nodes deterministically'. It also discloses the limitation that 'offline tests validate payload/registration only' versus live render/cook proof, which is valuable context beyond annotations.

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 three sentences, each earning its place: core purpose and capabilities, sibling differentiation, and prerequisites/limitations. It is front-loaded with the main action and contains no filler or redundant repetition of schema fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, usage context, sibling relationships, prerequisites, and limitations, which is quite complete for a 12-parameter tool. The only slight gap is that it does not describe the return value or result format, but since no output schema exists and the actions are clear, this is a minor omission.

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

Parameters3/5

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

Schema description coverage is 100%, so all 12 parameters are already described in detail. The description mentions high-level concepts like 'preset or explicit nodes/edges' and 'deterministically' auto-layout, but does not add any parameter-specific meaning beyond what the input schema already provides, so a baseline score of 3 is appropriate.

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 opens with a specific verb+resource: 'Build an editable RayTK ROP expression graph', clearly stating what the tool does. It further distinguishes from siblings by naming 'create_raytk_scene (minimal scene)' and 'create_raytk_op (single ROP)' and describing this tool's broader scope (preset or explicit nodes/edges).

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?

Usage is explicit through sibling differentiation: 'Complements create_raytk_scene (minimal scene) and create_raytk_op (single ROP)' indicates when this graph-builder is the right choice over those alternatives. It also states a prerequisite ('Requires RayTK staged and loaded') and a limitation ('live render/cook proof remains explicit'), guiding when not to rely on it for full proof.

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/Pantani/tdmcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server