Skip to main content
Glama

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.
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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Pantani/tdmcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server