Remove a connection in TouchDesigner by providing the operator path and optionally the input or output index to disconnect.
Alias of conn.delete.
path (<class 'str'>): Operator path.
inputIndex (int | None): Disconnect this input.
outputIndex (int | None): Disconnect this output.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| inputIndex | No | ||
| outputIndex | No |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral details itself. It states the core action, disconnecting inputs/outputs, but omits side effects, reversibility, error behavior, whether all connections are removed when indices are omitted, and what the tool returns.
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 short and contains no filler. It front-loads the alias and then lists the parameters in a scannable format. The brevity is good, though it comes at the cost of missing behavioral context.
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?
For a deletion tool with no annotations, no output schema, and three parameters, the description is too sparse. It does not explain how the parameters combine, what happens in default cases, what errors may occur, or what the result of the deletion is. An agent would struggle to use this correctly without external knowledge of TouchDesigner's conn.delete API.
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 must compensate. It barely adds meaning: path is called an 'Operator path' and the indices are linked to disconnecting inputs/outputs, but it lacks path format, indexing convention, interaction between the two optional indices, and None behavior.
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 conveys that this tool deletes or disconnects connections on an operator path via the phrases 'Disconnect this input' and 'Disconnect this output'. However, it relies on the cryptic 'Alias of conn.delete' and does not clearly distinguish itself from the sibling tool conn_delete.
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?
There is no guidance on when to use this tool versus conn_delete or connection_create/get. The description does not explain when to provide path alone versus inputIndex/outputIndex, nor does it mention prerequisites such as the connection needing to exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.