Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
td_search_operatorsA

Find TouchDesigner operators by what they do.

Searches names, labels, summaries and full documentation. Use this first, in plain language ("blur an image", "read a MIDI device", "instance geometry"). family optionally narrows to TOP, CHOP, SOP, DAT, MAT, COMP or POP.

td_operator_schemaA

Every parameter of an operator: exact names, defaults, menu options, ranges.

Read this before creating or configuring an operator — it gives the names TouchDesigner actually accepts. Note that TouchDesigner's own documentation describes parameter groups (such as 't' for Translate) while the settable parameters are the members ('tx', 'ty', 'tz'); this returns the members. page filters to one parameter page.

td_search_parametersA

Find which operators have a parameter matching a description.

Useful when you know the effect you want but not which operator provides it — "feedback amount", "sample rate", "instancing".

td_python_apiA

Python members and methods available on a class, with inherited ones.

name is an operator type ('noiseTOP') or a class ('TOP', 'OP', 'Par', 'UI'). query filters the member list. Signatures and return types come from the reference shipped with this TouchDesigner build.

td_docsA

Search or read TouchDesigner's documentation, mirrored offline.

Pass page to read one article in full (for example 'Write_a_GLSL_Material' or 'Noise_TOP'); otherwise query searches all 2000-odd pages and returns matching excerpts. Covers concepts and guides, not just operators.

td_expression_helpC

Look up TouchDesigner expression and command syntax.

td_statusB

Whether TouchDesigner is reachable, and what project it has open.

td_logA

Your own trail: every bridge call this host has made, and how it went.

Reach for this when something is wrong and you do not know what you did — an operator is missing, a parameter is not what you set, the artist says "it broke after you touched it". td_status shows only the last call and the next one overwrites it; this is the whole session, and it survives TouchDesigner being closed and reopened, so it also answers "what happened yesterday".

Also reach for it before repeating a call that failed. failures=True gives the refusals alone, each with the text it refused with, and the repair for the most recent one — repeating a call that a scope claim or a missing path already refused will refuse again for the same reason.

summary=True answers a different question: over everything recorded, which methods refuse and which are slow. Use it to notice a pattern you are inside of — the same method failing five times means the approach is wrong, not the call.

Not everything is here, and the gap matters: only calls that reached the bridge are recorded. The offline tools (td_project_read, td_docs, td_search_operators) never dial it and leave no trace, so an empty journal means no live work, not no work.

td_instancesA

Which TouchDesigner instances are running, and which one these tools reach.

