Skip to main content
Glama

Drive StreamDiffusionTD

drive_streamdiffusion

Installs and configures a StreamDiffusion node in TouchDesigner, connecting a video source, setting generation parameters, and outputting the result via Syphon/Spout or NDI.

Instructions

Wraps the community StreamDiffusionTD.tox (by dotsimulate) into a one-shot Layer 1 setup: locate the .tox via candidate-path discovery, drop it into a fresh baseCOMP, wire a camera/source TOP into its input, set the prompt/strength/cfg/seed custom pars, and optionally re-broadcast the output via Syphon/Spout or NDI. Returns a friendly error when the .tox is not installed. The result envelope includes validated_pars so downstream tools (create_ai_mirror) know which SD pars to bind a control panel to.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tox_pathNoOptional explicit absolute or project-relative override. When set, becomes the only candidate; standard discovery is skipped.
source_top_pathNoFile system path to a video/image file to feed into the StreamDiffusionTD container (creates a moviefileinTOP). When omitted, a synthetic noise TOP is created for device-free preview.
promptNoSets the Prompt custom par on the tox.a vibrant neon cyberpunk portrait, ultra detailed
strengthNoimg2img denoising strength — sets Strength par.
cfgNoClassifier-free guidance scale. Low CFG (1–2) is normal for StreamDiffusion/LCM.
seedNoRandom seed. -1 = random per tox convention.
controlnet_weightNoSets Controlnetweight when the par is present in the tox build.
t_indexNoSets Tindex (denoise step list index) when present; omitted = tox default.
output_modeNointernal = Null TOP only. syphon_spout / ndi = adds an FM-01 sender wired from out1.internal
output_nameNoSender/source name when output_mode != 'internal'.tdmcp_streamdiffusion
parent_pathNoParent network for the fresh streamdiffusion_driver baseCOMP./project1
expose_controlsNoReserved for v2 — the tox already surfaces its own UI; this field is accepted but not acted on in v1.
Behavior5/5

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

The description adds significant behavioral context beyond annotations: it details the setup process (candidate-path discovery, fresh baseCOMP, wiring, parameter setting), error behavior ('returns a friendly error when .tox not installed'), and output structure (validated_pars). No contradiction with annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true).

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?

The description is a single paragraph that efficiently covers the main action, error handling, and result. It front-loads the purpose but could benefit from minor structural improvements like bullet points for different stages.

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?

Given the tool's complexity (12 parameters, no output schema), the description adequately covers workflow, error handling, and result envelope. It lacks detail on return format but mentions validated_pars. Edge cases like invalid tox_path are implied error handling.

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%, but the description adds meaning beyond schema: explains candidate-path discovery for tox_path, synthetic noise TOP for source_top_path, purpose of validated_pars for downstream tools, and the reserved nature of expose_controls.

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 explicitly states the tool wraps a specific community .tox into a one-shot Layer 1 setup, with clear verbs like 'locate', 'drop', 'wire', 'set', and 're-broadcast'. It distinguishes from siblings by specifying the source .tox and mentioning downstream tools like create_ai_mirror.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context (one-shot setup, error handling, validated_pars for downstream tools) but does not explicitly state when to avoid this tool or offer alternatives. However, the narrow scope implies clear usage boundaries.

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