Skip to main content
Glama

td_extension_add

Attach a Python class to a TouchDesigner COMP as an extension in one call, handling creation, parameter setup, and error reporting.

Instructions

Attach a Python class to a COMP as an extension, in one call.

Reach for this instead of td_exec whenever a component needs methods or state of its own. Done by hand it is five steps — create the COMP, create the DAT, write the text, set three parameters on the Extensions page, re-initialise — and the last one fails silently: measured on 2025.32460, a wrong Extension Object expression or a class that raises in __init__ leaves the COMP reporting no error, no warning, and extensionsReady True, with the real message only in the textport. This tool reads the result back off the COMP and hands you that message.

Aim it either at path (an existing COMP) or at parent plus name (a baseCOMP to create) — not both. code must define class <class_name>, conventionally taking ownerComp and capitalising anything meant to be called from outside: with promote on, capitalised members are callable straight on the COMP, and every member is reachable as op(...).ext.<name>.<member> regardless.

The class name doubles as the name of the textDAT holding the code, which is what the generated Extension Object expression points at (op('./Name').module.Name(me)). extension_name renames the extension for ext lookups without touching the class. index picks which extension slot to write; the wiki says a COMP has four, the sequence took six here. A created COMP is given a free spot in the parent network unless position names one — [x, y] in network units, the left and bottom edges of the tile; it is ignored when aiming at a COMP that already exists.

The code is parsed on this host before anything is sent, so a typo costs no round trip. That check is not a guarantee TouchDesigner accepts it: this host's Python may be newer than TouchDesigner's embedded 3.11, so 3.12+ syntax passes here and fails there — which is caught, but only by the read-back above. Pass the same owner you claimed the area with, or your own claim refuses this write.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYes
nameNo
pathNo
indexNo
ownerNo
parentNo
promoteNo
positionNo
class_nameYes
extension_nameNo

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

A5/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 it does so thoroughly: it reveals the silent-failure failure mode, the read-back verification, local parsing, Python-version mismatch risks, the owner-claim requirement, and the extension-slot behavior. This far exceeds minimal disclosure.

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 long but dense and front-loaded: the first sentence states the core purpose, then the manual five-step pain point, targeting rules, naming mechanics, and failure modes follow in logical order. There is no filler; every paragraph earns its place for a 10-parameter tool.

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 complex mutation tool with no annotations, the description covers when to use it, how to target a COMP or create one, parameter roles, error behavior, prerequisites, and version pitfalls. Nothing an agent needs to make a competent first call 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%, and the description compensates remarkably: it explains code/class_name, path vs parent/name, extension_name renaming, index slot selection, position coordinate semantics, promote behavior, and owner usage. Every ambiguous parameter receives meaningful context beyond its raw name.

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 and resource: 'Attach a Python class to a COMP as an extension, in one call.' It immediately distinguishes the tool from td_exec by stating when this is the right choice. An agent can tell exactly what capability is being offered.

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?

It explicitly says 'Reach for this instead of td_exec whenever a component needs methods or state of its own,' giving a clear selection rule. It also explains the two targeting modes — path vs parent+name — and warns not to supply both, plus when position is ignored.

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