Reach for this whenever the artist may have more than one project open — and always before believing that an edit went where you meant. Every other bridge tool here dials a single bridge chosen on this host (the session file, or a --port/--project flag given to the td-atlas CLI); with two TouchDesigners running, the one it picks may not be the one the conversation is about, and nothing in a successful result would say so. This lists all of them — project, port, build, pid and when each was last seen — and marks the one the other tools are talking to. Aiming at a different one is not possible from here (the CLI's --port/--project have no MCP equivalent yet): name the port to the user and let them decide, rather than assuming the edit landed where they meant.

td_doctorA

Check the whole chain — install, index, probe pass, bridge, this server.

Run this when something is wrong and it is not obvious which link broke, or before trusting a long build session. The trap it exists for is the one that raises nothing: an index built from a different TouchDesigner build still answers every question, with defaults and menu options that describe the other build, so an agent configures parameters that may not exist and the only symptom is a network that quietly does not work. It also separates 'not running' (a state) from 'registered but silent' and 'answering but refusing the token', which need different repairs. Each line names the command that fixes it.

td_networkA

List the operators inside a component and how they are wired.

td_op_infoA

Inspect one operator in the running project: type, wiring, live parameter values.

td_buildA

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.

td_set_paramsA

Set parameters on an existing operator, checked against the index first.

Values may be a constant, {"expr": "..."} for an expression, {"bind": "..."} or {"pulse": true}. Pass op_type to have the names validated locally before anything is sent. Pass the same owner you claimed the area with, or your own claim refuses this write.

td_renderA

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.

td_healthA

Find what is quietly broken — the failures nothing reports.

Run this after building anything, and whenever a composition "looks fine but does nothing". td_errors only covers what TouchDesigner calls an error; this additionally catches:

  • operators that never cook, because a branch nothing displays or records is never pulled and therefore is not running at all

  • output operators switched off (audio device, movie recorder, MIDI, OSC) which produce nothing and report nothing

  • GLSL operators whose shader failed to compile, quoting the compiler's own line: TouchDesigner only warns that an Info DAT would show the details

  • tracebacks raised inside callbacks and extensions (Execute DAT, Replicator, component callbacks), which are kept apart from the error list. A Script operator's onCook raising during a cook Python asked for is not covered — that traceback goes back to the caller instead

  • operators costing more than half a frame to cook, and the resulting frame rate collapse

  • bypassed operators, and the current licence

interval is the gap between the two samples, in seconds, and is capped: this process sleeps through it and answers nothing else meanwhile.

td_paletteA

Search the ready-made components TouchDesigner ships in its palette.

277 finished tools — projection mappers, corner-pinners, colour pickers, audio analysers, UI widgets. Check here before building something from scratch, then install the one you want with td_palette_load.

td_palette_loadA

Install one of TouchDesigner's palette components into the project.

Reach for this the moment td_palette shows a component that does what you were about to build by hand — it is one call, where the alternative is td_exec with a loadTox path you have to get exactly right, on a machine whose TouchDesigner may not be installed where you assume.

name is the component name td_palette reports. The .tox path comes from the index and is checked on disk before anything is sent, so a stale index fails here rather than as a TouchDesigner traceback. Fourteen palette names exist in two folders each (the Ableton set, operatorPath, vrRenderToMovie): those are refused with the candidates listed until you narrow them with category.

The node's final name is reported back rather than assumed: TouchDesigner names a loaded component after its file, and numbers it (checker1, checker2) when a sibling already holds that name. rename is stricter — a name already taken is refused outright and the load is rolled back, so read the path in the reply rather than assuming the name you asked for.

Loading is not free: measured 0.006 s for a 20-operator component and 1.08 s for kantanMapper's 4,079, all of it on TouchDesigner's main thread.

td_glossaryA

Look up TouchDesigner terminology.

185 glossary entries defining the vocabulary the rest of the docs assume: Cook, Time Slice, Par, CHOP, Clone, Tox, Perform Mode, Sample.

td_errorsA

Every operator at or under path currently reporting an error or warning.

Node errors are shown as colours in the TouchDesigner UI and are otherwise invisible to you; check this after building something.

The default is the project, not /, and asking for / is usually the wrong move: the walk is breadth-first and bounded, and on an open session TouchDesigner's own /ui and /sys are thousands of operators wide at the shallow levels, so the budget runs out before the walk reaches anything of yours. Point it at the component you built instead.

td_execA

Run Python inside TouchDesigner and return its output.

The full td namespace is in scope (op, ops, root, project, ui, app, families, operator type classes). A trailing expression, or a variable named result, is returned. Reach for the structured tools first — this blocks TouchDesigner's main thread while it runs.

td_project_readA

Read a .toe or .tox from disk, without TouchDesigner running.

Returns the operator tree with wiring. path narrows to a subtree such as '/project1', depth is how many levels of children to show, and params adds the parameter values that differ from the defaults — which is all a saved project records, so it is exactly what someone chose deliberately.

td_project_textA

Dump a whole .toe/.tox network as JSON, without TouchDesigner running.

Use this when td_project_read's tree is not enough — when the answer needs
every parameter, the wiring, the flags and the DAT code at once, for
instance before rewriting a component or explaining what an unfamiliar
project actually does.

DAT text arrives as an array of lines rather than one escaped string, so a
single changed line stays a single changed line; join the array with '

' to get the file back byte for byte. Standard JSON otherwise.

A network larger than `max_bytes` is refused rather than truncated: a cut
dump is not parseable JSON, and `path` narrows the dump to one component.
td_project_writeA

Write an edited td_project_text dump back into a new .toe/.tox.

The return leg of td_project_text: edit the JSON, hand the whole document back here, and get a file TouchDesigner opens — with no instance running.

Three things to know before reaching for it, because each one is a silent wrong answer otherwise:

  • file must still be the original the text came from. The dump covers five of the forty-odd kinds of file a .toe holds; panel layouts, replicator settings and custom parameter definitions live in the others and are copied across from the original. There is no path from text alone to a .toe.

  • output must not exist. Repacking writes the file whole, and this tool will not overwrite anything of the user's. Write beside it and diff.

  • Read the gaps in the reply. Anything the text asked for that could not be written — a new operator, a changed operator type, a custom parameter page — is listed rather than approximated, and the built file does not say what the text said.

Changing a parameter, its expression, a DAT's code, a table cell, the wiring, the flags, the placement or the colour all work, as does deleting an operator.

td_variant_saveA

Keep the current state of a .toe/.tox so it can be returned to and compared.

Take one before trying a direction, another after, and td_variant_diff says exactly what the direction changed. Nothing of the user's is touched: the variant is the network text plus a byte copy of the file, kept under ~/.td-atlas/variants and grouped by the project's path.

That copy is what makes a restore possible at all: the rebuild is a patcher, so the text alone cannot produce a .toe. It is also cheap — measured across the shipped palette, the copy adds a median 19% on top of the text and no measurable time.

label may hold letters, digits, dot, dash and underscore. A label already in use is refused rather than overwritten. path narrows only the stored text to a subtree; the copy is always the whole file.

td_variant_listA

List saved variants — of one .toe/.tox, or of every project that has any.

Each line carries when it was saved, how large it is, and whether the original file has changed since. That last one is information rather than a warning: a restore reads the variant's own copy, so a changed original cannot affect it.

td_variant_restoreA

Write a saved variant back out as a .toe/.tox file.

A byte copy of what was saved, not a repack: nothing is collapsed, so TouchDesigner's toecollapse never runs and never moves a user's file aside to a .bkp1 name. output must not exist — hand back a new path and compare with td_project_diff rather than replacing anything in place. A directory as output keeps the name the file had when it was saved.

td_variant_diffA

Compare two saved variants of the same project.

The same semantic comparison td_project_diff runs, aimed at two saved states instead of two files: added, removed, retyped, rewired and re-parameterised operators, plus a line diff of changed DAT code. Nodes that only moved are counted separately so they cannot bury a real change.

td_project_grepA

Search the Python and GLSL held inside a project's DATs.

Ordinary file search cannot reach this code: it lives inside the .toe container, not on disk. pattern is a regular expression.

td_project_diffA

Compare two .toe/.tox files and report what actually changed.

Reports added, removed, retyped, rewired and re-parameterised operators, plus a line diff of any changed DAT code. Nodes that were only dragged to a new position are counted separately so they cannot bury a real change.

td_snapshotA

Save a component to a file so it can be diffed later.

Take one before a round of edits and another after, then pass both to td_project_diff to see exactly what changed. Snapshots go to ~/.td-atlas/snapshots.

A component is written rather than the whole session because saving the session is a Save As: it repoints TouchDesigner at the snapshot file and leaves the artist working in ~/.td-atlas instead of their own project.

td_exampleA

Show a working example network for an operator.

TouchDesigner ships an example .tox for most operators. This reads one offline and describes how it is wired and configured — a real usage reference rather than a parameter list.

td_undoA

Undo (or redo) the last change, including whole td_build batches.

td_claim_scopeA

Announce one subtree of the network as yours while you work in it.

Reach for this before a run of edits whenever another agent or session may be touching the same project: without a claim, two agents editing the same nodes overwrite each other and neither result reports anything wrong. owner is any string that identifies you (a task name, a session id) — it is what the other agent is told when it is refused.

The claim covers everything below path: '/project1/audio' includes '/project1/audio/eq1' but not '/project1/audio2'. It lapses on its own after ttl_seconds, so a crash cannot park a subtree for the session; claim again to renew. This is an agreement between agents, not a lock — it does not constrain a person editing those nodes by hand.

Write calls must carry the same owner to pass their own claim; the refusal text says which owner to send.

td_release_scopeA

Give a claimed subtree back before its claim expires.

Call it as soon as a run of edits is finished — otherwise the next agent waits out the whole time-to-live for nothing. Only the owner named on the claim can release it.

td_scopesA

Which subtrees other agents have claimed, and until when.

Check this before editing a project someone else may be in — it is the only way to see a claim before a write bounces off it, and it names the owner to coordinate with.

td_extension_addA

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.

td_annotateA

Leave a note in the network saying what you built and why.

Reach for this at the end of a build, not as decoration: the network you made records what it does and nothing about why, and the person who opens the project next reads the network editor, not this conversation. An Annotate is a coloured box with your text in it, sitting beside the nodes it describes.

text is the body (newlines work), title the bar along the top. Without position the note is placed where it does not cover anything, and without size it takes the default 382x288 network units — make it big enough to enclose the nodes it is about and td_annotations will report them as the ones it covers.

Pass path (an existing note) instead of parent to rewrite that note rather than add another — the right call when you rerun a build. The reply always names the path the note actually has: TouchDesigner ignores the name given at creation, so name is applied afterwards and can be refused if a sibling holds it.

mode is comment, networkbox or annotate: a comment is text only, a network box groups nodes without a title bar.

td_annotationsA

Read the notes in a network — including the ones a person left for you.

Check this before building in a project you did not build. An artist can leave a brief as an Annotate beside the nodes it concerns, which is the natural place to put it and completely invisible to every other tool here: it is not an error, not a parameter and not a name.

Each note comes back with the nodes its box sits over, so a note saying "this chain is the one to keep" can be matched to the chain. That list is geometric — the tiles whose centre falls inside the box — so a node the artist dragged half out of the box counts as outside.

td_flagsA

Read the flags that decide whether a node runs and what is visible.

Run this when a network looks right and produces nothing. A bypassed operator, a COMP with its display or render flag off, and a COMP with cooking disabled are all invisible in a parameter dump and in td_network, and each of them makes a correct network output nothing — the kind of silent failure that costs an hour of re-reading parameters.

unavailable names the flags this operator genuinely does not have, so you can tell "off" from "not a thing here". The clone master is a parameter rather than a flag, so it is not listed; cloneImmune is the flag half.

td_set_flagsA

Turn node flags on or off — bypass a node, hide it, stop it cooking.

The write half of td_flags, and the way to bypass an operator without deleting it. flags is {"bypass": true} and the like.

Every write is read back before this reports success, because the failure it exists to prevent is silence: TouchDesigner accepts pickable on COMPs only and refuses allowCooking = false outside a COMP, and a flag that exists but does nothing on this family would otherwise look like it landed. A refusal names the flag and the family, and nothing is left half-set.

Pass the same owner you claimed the area with, or your own claim refuses this write.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

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