Skip to main content
Glama
Pantani

tdmcp

by Pantani
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Arrange network layout

arrange_network

Reorganize existing TouchDesigner networks into a clear left-to-right data-flow layout, or apply exact coordinates with rollback safety. Preserves node wiring while improving readability.

Instructions

Tidy an existing network into a readable left→right data-flow layout, or use layout_mode=explicit for one bounded, atomic exact-coordinate mutation with stale-context checks, readback and rollback. Annotation-aware automatic layout remains available, and omission of layout_mode preserves the legacy response. It never adds, deletes, or rewires nodes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesCOMP whose children to arrange, e.g. '/project1' or a container path.
positionsNoExplicit mode only: normalized absolute child path to exact [x, y] coordinates.
recursiveNoAlso arrange the nodes inside nested COMPs (each network is tidied on its own).
layout_modeNoKeep automatic layout by default, or place exact coordinates atomically.auto
target_sourceNoExplicit mode only: use the supplied paths or compare them with active selection.
include_dockedNoMove each node's docked DATs (e.g. GLSL *_pixel or callbacks DATs) with it by the same delta, like an interactive drag. Set false to reposition only the nodes themselves.
idempotency_keyNoExplicit mode only: stable response-loss recovery key.
annotation_awareNoTreat each annotation and the operators it encloses as one layout unit. Uses structured bridge routes and never raw Python.
annotation_paddingNoPadding in network-editor units when resize_annotations is enabled.
resize_annotationsNoWith annotation_aware, resize non-empty annotation bounds to the enclosed content plus annotation_padding.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.13.2
    • addedInput schema / properties / annotation_aware
      Added value: +{
+  "default": false,
+  "description": "Treat each annotation and the operators it encloses as one layout unit. Uses structured bridge routes and never raw Python.",
+  "type": "boolean"
+}
    • addedInput schema / properties / annotation_padding
      Added value: +{
+  "default": 80,
+  "description": "Padding in network-editor units when resize_annotations is enabled.",
+  "maximum": 1000,
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / idempotency_key
      Added value: +{
+  "description": "Explicit mode only: stable response-loss recovery key.",
+  "maxLength": 128,
+  "minLength": 16,
+  "pattern": "^[A-Za-z0-9_-]+$",
+  "type": "string"
+}
    • addedInput schema / properties / layout_mode
      Added value: +{
+  "default": "auto",
+  "description": "Keep automatic layout by default, or place exact coordinates atomically.",
+  "enum": [
+    "auto",
+    "explicit"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / positions
      Added value: +{
+  "additionalProperties": {
+    "items": [
+      {
+        "maximum": 1000000,
+        "minimum": -1000000,
+        "type": "integer"
+      },
+      {
+        "maximum": 1000000,
+        "minimum": -1000000,
+        "type": "integer"
+      }
+    ],
+    "type": "array"
+  },
+  "description": "Explicit mode only: normalized absolute child path to exact [x, y] coordinates.",
+  "propertyNames": {
+    "maxLength": 1024,
+    "minLength": 1,
+    "type": "string"
+  },
+  "type": "object"
+}
    • addedInput schema / properties / resize_annotations
      Added value: +{
+  "default": false,
+  "description": "With annotation_aware, resize non-empty annotation bounds to the enclosed content plus annotation_padding.",
+  "type": "boolean"
+}
    • addedInput schema / properties / target_source
      Added value: +{
+  "description": "Explicit mode only: use the supplied paths or compare them with active selection.",
+  "enum": [
+    "provided_paths",
+    "active_selection"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changedv0.12.0
    • addedInput schema / properties / include_docked
      Added value: +{
+  "default": true,
+  "description": "Move each node's docked DATs (e.g. GLSL *_pixel or callbacks DATs) with it by the same delta, like an interactive drag. Set false to reposition only the nodes themselves.",
+  "type": "boolean"
+}
  3. Addedv0.8.3
  4. Removedv0.6.1
  5. First observedv0.3.0

TDQS

A4.6/5.0
Behavior5/5

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

The description discloses important behavioral traits beyond the annotations: atomicity, stale-context checks, readback, rollback, and legacy response preservation. It also guarantees no structural changes to nodes, which adds significant context beyond readOnlyHint:false and destructiveHint:false.

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 three sentences, front-loaded with the core purpose in the first clause, and each sentence adds distinct, non-redundant information: core function, mode-specific behavior, and non-destructive guarantee. No word is wasted.

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?

For a complex 10-parameter tool with no output schema, the description provides a solid high-level orientation, covering modes, atomicity, safety guarantees, and legacy behavior. It doesn't describe return values, but given 100% schema parameter coverage, the description need not compensate for schema gaps. The main missing piece is return-value expectations, but this is acceptable given the schema richness.

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?

All 10 parameters already have descriptions in the schema (100% coverage), raising the baseline to 3. The description adds value by contextualizing layout_mode (auto vs explicit), mentioning annotation-aware behavior, and connecting idempotency_key to the atomic/rollback guarantees, but it doesn't deeply elaborate individual parameter meanings.

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 tool's purpose: 'Tidy an existing network into a readable left→right data-flow layout' with a specific verb and resource. It also distinguishes itself from topology-changing sibling tools by explicitly stating 'It never adds, deletes, or rewires nodes.'

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?

The description gives clear mode-specific guidance, such as 'use layout_mode=explicit for one bounded, atomic exact-coordinate mutation' and notes that annotation-aware automatic layout remains available. However, it does not explicitly name alternative sibling tools or provide 'when-not-to-use' exclusions beyond the implicit 'never adds, deletes, or rewires nodes.'

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