Skip to main content
Glama

auto_layout

Rearranges connector-joined shapes into a layered graph to clarify board structure and flow.

Instructions

Rearranges the shapes joined by connectors into a layered graph.

Input Schema

NameRequiredDescriptionDefault
pageNoPage: number (from 1) or name. Defaults to the first.
pathNoPath of the board file (.inkboard; .inkboard.json and .tableau.json also accepted). Optional when the application is open: the tool then acts live on the displayed board (undoable with Ctrl+Z).
directionNoDefault: TB.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden, yet it says nothing about the mutating side effects: that existing shape positions are overwritten, whether the change is undoable, or whether unconnected shapes are affected. The single sentence conveys the transformation type (layered graph with a direction) but omits the behavioral facts an agent needs before invoking a write operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tightly written sentence with the action and outcome front-loaded and zero filler. It is efficient, though its brevity contributes to the missing behavioral context rather than resolving it.

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

Completeness2/5

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

For a mutation tool with no annotations and no output schema, the description should cover side effects, scope (page vs selection vs connected subgraph), and reversibility. It covers none of these, leaving the agent to infer behavior from the sibling name arrange_objects and the schema alone.

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

Parameters3/5

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

Schema description coverage is 100%, so page, path and direction are already documented in the schema, including the live-edit/undo note for path and the TB default for direction. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (rearranges) and a specific target (shapes joined by connectors) plus an outcome (layered graph), which clearly separates it from positional siblings like move_objects or arrange_objects. It stops short of explicitly naming the sibling it competes with, so it is clear but not fully differentiated.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisite (e.g. does it operate on the whole page or only a selection?), and no mention of alternatives such as arrange_objects or move_objects. The usage is only inferable from the noun phrase 'shapes joined by connectors'.

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