Skip to main content
Glama

td_build

Apply multiple TouchDesigner edits as one atomic, undoable batch. If any operation fails, the entire change is rolled back, preventing half-modified projects and enabling a single undo.

Instructions

Apply several edits to the project as one atomic, undoable block.

Prefer this over separate calls: if any step fails the whole batch is rolled back, so the project never ends up half-modified, and a successful batch is a single Ctrl+Z for the person using TouchDesigner.

Each operation is {"method": ..., "params": {...}} where method is one of op_create, op_delete, op_connect, op_disconnect, par_set.

op_create takes parent, type, name, optional pars {name: value}, optional position [x, y], optional connect [{"from": path, "index": 0}], and optional text for a DAT's contents — shader and script source belongs there, not in a separate td_exec, so it lands inside this undo block. Values may be a constant, {"expr": "..."} for an expression, {"bind": "..."} or {"pulse": true}. Parameter names are validated against the index first.

Pass the same owner you claimed the area with — it carries into every step, and without it your own claim refuses the batch.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ownerNo
undo_nameNoagent edit
operationsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden of explaining behavior. It does so thoroughly: atomic rollback, single undo, owner requirement, supported operation methods, value encodings, and validation order are all disclosed.

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 text is dense but organized: it opens with the core value proposition, then lists operation methods, expands op_create arguments, and closes with validation and owner requirements. Each sentence adds needed detail, though the nested format examples make it slightly long.

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 complexity of batch editing with multiple operation types, the description covers the essential context: atomicity, undo behavior, operation syntax, parameter value forms, and ownership. It does not discuss return values, but an output schema appears to exist, so that is an acceptable omission.

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

Parameters4/5

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

The description adds substantial meaning for the central 'operations' parameter, enumerating methods like op_create and op_delete and detailing nested parameters such as pars, position, connect, and text. It also clarifies 'owner' by explaining it must be the claimed area. The 'undo_name' parameter is not explained, but the most complex parameter is richly documented.

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 precise statement: 'Apply several edits to the project as one atomic, undoable block.' It clearly identifies the resource (project) and the core action (applying edits in a batch), leaving no ambiguity about what the 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 Guidelines5/5

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

The description explicitly advises 'Prefer this over separate calls' and explains the benefit: atomic rollback and a single undo step. It also contrasts with td_exec by noting that shader/script text belongs in op_create rather than a separate call, giving clear usage direction.

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

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/grigabyte/td-atlas'

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