Pulse a momentary parameter in TouchDesigner by providing the operator path and parameter name, enabling live parameter control from MCP clients.
Pulse a momentary parameter.
path (<class 'str'>): Operator path.
name (<class 'str'>): Parameter name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| path | Yes |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist and the description does not disclose what 'pulse' actually does—whether it triggers a temporary state change, what side effects occur, or whether it is reversible. The term 'momentary' hints at behavior but is left vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded: the purpose is stated in the first sentenceoley. The parameter descriptions add minimal clutter. This is concise, though arguably too sparse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations ricche and no output schema, the description alone must make the tool self-explanatory. It does not define 'pulse,' 'momentary,' or the expected behavior, leaving an agent without enough context to confidently select or invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source of parameter meaning. It adds only 'Operator path' and 'Parameter name', which barely extend beyond the schema property names and do not explain formats, constraints, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Pulse') and resource ('momentary parameter'), which conveys the core operation and differentiates it from sibling tools like par_get or par_set. However, 'momentary parameter' is somewhat jargon-heavy and not fully explained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like par_set or par_get. The description gives no exclusions, no context, and no mention of related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.