Skip to main content
Glama
grigabyte

td-atlas

by grigabyte
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

td_render

Render a TouchDesigner TOP to an image so you can visually verify what you built. Optionally save the PNG to a file and wait for parameter changes to settle before rendering.

Instructions

Render a TOP and return the image, so you can see what you built.

TouchDesigner is a visual tool: check your work with this rather than inferring it from parameter values. height defaults to preserving the TOP's aspect ratio; width=0 keeps the TOP's own resolution.

save_to writes the PNG to that path on this machine and answers in text instead of returning the image — for comparing two states pixel by pixel, or keeping a frame, without spending context on it. A file already at that path is refused unless overwrite=True: it may be the artist's.

settle_frames waits that many of TouchDesigner's own frames before rendering. A render right after td_set_params or td_build can return the frame from before the edit; 2–3 frames is enough for a parameter change. The answer says so if TouchDesigner stopped drawing during the wait.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
widthNo
heightNo
save_toNo
overwriteNo
settle_framesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.2.0
    • addedInput schema / properties / overwrite
      Added value: +{
+  "default": false,
+  "title": "Overwrite",
+  "type": "boolean"
+}
    • addedInput schema / properties / save_to
      Added value: +{
+  "default": "",
+  "title": "Save To",
+  "type": "string"
+}
    • addedInput schema / properties / settle_frames
      Added value: +{
+  "default": 0,
+  "title": "Settle Frames",
+  "type": "integer"
+}
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and delivers rich disclosure: default behaviors (height preserves aspect ratio, width=0 keeps TOP resolution), the side effect of save_to writing a file and switching response mode to text, the refusal of existing files unless overwrite=True, the stale-frame risk when rendering immediately after edits, and even that the tool will state when TouchDesigner stopped drawing. This goes well beyond the schema's bare defaults.

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?

Three paragraphs, front-loaded with purpose and usage philosophy before diving into parameters. Every sentence adds value — no filler — and the paragraph-per-parameter-group structure makes it scannable. It is on the longer side, but for a 6-parameter tool with zero schema coverage, the density of unique information justifies the length.

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?

For a tool with 6 params, 0% schema coverage, no annotations, and no output schema, the description is unusually complete. It covers defaults, special values, failure modes (file refusal), timing (settle_frames), and return behavior (image vs. text with save_to) — the last of which compensates for the absent output schema. Nothing an agent needs to invoke it correctly is missing.

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 description coverage is 0%, so the description must compensate — and it does thoroughly. It explains the special-value semantics of height (0 preserves aspect ratio) and width (0 keeps the TOP's own resolution), the dual behavior of save_to, the overwrite guard, and the frame-waiting semantics of settle_frames. Five of six parameters receive meaningful explanation beyond their schema titles; only path is left implicit, which is acceptable given its self-evidence.

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: 'Render a TOP and return the image.' It clearly distinguishes the tool from siblings like td_set_params (which edits) and td_build (which constructs) by emphasizing the visual verification outcome — 'see what you built.' No ambiguity about what this tool does.

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?

Gives explicit when-to-use guidance: 'check your work with this rather than inferring it from parameter values' directly tells the agent to render for visual verification instead of reasoning from parameters. It also provides targeted use cases for save_to (comparing two states pixel by pixel, keeping a frame without context cost) and timing guidance for settle_frames after td_set_params or td_build. It lacks a formal 'when not to use X instead' exclusion naming an alternative tool, but the context is clear and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools