Loading ToolBench
Local-first TouchDesigner AI copilot with 114 MCP tools, truthful concept routing, deterministic visual techniques, transactional execution, live validation, and rollback.
TDPilot demonstrates solid definition quality with strong naming conventions, comprehensive parameter schemas, and mostly good descriptions. All 15 tools follow verb_noun naming patterns (td_*). Tool descriptions range from 100-400 characters, generally covering WHAT and WHEN. However, several tools have incomplete output schema documentation, and some descriptions lack sufficient depth on error handling and recovery paths. Tool annotations (destructiveHint/readOnlyHint) are present, which is excellent. Naming is consistent and action-oriented. The main gaps are: (1) output schemas not fully documented for several tools (td_brain_plan, td_brain_ground return 'concept graphs' and 'grounding packs' but structure undefined); (2) error handling guidance sparse in descriptions; (3) some parameter descriptions are terse.
Ground a host-authored TD Brain draft and return a read-only grounding pack with task features, corpus evidence, candidate operators, parameter contracts, operator availability, live state, exemplars, and the draft authoring contract.
Plan a TD Brain task and return a non-mutating concept graph, typed patch plan, and server-derived intent coverage. Use when a request is pattern-shaped with an exact validated topology or technique composition.
Read CHOP channel data (values/samples).
Get cooking/performance info for a subtree.
Create or update a custom parameter page on a COMP.
Execute Python code inside TouchDesigner.
Output schemas not documented for complex tools (td_brain_plan, td_brain_ground). Descriptions mention 'concept graph', 'grounding pack', 'patch plan', 'intent coverage' but do not specify the structure of these responses. LLMs cannot chain results without knowing what fields to extract.
Error handling and recovery guidance missing from most tool descriptions. No indication of what constitutes a retryable error vs. permanent failure. E.g., 'td_exec_python' does not document behavior on SyntaxError, timeout, or restricted-operation rejection.
Parameter dependency documentation incomplete. 'td_custom_parameters' accepts 'params' array with 'kind' that determines valid sub-fields (float/int/toggle/menu/str/rgb/rgba/pulse/file/filesave/folder/chop/comp/dat/mat/header), but does not document which fields (default, min, max, label, size) apply to which kinds.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | A | 82 | 2026-07-28+ | v2 |
Read SOP/POP geometry data (points/prims).
Read the text or table content of a DAT node.
Read recent runtime event history from the server-side event buffer.
Read structured POP metadata and attribute samples.
Capture a TOP frame as base64 inline, or to disk via ``save_path``. Use this for a quick single-frame visual: with ``save_path`` set the image is written to disk TD-side and only metadata + the path come back — use this for repeated visual verification. Without it the response embeds base64 image data; ask the user before repeated base64 screenshots because each image can consume significant tokens in model context. Prefer td_capture_frame when you want metadata-first (resolution/format/bytes) with the image behind a confirm/save_path gate; prefer td_capture_and_analyze when you also need cooking state and errors folded into the same call.
Write text or table content into a DAT node (overwrites existing).
Subscribe to runtime TD events for a node.
Dispatch up to 8 tool calls in one model roundtrip with sequential execution on the cook thread. Per-call failures do not abort the batch.
Remove a runtime-event subscription for a node path.
'td_screenshot' description is verbose (400+ chars) and buries the actionable guidance. Key advice ('prefer td_capture_frame when…', 'ask the user before repeated base64…') is buried in prose rather than highlighted as distinct concerns.
Resource limits not fully documented. 'td_tool_batch' accepts 'max 8 items' but does not specify timeout per call, total timeout for the batch, or failure behavior (does one failed call abort the batch or return partial results?). Description says 'Per-call failures do not abort' but structure of per-item results not specified.