Skip to main content
Glama

tidy_canvas

Rearranges all canvas widgets into a neat grid, matching the Tidy up button, and returns their new positions. Set grid width from 1 to 8 columns.

Instructions

Re-pack every widget on the canvas into a neat grid (same as the Tidy up button). Returns the new positions.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "tidy_canvas"
  }
}

Input Schema

NameRequiredDescriptionDefault
columnsNoGrid width in 300px columns, 1–8 (default 4).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.1

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations supplied, the description carries the full burden. It usefully discloses scope ('every widget') and that new positions are returned, which is valuable since there is no output schema. However, it does not say whether existing manual layout is destroyed, whether the operation is undoable, whether annotations/comments are affected, or whether any permission is required for a canvas-wide mutation.

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?

Two short sentences, front-loaded with the action and scope, followed by the return behavior. No filler, no restatement of the name.

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 one-optional-parameter bulk layout tool with no annotations and no output schema, the definition covers what it does and what it hands back. The remaining gap is side-effect disclosure — reversibility and impact on non-widget canvas elements — which would matter for an agent deciding whether to invoke it.

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% and the single 'columns' parameter is fully documented in the schema with range and default. The description adds no meaning about how column width interacts with widget sizing or how the grid is chosen, so the baseline 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 gives a specific verb and resource ('re-pack every widget on the canvas into a neat grid') and anchors it to a known UI action ('same as the Tidy up button'). It is clearly a bulk layout operation, distinguishable in spirit from place_widget or update_widget, though it never names or contrasts those siblings explicitly.

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

Usage Guidelines3/5

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

Usage is only implied: an agent can infer this is the tool for wholesale re-layout, and the 'Tidy up button' analogy helps. There is no explicit guidance on when to prefer this over place_widget for individual moves, nor any warning about when not to run it (e.g. a deliberately hand-positioned canvas).

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