Skip to main content
Glama
Sign In
TouchDesigner MCP

TouchDesigner MCP

by 8beeeaaat
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

exec_node_method

Execute a method on a TouchDesigner node by specifying the node path and method name, with optional arguments for dynamic control.

Instructions

Execute a method on a specific node in TouchDesigner

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "nodePath": "<nodePath>",
      "method": "<method>"
    },
    "name": "exec_node_method"
  }
}

Input Schema

NameRequiredDescriptionDefault
argsNoList of arguments for the method call
kwargsNoKeyword arguments for the method call
methodYesName of the method to call
nodePathYesPath to the node (e.g., /project1/null1)
detailLevelNoResponse detail level for tool output (minimal, summary, or detailed)
responseFormatNoStructured output format for formatted responses

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.1.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / args / items / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  },
-  {
-    "type": "boolean"
-  }
-]
    • addedInput schema / properties / args / items / type
      Added value: +[
+  "string",
+  "number",
+  "boolean"
+]
  2. First observedv1.4.11

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Execute a method' with no mention of side effects, mutation risk, method validation, error behavior, or whether methods can modify the TouchDesigner scene state. It does not contradict any annotations, but it also fails to inform the agent about potential destructive or irreversible operations.

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, direct sentence with no filler or redundancy. It front-loads the core action and target, making it immediately scannable, and it earns its place by conveying the essential purpose without unnecessary elaboration.

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?

The tool has six parameters, no output schema, and no annotations, yet the description supplies only the basic action and target. It does not explain what the method call returns, whether arbitrary methods are allowed, how arguments map to the call, or any safety considerations — leaving significant gaps for an agent attempting to invoke it correctly.

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?

Schema description coverage is 100%, so the schema itself documents all six parameters, including the nodePath example and the args/kwargs purpose. The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies — adequate but not enhanced by tool-level context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource — 'Execute a method on a specific node' — which names the action and target distinctly. It partially distinguishes the tool from siblings like execute_python_script by focusing on node-specific methods rather than general Python execution, but it does not explicitly contrast with any sibling.

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

Usage Guidelines2/5

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

The description gives no guidance on when to use this tool versus alternatives such as execute_python_script or update_td_node_parameters. There is no mention of when a method call is preferred over parameter updates or arbitrary script execution, leaving the agent to infer appropriate usage.

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

Deploy Server

Other Tools