gimp-mcp

Overview Schema Source Related Servers Discussions Admin

Create image

gimp_create_image

Create a new GIMP image with defined width, height, fill color, layer name, base type, and optional resolution; use transparent fill for an alpha layer.

Instructions

Create a new image with a single layer named layer_name filled with an explicit color (default white; 'transparent' gives an alpha layer). Like a new image in GIMP's UI, it starts without unsaved changes and without undo history. Shown in a window when GIMP has a UI.

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": {
      "width": "<width>",
      "height": "<height>"
    },
    "name": "gimp_create_image"
  }
}

Input Schema

Name	Required	Description	Default
`fill`	No	sRGB color as '#rrggbb', '#rrggbbaa', '#rgb' or one of: white, black, red, green, blue, transparent	white
`width`	Yes	Pixels.
`height`	Yes	Pixels.
`base_type`	No		rgb
`layer_name`	No		Background
`resolution`	No	Pixels per inch.

Output Schema

Name	Required	Description
`id`	Yes
`file`	Yes
`name`	Yes	GIMP's display name (may be localized).
`dirty`	Yes
`width`	Yes
`height`	Yes
`xcf_file`	Yes
`displayed`	Yes	True when a GIMP window shows the image (GUI sessions only).
`layer_count`	Yes	Number of top-level layers.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 7, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare non-read-only, non-destructive, non-open-world behavior, and the description adds real state semantics on top: no unsaved changes and no undo history at creation, plus a window being shown when a UI is present. It stops short of saying what identifier or handle is returned or what permissions/context the call requires.

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?

Three short sentences, front-loaded with the core behavior, with the fill default and transparency effect placed immediately after. Slight overlap with what the schema already documents for fill, but no filler.

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 simple creation tool with an output schema and full annotations, the description covers purpose, default state, and the notable transparent-fill case. Remaining gaps (base_type semantics, how the new image is identified after creation) are minor given the output schema.

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?

The description adds meaning for two of the six parameters: layer_name (naming the single created layer) and fill (default white, 'transparent' produces an alpha layer). At 67% schema coverage, base_type's rgb/gray semantics and its interaction with fill are explained in neither the schema nor the description, so it does not fully compensate for the gap.

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 states a specific verb and resource ('Create a new image') plus its exact result shape: one layer, named via layer_name, filled with a given color. This is enough to distinguish it from gimp_open_image (existing file) and gimp_create_layer (adding to an existing image) without opening any schema.

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: it reads as the entry point for a fresh canvas, but the description never says when to prefer it over gimp_open_image or gimp_import_layer. The note about 'new image in GIMP's UI' gives context but no explicit exclusions or alternatives.

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

Deploy Server