Skip to main content
Glama

Paint: Manage layers

paint_layer

Manage layers on a named paint canvas: list, add, remove, select, move, merge, or set name, opacity, blend mode, and visibility by index.

Instructions

list | add | remove | select | move | merge | set (rename, opacity, blend, visible). Layers stack bottom→top; index 0 is the bottom one.

Target the canvas by name (created with paint_canvas) and optionally a layer index. Layers, filters and undo work the same for every drawing tool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoDestination index for move
nameNo
belowNoInsert below the active layer
blendNo
indexNo
actionYes
canvasYesCanvas name. Letters, digits, space, dot, dash, plus; the .png/.paint suffix may be included or omitted.
opacityNo
previewNoImage reply: auto/thumb = downscaled picture back into the result, full = unpixelated, none = text only
visibleNo
preview_sizeNoLongest edge of the returned thumbnail

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare the safety profile (readOnly=false, destructive=false, idempotent=false), so the description only needs to add context. It usefully discloses the stack ordering (index 0 is the bottom layer) and that layers, filters and undo behave uniformly across drawing tools, which is genuine behavioral information. It does not mention what 'remove' or 'merge' destroy or any permission/reversibility caveats for mutations.

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?

The action list is front-loaded and the remaining sentences are dense and information-bearing (ordering, canvas targeting, uniform behavior across tools). It is efficient overall, though the final sentence about filters and undo working the same everywhere is slightly tangential to a layer-management tool.

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

Completeness3/5

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

For an 11-parameter multi-action tool with no output schema, the description covers the action vocabulary and indexing but does not state per-action requirements (e.g., that move needs 'to', remove needs an 'index') or what 'list' returns. It is adequate but leaves the agent to infer which parameters pair with which action.

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?

Schema description coverage is only 45% (uncovered: name, blend, index, action, opacity, visible), so the description must compensate. It does so by mapping the 'set' action to its sub-parameters (rename, opacity, blend, visible) and by defining index semantics and layer ordering, adding real meaning beyond the bare schema types.

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 names the specific resource (layers) and enumerates the exact action verbs the tool supports: list, add, remove, select, move, merge, set. It separates itself from siblings like paint_canvas (which creates the canvas) and paint_filter/paint_undo while clarifying that layer state is the shared substrate. An agent can identify the tool's role without opening the schema.

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?

It tells the agent to target the canvas by name (created with paint_canvas) and optionally a layer index, and the action list effectively tells the agent which verb to pick. However, it never states when to prefer this tool over alternatives such as paint_ops or how layer actions interact with drawing tools, so it stops short of explicit when/when-not guidance.

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