Skip to main content
Glama
Sign In
gimp-mcp

gimp-mcp

by mhbxyz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Move layer in the stack

gimp_move_layer

Moves a layer or group to a new parent group or the image’s top level and sets its stack position, reordering the GIMP project without changing pixels or offsets.

Instructions

Move a layer or group to another parent (a group of the same image, or null for the top level) and position (0 = top-most). Does not change pixels or offsets. One undo step.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "item": "<item>",
      "parent": "<parent>",
      "position": "<position>"
    },
    "name": "gimp_move_layer"
  }
}

Input Schema

NameRequiredDescriptionDefault
itemYesItem id (layer, group, mask...) e.g. 'item:5@a1b2c3d4'.
parentYesGroup id to put the layer in; null for the top level of the image.
positionYesIndex within the parent, 0 = top-most (in front).

Output Schema

NameRequiredDescriptionDefault
xYesOffset of the layer's top-left corner in image pixels.
yYes
idYes
kindYes
maskYes
modeYesGIMP layer mode nick, e.g. 'normal', 'multiply'.
nameYesLayer name. GIMP keeps names unique within an image ('Title #1').
locksYes
widthYes
heightYes
parentYesId of the parent group, null at the top level.
opacityYes0-100.
visibleYes
childrenNoChild layers of a group, top-most first; null for non-groups.
has_alphaYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.6.0
    • changedOutput schema / $defs / LayerNode / properties / kind / enum
      Previous value: -[
-  "layer",
-  "group",
-  "text"
-]New value: +[
+  "layer",
+  "group",
+  "text",
+  "vector",
+  "link"
+]
    • changedOutput schema / properties / kind / enum
      Previous value: -[
-  "layer",
-  "group",
-  "text"
-]New value: +[
+  "layer",
+  "group",
+  "text",
+  "vector",
+  "link"
+]
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false), and the description adds real context beyond them: reparenting is the effect, pixels and offsets are untouched, null targets the image top level, and the whole operation collapses into one undo step. That undo granularity is genuinely useful behavioral disclosure; what is missing is any failure mode, such as moving a group into its own descendant.

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?

Three tight sentences, zero filler, with the core action and its scope front-loaded before the clarifying negatives. Every sentence carries information an agent needs.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description covers action, target, positioning, and side effects; only edge-case constraints (cyclic group nesting, cross-image rejection) are absent, which keeps it just below fully complete.

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 all three parameters are already documented, including '0 = top-most' and 'null for the top level'. The description restates those same semantics rather than adding new ones (e.g. how position interacts with the destination group's children), so the baseline 3 applies.

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 ('Move a layer or group') plus the two axes of the operation: parent and stack position. The clause 'Does not change pixels or offsets' explicitly separates it from siblings like gimp_set_layer_offsets and gimp_flip_layer, so an agent can route correctly 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?

The reparenting/positioning use case is clearly implied and the negative case (pixel/offset changes belong elsewhere) is stated. There is no explicit 'use X instead' routing or prerequisite note (e.g. same-image constraint is only hinted by 'a group of the same image'), so it stops short of full 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.

Deploy Server

Other Tools