touchdesigner-mcp

Name: touchdesigner-mcp
Author: aliphi

by aliphi

Overview Schema Related Servers Score Discussions

JavaScript

Local

TouchDesigner MCP Server

License: MIT Node MCP

An MCP server for TouchDesigner that lets you control TouchDesigner with Claude (or any Model Context Protocol client). Create operators, set parameters, and wire networks inside a running TouchDesigner project just by describing what you want — "make a noise texture chained into a level" — and watch the operators appear in your patch.

Built for Claude Code but works with any MCP-compatible client (Cline, Continue, Claude Desktop, etc.).

  MCP Client  ──stdio──▶  server.js  ──HTTP :9980──▶  Web Server DAT  ─▶  /project1
  (Claude…)              (this repo)                  (inside TD)         (your network)

What you need

macOS, Linux, or Windows (instructions are mac/linux; on Windows use the equivalent paths)
Node.js 18 or newer — check with node -v. Install via brew install node or nodejs.org.
TouchDesigner — any recent build, download here.
Claude Code — npm install -g @anthropic-ai/claude-code, then run claude once to log in.

Related MCP server: touchdesigner-mcp

Setup — three steps

1. Get the MCP server running

git clone https://github.com/aliphi/touchdesigner-mcp.git
cd touchdesigner-mcp
npm install

That installs the two dependencies (@modelcontextprotocol/sdk, zod). Don't run node server.js yourself — Claude Code will start it for you in step 3.

2. Set up TouchDesigner to listen

Shortcut: open Touchdesigner/TouchdesignerClaudeMCP.toe — it's a ready-to-use TD project with the Web Server DAT already created, configured on port 9980, and wired to the callback below. Open it, make sure the Web Server DAT's Active toggle is on, and skip to step 3.

Otherwise, to set it up by hand in your own project:

