MindDesigner / tdmcp: an MCP server that builds real TouchDesigner networks from plain language

General TouchDesigner Discussion
, ,
1

MindDesigner / tdmcp: an MCP server that builds real TouchDesigner networks from plain language

Hi everyone,

I wanted to share a project I have been building: MindDesigner (tdmcp), an open-source MCP server for TouchDesigner.

The goal is simple: let an MCP-capable AI assistant build actual TouchDesigner networks from plain language, not just search documentation.

For example, you can ask:

Create an audio-reactive particle galaxy with a warm feedback trail, expose the main controls, check it for errors, and show me a preview.

tdmcp connects three things locally:

  • your AI assistant: Claude Desktop, Claude Code, Codex, Cursor, etc.
  • the MCP server: exposes TouchDesigner-aware tools to the assistant
  • a small bridge running inside TouchDesigner: creates, connects, inspects, edits, and previews real operators in your project

What I am trying to solve is the gap between “the AI knows some TouchDesigner words” and “the AI can actually operate inside TouchDesigner safely enough to be useful.”

Current highlights:

  • embedded TouchDesigner knowledge base: 629 operators, 68 Python classes, workflow patterns, GLSL techniques, and tutorials
  • 179 MCP tools, from high-level artist tools like feedback networks, audio-reactive systems, particles, Shader Park scenes, and live/VJ utilities down to low-level node CRUD and inspection
  • create → verify → preview loop, so the assistant can build something, inspect it, catch errors, and iterate
  • auto-arranged readable networks instead of random node piles
  • Claude Desktop .mcpb bundle for no-terminal install
  • source setup for Claude Code, Codex, Cursor, and other MCP clients
  • project analysis, generated README/docs, reusable components, presets, recipes, and Obsidian vault integration
  • security controls for the local bridge, including bearer-token auth and the option to disable arbitrary exec endpoints

It is still moving fast, but it is already usable. The project is not affiliated with Derivative; it is a community experiment in making TouchDesigner more AI-native while still keeping the actual patch visible, editable, and artist-owned.

Links:

I would love feedback from TouchDesigner users, especially around:

  • what workflows would actually be useful in production or live performance
  • where the bridge should be more careful or transparent
  • which TouchDesigner concepts AI assistants still misunderstand
  • what examples, recipes, or tutorials would make this easier to evaluate

If anyone here is experimenting with MCP, AI-assisted patching, documentation agents, or live-control workflows, I would be very happy to compare notes.

Thanks!

2

I use Claude a massive amount now in my web dev tasks.

Does this mean I can do something like “I made a typo for an op named ‘OCpolor’ can you change all references to ‘OpColor’”? And that would pick up ALL python script references, parameters etc?
Cause that’s huge.
The amount of times I have worked on a project and realised my earlier naming doesn’t work.

Or “I misplaced a button on a component that I copied 20 times. The component at /project/Something/TheComponent/button1 needs to be at expression ‘y=parent().height - 100’ instead of ‘y=100’. The button was copied into ‘/project/*/TheComponent/’. Please fix them”

Regardless, I will be playing with this!
I had Claude successfully place a sin pattern chop in the default project after supplying it with a converted/extracted/cant-remember-the-name-of-the-provided-tool to turn a project into a directory of files/folders describing the network. But anything more complex broke Claude.
Making a bridge INTO touchdesigner is genius. Let the (python) API drive TD, and “teach” LLMs the API… this is awesome.
I can’t wait to try it! See if it can fix stupid mistakes, see if it can SPOT stupid mistakes. I don’t really care if it can build networks. My biggest cost is fixing early assumptions, or refactoring to new client requirements. Which LLMs can shine at when guided properly.
Super stoked!

3

Yes, that is exactly the kind of use case I am most excited about too.

The honest version is: I would not describe it as a magical “guaranteed semantic refactor across every possible hiding place” yet, but the bridge makes this kind of workflow much more realistic than asking an LLM to reason over an exported folder blindly.

For the rename case, the flow I want is: first have Claude/Codex inspect the live project and list every place it finds OCpolor - node names, parameter expressions, DAT text, callbacks, custom parameters, shortcuts, etc. Then it should show the proposed edits, apply them through the TouchDesigner Python API, and inspect again to confirm there are no remaining references. That is very much the direction.

Your second example is even more directly in the sweet spot: “find every /project/*/TheComponent/button1, change the Y expression, report which ones were changed and which ones were missing or different.” That kind of repetitive project surgery is exactly where having a bridge into TD starts to feel powerful.

I also agree with you: building networks from scratch is fun, but fixing bad early assumptions, renaming things, updating repeated components, spotting broken references, and adapting a project to new client requirements might end up being the more valuable part in real production work.

Please do play with it and try to break it. Those refactor/cleanup cases are the ones I really want to harden.