local-comfyui-mcp

Overview Schema Source Related Servers Score Discussions Admin

arrange_workspace

Automatically layout a ComfyUI workflow left to right in data-flow order, keeping groups intact and arranging only selected nodes if needed. Fixes cluttered canvases by computing or applying tidy positions.

Instructions

Lay the workflow out left to right, in the order the data flows through it.

Each node goes as far right as its consumers allow, so a loader sits beside the sampler that reads it rather than in a column of loaders at the far edge, and the nodes in a column are ordered and placed to face what they are wired to. The result keeps the top-left corner it already had, so it lands where the author left it rather than at the origin.

Groups are laid out as groups. A group is a rectangle with no membership - what is in it is whatever falls inside - so arranging a grouped canvas flat scatters each group across the columns and its box stretches to follow, which on a real workflow turned eight tidy groups into overlapping sheets covering everything. So the layout runs inside each group first and then over the blocks they form, and ungrouped nodes travel together as one more block.

It still moves every node it is given, which is the blunt instrument. only is the narrow one: it arranges just those nodes and leaves the rest of the canvas alone - and since the caller has already said which nodes they mean, groups are not consulted in that case.

Args: only: node ids to arrange, leaving every other node where it is. Links to nodes outside the list are ignored, since they cannot place anything. spacing_x: gap between columns, past the widest node in the left one. spacing_y: gap between nodes stacked in one column. origin: [x, y] for the top-left of the result. Defaults to the top-left of what is being arranged, so nothing wanders off. apply: write the positions. False computes and reports them without touching the canvas - the same dict can then be passed to set_workspace_layout. scope: "root" for the top level, "active" for the subgraph on screen. Not "all": a subgraph is a canvas of its own with its own coordinates, so there is no one layout that covers several. Use navigate_workspace to go in and arrange with "active". client_id: which tab to arrange; defaults to the most recently focused one.

Input Schema

TableJSON Schema

Name	Required	Default
`only`	No
`apply`	No
`scope`	No	root
`origin`	No
`client_id`	No
`spacing_x`	No
`spacing_y`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 13, 2026

TDQS

A5/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and meets it: it warns that arranged groups otherwise scatter into overlapping sheets, discloses that the result keeps its existing top-left corner, and explains that apply=False computes without touching the canvas. It also calls out the blunt behavior that every node it is given will be moved.

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 longer than average but earns its length: each paragraph covers one behavioral facet—layout rule, group handling, scope, and parameters—and the most important outcome is front-loaded in the first sentence. The prose examples clarify rather than pad.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, the absence of annotations, and the presence of an output schema, the description is complete: it explains the algorithm, group block behavior, node-scoped mode, coordinate meanings, apply vs report, scope constraints, and tab targeting. No critical operational question is left unanswered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it does: an Args section defines all seven parameters with meaningful semantics, e.g. origin defaults to the arranged content's top-left, client_id means the recently focused tab, and scope explains why 'all' is not supported. This goes far beyond bare parameter names.

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?

States a specific verb and resource: 'Lay the workflow out left to right, in the order the data flows through it.' The description explains the layout rule and the preserved corner, making it clear this is a data-flow-aware arrangement rather than a generic alignment tool.

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

Usage Guidelines5/5

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

Gives explicit when-to-use and when-not-to-use guidance: 'only' arranges just those nodes and leaves the rest alone, and scope is explicitly limited: 'Not "all"' with a pointer to navigate_workspace for subgraphs. It also directs users to set_workspace_layout when apply is False, naming the alternative path.

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

Install Server