Open TouchDesigner (a fresh project is fine — you'll be inside /project1).
Press Tab → DAT → Web Server to drop a Web Server DAT into the network.
In the DAT's parameters:
- Set Port to 9980
- Turn Active ON
Right-click the Web Server DAT → Edit Callbacks. A text editor opens.
Replace the entire contents of that callback file with the contents of td_webserver_callback.py from this repo. Save.

Verify it's working: open http://localhost:9980 in your browser. You should see:

{"status": "connected", "project": "project1"}

If you don't, the DAT isn't Active or the port isn't 9980. Fix that before continuing.

3. Register the MCP server with Claude Code

From inside the touchdesigner-mcp folder, run:

claude mcp add touchdesigner -- node "$(pwd)/server.js"

That's it — Claude Code now knows how to launch the server.

Edit ~/.claude.json and add a touchdesigner entry under mcpServers:

{
  "mcpServers": {
    "touchdesigner": {
      "command": "node",
      "args": ["/absolute/path/to/touchdesigner-mcp/server.js"]
    }
  }
}

Replace /absolute/path/to/ with your real path.

Try it

Make sure TD is open with the Web Server DAT active, then in any terminal run claude and try:

List what's in my TouchDesigner project

Create a noiseTOP feeding a levelTOP, then a compositeTOP

Build me a basic 3D scene: a sphere, a camera, a light, and a renderTOP that outputs it all

Claude will use the tools below to build the network inside your running TD project. Switch back to TD to watch the operators appear.

What the MCP server exposes

Tool	What it does
`td_list_operators`	List everything at a given path. Always run this first.
`td_create_operator`	Create a new operator (TOP/CHOP/SOP/DAT/COMP) at a position
`td_set_parameter`	Set a single parameter on an operator
`td_connect`	Wire one operator's output into another's input
`td_run_python`	Escape hatch — run arbitrary Python inside TD

Conventions Claude follows (defined in CLAUDE.md):

Everything lives under /project1
Operators spaced 200 horizontal × 150 vertical
Sources on the left, outputs on the right

Repo layout

server.js                                  Node MCP server (the thing Claude launches)
td_webserver_callback.py                   Paste this into TD's Web Server DAT
CLAUDE.md                                  Conventions Claude follows when building networks
package.json                               Node deps
Touchdesigner/TouchdesignerClaudeMCP.toe   Ready-to-use TD project with the Web Server DAT pre-wired

Troubleshooting

"Error connecting to TouchDesigner: fetch failed" TD isn't reachable. Check, in order: (a) TD is open, (b) the Web Server DAT exists, (c) its port is 9980, (d) Active is on, (e) http://localhost:9980 returns the JSON above in your browser.

Claude says it doesn't have TouchDesigner tools The MCP server isn't registered. Run claude mcp list — touchdesigner should appear. If it doesn't, redo step 3 with an absolute path. After registering, fully quit and reopen Claude Code.

"Cannot find module '@modelcontextprotocol/sdk'" You skipped npm install. Run it inside the touchdesigner-mcp folder.

Operators get created but td_set_parameter errors with "no attribute 'par.foo'" That parameter name doesn't exist on that operator type. Ask Claude to use td_run_python with dir(op('/project1/x').par) to list valid parameters.

Port 9980 already in use Either kill whatever's using it (lsof -i :9980) or change the port in both server.js (the TD_PORT constant near the top) and the Web Server DAT in TD.

How it works under the hood

The MCP server has no domain logic — it serializes Python strings and POSTs them to http://localhost:9980. The Web Server DAT's callback tries eval(code) first, and if that's a SyntaxError, falls back to exec(code). The last expression in the script becomes the HTTP response body, which is why every built-in tool ends with an f-string summary like f"Connected {…} -> {…}".

Security note: the callback runs arbitrary Python with no auth. Keep localhost only — don't expose port 9980 to your network.

Available Tools

5 tools

td_connectB

Connect the output of one operator to the input of another operator in TouchDesigner.

ParametersJSON Schema

Name	Required	Description
`from_path`	Yes	Path of the source operator
`to_path`	Yes	Path of the destination operator
`from_output`	No	Output index (default 0)
`to_input`	No	Input index (default 0)

TDQS

B3.4/5.0

Behavior2/5

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

Without annotations, the description carries the full burden of behavioral disclosure, but only provides the basic action. It does not mention if existing connections are overwritten, what happens with invalid paths, error handling, or the state after connection. This is insufficient for a mutation tool.

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 a single sentence that conveys the core purpose efficiently. No unnecessary words, and it is front-loaded with the essential verb and objects.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description should provide more context to be complete. It lacks details about the effect on the TouchDesigner network, prerequisites, or return behavior. A connecting tool often has nuances about ordering or validation that are missing.

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

Parameters3/5

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

The input schema has 100% description coverage, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not clarify the ordering or specifics of output/input indices. The schema already documents this adequately.

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 clearly states the action 'connect' and the specific resources: 'output of one operator' to 'input of another operator' in TouchDesigner. It is distinct from sibling tools like td_create_operator (creation), td_list_operators (listing), td_run_python (execution), and td_set_parameter (modification), making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies usage by stating what the tool does, but provides no explicit guidance on when to use it, when not to use it, or alternatives. Given the straightforward nature of connecting operators, the implicit guidance is adequate, but lacks depth.

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

td_create_operatorA

Create a new operator in TouchDesigner. Operator types use TD class names like: TOPs: constantTOP, noiseTOP, compositeTOP, levelTOP, feedbackTOP, moviefileinTOP, renderTOP CHOPs: noiseCHOP, lfoCHOP, mathCHOP, filterCHOP, constantCHOP SOPs: sphereSOP, boxSOP, gridSOP, noiseSOP, transformSOP DATs: textDAT, tableDAT, scriptDAT COMPs: geometryCOMP, cameraCOMP, lightCOMP, containerCOMP

ParametersJSON Schema

Name	Required	Description	Default
`parent_path`	No	Parent operator path, e.g. /project1	/project1
`op_type`	Yes	Operator type class name, e.g. noiseTOP, sphereSOP
`name`	Yes	Name for the new operator
`x`	No	Horizontal position in network
`y`	No	Vertical position in network

TDQS

A3.7/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only says 'Create a new operator' without explaining side effects, error handling, or whether it overwrites existing operators. Minimal behavioral 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 concise: one sentence followed by a clear bulleted list of examples. No extraneous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers basic creation but lacks details on return value, error conditions, or default behavior. Given the absence of annotations and output schema, more context would be helpful.

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?

Schema description coverage is 100%, so each parameter is already documented. The description adds value by listing example operator types, which clarifies the op_type parameter beyond the schema.

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 clearly states 'Create a new operator in TouchDesigner' and provides concrete operator type examples. This distinguishes it from sibling tools like td_connect, td_list_operators, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description provides operator type examples and required parameters (op_type, name) but does not explicitly state when to use this tool vs alternatives, nor does it mention prerequisites like existing parent path.

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

td_list_operatorsA

List all child operators at a given path in TouchDesigner. Useful for inspecting the current state of a network.

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	Path to list children of	/project1

TDQS

A4/5.0

Behavior3/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. It correctly implies a read-only operation ('list'), but does not explicitly state it is non-destructive or describe any limitations (e.g., depth of listing). The description is adequate but not detailed.

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?

Two concise sentences that front-load the core purpose and follow up with a usage hint. Every sentence is valuable with no redundant phrasing.

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?

With one parameter and no output schema, the description adequately explains what the tool does and when to use it. It could mention the output format (e.g., returns operator names) or depth behavior, but overall it is sufficient for a simple list operation.

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

Parameters3/5

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

The input schema has 100% description coverage for the single parameter 'path' (default '/project1'). The description adds no additional semantics beyond the schema's parameter description, meeting the baseline expectation.

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?

Explicitly states it lists child operators at a given path in TouchDesigner, clearly distinguishing it from siblings like td_create_operator (create) and td_set_parameter (set). The verb 'list' combined with the resource 'child operators' is specific and unambiguous.

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?

Provides a clear usage context: 'Useful for inspecting the current state of a network.' While it doesn't explicitly mention when not to use or name alternatives, the context is sufficient for an AI agent to understand when to invoke this tool over others.

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

td_run_pythonA

Execute Python code inside TouchDesigner. Use op() to reference operators. Examples:

op('/project1/container1') to get an operator
op('/project1').create(constantTOP, 'my_top') to create a TOP
op('/project1/my_top').par.colorr = 1.0 to set a parameter
op('/project1/my_top').nodeX = 200 to position in the network Always use full paths starting with /project1.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Python code to execute in TouchDesigner

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. While it explains how to write code, it does not disclose potential risks, such as destructive operations or security implications. As a code execution tool, more transparency about side effects is needed.

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 concise and front-loaded with the purpose, followed by relevant examples. Every sentence serves a clear purpose, and the structure is efficient without unnecessary words.

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 tool's complexity (code execution) and lack of output schema, the description adequately explains how to interact (op() usage, full paths). It could mention error handling, but overall it is sufficiently complete for an agent to invoke correctly.

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 schema already describes the 'code' parameter with 100% coverage, but the description adds value by providing examples and best practices (e.g., full paths, common operations). This goes beyond the schema's basic description.

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 clearly states 'Execute Python code inside TouchDesigner', which is a specific verb+resource. It distinguishes itself from sibling tools like td_connect, td_create_operator, td_list_operators, and td_set_parameter, which handle specific operations rather than arbitrary code execution.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description provides examples and guidance on using op() and full paths, implying when to use the tool (for custom Python execution). However, it does not explicitly state when not to use it or provide alternatives, leaving the agent to infer usage context.

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

td_set_parameterA

Set a parameter on a TouchDesigner operator. Common parameter names:

TOPs: colorr, colorg, colorb, colora, resolutionw, resolutionh, brightness, contrast, opacity
SOPs: radx, rady, radz (radius), tx, ty, tz (translate), rows, cols
CHOPs: roughness, amp, freq, period
General: display, render, bypass

ParametersJSON Schema

Name	Required	Description
`op_path`	Yes	Full path to the operator, e.g. /project1/noise1
`param_name`	Yes	Parameter name, e.g. colorr, resolutionw
`value`	Yes	Value to set

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It indicates mutation ('set') but lacks details on side effects, permissions, or recomputation behavior. The list of common parameter names adds context but not behavioral depth.

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 brief and front-loaded with the core action. The subsequent list of examples is structured and concise, with no extraneous information.

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 tool's simplicity and lack of output schema, the description covers the primary usage well. Minor gaps exist: no mention of error behavior or return value, but the tool's purpose is sufficiently conveyed for typical use.

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?

Schema coverage is 100% with descriptions for all parameters. The description adds value by providing categorized common parameter examples (TOPs, SOPs, CHOPs, General), which aids the agent in selecting valid param_name values beyond the schema.

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 explicitly states 'Set a parameter on a TouchDesigner operator' which is a clear verb+resource. Sibling tools like td_create_operator and td_run_python are distinct, so the purpose is well differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives. The sibling names hint at different tasks, but the description does not specify conditions or exclusions, leaving the agent to infer usage context.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct operation: connecting, creating, listing, running code, and setting parameters. Even though td_run_python is versatile, it is clearly for arbitrary code execution and does not overlap with the specific purposes of the other tools.

Naming Consistency4/5

All tools share the 'td_' prefix and use snake_case, but 'td_connect' lacks an explicit object while the others follow a verb_noun pattern like 'td_create_operator' and 'td_set_parameter'. This minor deviation is consistent enough for good readability.

Tool Count5/5

With 5 tools covering creation, connection, listing, parameter setting, and code execution, the count is well-scoped for the domain. Each tool serves a clear purpose without unnecessary redundancy.

Completeness4/5

The set covers core CRUD-like operations (create, connect, list, set) and includes a Python execution tool for flexibility. However, it lacks dedicated tools for deletion or getting parameter values, which are minor gaps that can be worked around via td_run_python.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Remote Desktop Commander
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214
mcp-producer
io.github.AceDataCloud
MCP server for Producer/Riffusion AI music generation
Audio Processing AI & Machine Learning
22
mcp-aichat
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2
mcp-hailuo
io.github.AceDataCloud
MCP server for Hailuo (MiniMax) AI video generation
AI & Machine Learning Image & Video Processing
21

Related MCP Servers

td-mcp
Design Tools Multimedia Processing
tai5863
A
license
A
quality
D
maintenance
MCP server for controlling TouchDesigner from AI coding agents like Claude Code and Codex CLI, enabling operator manipulation, parameter control, and screenshot capture.
Updated 6 months ago (2026-03-18 04:51 UTC)
12
MIT
touchdesigner-mcp
Developer Tools Multimedia Processing Code Execution
mrinalghosh
A
license
Not graded
quality
A
maintenance
MCP server that lets Claude drive a running TouchDesigner instance to create operators, wire them, set parameters, run arbitrary Python, and introspect the td API.
Updated a month ago (2026-07-20 02:34 UTC)
MIT
TD-MCP
Multimedia Processing Audio Processing
Gleinkaa
A
license
Not graded
quality
D
maintenance
MCP server + web dashboard for TouchDesigner. Inspect, optimize, and control TD patches from Claude Code or the browser.
Updated 4 months ago (2026-05-08 07:35 UTC)
MIT
TD_MCP
RAG Systems Code Execution Developer Tools
NairoDorian
A
license
Not graded
quality
B
maintenance
A local-first MCP server for TouchDesigner that provides offline documentation retrieval and live control of TouchDesigner sessions, enabling AI-assisted network building and parameter management.
Updated 9 days ago (2026-08-26 09:38 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/aliphi/touchdesigner-mcp'

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