What can you do with this server?

This server is an MCP bridge that lets an LLM control GIMP 3 locally for image editing, file management, and advanced features like semantic vision. Session & Status: * Check connection (gimp_status), get capabilities/limitations (gimp_capabilities), list open images, get active image, and retrieve image info. File Operations: * Open local images, create new RGB/GRAY/INDEXED images, save as XCF (with overwrite), export to formats by extension (non-overwriting by default), and close images (explicit discard for dirty). Layer Management: * List layers, get layer info, create/duplicate/rename/delete layers, set visibility/opacity/mode, move layers (including into groups), and merge down. Image Transforms: * Resize image (scale), resize canvas (without scaling), crop, rotate (90/180/270), and flip (horizontal/vertical). Selection: * Select all, none, invert, rectangle, ellipse, and layer alpha. Adjustments & Undo: * Brightness/contrast, hue/saturation, desaturate, undo, and redo. Non-destructive Filters: * Apply Gaussian blur and brightness/contrast as GEGL filters. Layer Masks & Subject Isolation: * Get mask info, create/enable masks, isolate subject (high-key or border), isolate via vision (isolate_subject_vision), and separate subject/concepts to layers. Optional Local Vision: * Check vision status, segment subject by prompt, use CLIPSeg or SAM3 workers for prompt-based masks (no cloud). PDB Interaction: * Search procedures, describe metadata, and invoke PDB procedures with structured JSON arguments. Developer Tools: * Run doctor to check server configuration and GIMP connection.

Which integrations are available for this server?

Provides tools for controlling GIMP 3 locally, including image and layer management, transforms, selections, adjustments, and PDB procedure invocation.

How do I use gimp-local-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gimp-local-mcp Open the last image and export it as PNG at 1920px wide" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

gimp-local-mcp

by epi13

Overview Schema Source Related Servers Discussions Admin

Python

Local

GIMP Local MCP

GIMP Local MCP is a local-first Model Context Protocol server for controlling GIMP 3 through an LLM. The LLM chooses an operation through structured MCP calls; GIMP owns the image manipulation, rendering, file loading, and exporting. Images and files remain on the user’s machine.

This v0.1 implementation favors a small, composable architecture over hundreds of one-off wrappers.

Philosophy

GIMP owns pixels. This project does not generate replacement pixels or call cloud image services.
Routine edits use ergonomic tools with stable image and layer IDs.
The live GIMP PDB is the long-term path to broad coverage, with structured invocation rather than raw Scheme input.
File writes are explicit and never overwrite existing targets by default.
The bridge preserves GIMP’s undo history and groups multi-step operations when the operation needs multiple PDB calls.

Related MCP server: gimp-mcp

Architecture

Natural language
      |
      v
MCP host (Codex, Claude, custom client)
      |
      | MCP stdio / JSON-RPC
      v
gimp-local-mcp
  ergonomic tools ---> GimpService ---> safe Scheme serializer
                              |                  |
                              +--> PDB catalog/invoker
                              +--> structured GEGL filter gateway
                              +--> VisionClient ---> trusted local JSONL worker
                                                   |
                                                   v
                                    Script-Fu TCP framing (127.0.0.1:10008)
                                                   |
                                                   v
                                             GIMP 3 Script-Fu server

The official MCP Python SDK is used for the server. Script-Fu socket and framing logic is isolated in gimp/transport.py and gimp/protocol.py; tool functions do not manipulate sockets directly.

Requirements

Python 3.10 or newer
GIMP 3.x
A running GIMP 3 Script-Fu server

GIMP is not required for the ordinary unit test suite.

GIMP 3 setup

Start GIMP 3.
Open Filters → Development → Script-Fu → Start Server.
Keep the listener on 127.0.0.1 and port 10008 unless you have a specific reason to change it.
Start the MCP server after the Script-Fu server is listening.

GIMP’s Script-Fu server accepts a three-byte G/16-bit-length request frame and returns a four-byte G/error/16-bit-length response frame. GIMP allows one Script-Fu client at a time; this server maintains one reconnectable client connection.

Installation

From a checkout:

python -m pip install -e '.[dev]'

For a runtime-only installation:

python -m pip install .

Run the server

gimp-local-mcp serve

With no subcommand, gimp-local-mcp also starts the stdio MCP server. Stdout is reserved for MCP protocol traffic; diagnostics go to stderr.

Check the local connection independently:

gimp-local-mcp doctor

doctor prints Python details, the configured endpoint, local-only status, Script-Fu reachability, GIMP version, and open-image count. A connection refusal is expected until GIMP’s Script-Fu server is started.

Codex configuration

Add a project-local MCP entry in the Codex configuration used for this checkout. The exact location depends on the Codex client version; do not modify global configuration automatically.

[mcp_servers.gimp-local-mcp]
command = "gimp-local-mcp"
args = ["serve"]

If the command is not on the client’s PATH, use the absolute path to the virtual-environment executable or launch it with Python:

[mcp_servers.gimp-local-mcp]
command = "python"
args = ["-m", "gimp_local_mcp.cli", "serve"]

Configuration

Defaults work with a standard local GIMP setup:

Environment variable	Default	Meaning
`GIMP_MCP_HOST`	`127.0.0.1`	Script-Fu host
`GIMP_MCP_PORT`	`10008`	Script-Fu port
`GIMP_MCP_TIMEOUT`	`10`	TCP operation timeout in seconds
`GIMP_MCP_LOG_LEVEL`	`INFO`	stderr log level
`GIMP_MCP_MAX_RESPONSE_BYTES`	`65535`	bounded response body size
`GIMP_MCP_ALLOW_REMOTE`	`false`	explicit opt-in for non-loopback hosts
`GIMP_MCP_VISION_PROVIDER`	`none`	optional trusted local provider name, such as `clipseg`
`GIMP_MCP_VISION_COMMAND`	unset	trusted local worker command; never an MCP argument
`GIMP_MCP_VISION_TIMEOUT`	`60`	local worker response timeout in seconds, capped at 600
`GIMP_MCP_VISION_DEVICE`	`auto`	provider device policy: `auto`, `cpu`, or `cuda`

Remote connections are rejected unless GIMP_MCP_ALLOW_REMOTE=true is set. Localhost-only operation is the secure default.

MCP tools

The current server registers 57 tools across these groups:

Session: gimp_status, gimp_capabilities, list_open_images, get_active_image, get_current_context, get_image_info
Files and images: open_image, create_image, save_xcf, export_image, close_image
Layers: list_layers, get_layer_tree, get_layer_info, get_selected_layers, set_selected_layers, create_layer, create_layer_group, duplicate_layer, rename_layer, delete_layer, set_layer_visibility, set_layer_opacity, set_layer_mode, move_layer, merge_down
Transforms: resize_image, resize_canvas, crop_image, rotate_image, flip_image
Selection: select_all, select_none, invert_selection, select_rectangle, select_ellipse, select_layer_alpha
Masks and subject isolation: get_layer_mask_info, create_layer_mask, set_layer_mask_enabled, isolate_subject, isolate_subject_vision, separate_subject_to_layers, separate_concepts_to_layers
Optional local vision: vision_status, segment_subject
Adjustments and undo: brightness_contrast, hue_saturation, desaturate, undo, redo
Non-destructive filters: apply_gaussian_blur_filter, apply_brightness_contrast_filter, list_drawable_filters
PDB: search_pdb, describe_pdb_procedure, invoke_pdb_procedure

invoke_pdb_procedure accepts JSON-compatible structured values, including { "scheme_symbol": "RGB" } for a GIMP enum. It does not accept Scheme source, Python, shell commands, or arbitrary evaluation. Runtime PDB counts and documentation are used when available. Procedure descriptions now include a bounded typed-metadata state (available, partial, unavailable, or malformed) plus argument/return records when a trusted structured adapter reports them. The default Script-Fu TCP adapter reports argument metadata as unavailable because Script-Fu does not expose a stable GimpProcedure/GParamSpec representation; no signatures or types are guessed. Named-argument validation is performed only when trustworthy names are actually available.

GIMP 3 also exposes non-destructive drawable filters through special Script-Fu bindings rather than ordinary PDB procedures. The filter gateway uses the documented gimp-drawable-append-new-filter binding with structured named GEGL properties, then reads the actual filter ID and state back through GIMP. The current high-level slices are Gaussian blur and brightness/contrast; they preserve the existing destructive adjustment tool names.

Layer masks use a reusable gateway over the GIMP bindings gimp-layer-create-mask, gimp-layer-add-mask, gimp-layer-get-mask, and the mask state accessors. Existing masks are reported and never replaced by the public creation tool. isolate_subject duplicates the explicit source layer, measures the perimeter, and seeds a contiguous-color background selection from either light perimeter samples or all perimeter samples when high-key evidence is strong. It inverts that selection into a mask and leaves the source layer intact. The operation returns baseline and refined observable mask proxies: border transparency, transparent and opaque proportions, partial-alpha proportion, edge-transition samples, a sampled retained bounding box, and retention relative to the baseline's confident samples. These are not semantic accuracy scores.

Optional local semantic vision

Semantic vision is deliberately out of process. VisionClient speaks a bounded JSONL protocol to a trusted command configured by the operator; the core installation does not install PyTorch, CUDA, Transformers, SAM, or model weights. A worker returns structured candidates and lossless grayscale PNG mask artifacts. Diagnostics go to worker stderr, while protocol traffic remains stdout-only.

CLIPSeg through tools/vision/clipseg_worker.py remains the lightweight fallback. It supports local free-text concept masks and fits CPU-only systems much better than SAM 3. It loads checkpoints with local_files_only=True during ordinary operation; downloading is a separate explicit setup step. tools/vision/sam3_worker.py is now an adapter for the official Meta SAM 3 image API. It supports the official text and positive-box grounding paths, multiple scored masks, and boxes only after a real checkpoint self-test succeeds. Point prompting belongs to SAM 3's separate interactive predictor and is not claimed by this adapter. No normal request downloads a checkpoint.

Create a separate provider environment; this does not change pip install .:

python3.13 -m venv .venv-vision
.venv-vision/bin/python -m pip install --upgrade pip
.venv-vision/bin/python -m pip install torch --index-url https://download.pytorch.org/whl/cpu
.venv-vision/bin/python -m pip install transformers accelerate pillow psutil
.venv-vision/bin/python tools/vision/clipseg_worker.py --download-model

export GIMP_MCP_VISION_PROVIDER=clipseg
export GIMP_MCP_VISION_COMMAND="$PWD/.venv-vision/bin/python $PWD/tools/vision/clipseg_worker.py"
export GIMP_MCP_VISION_DEVICE=auto
export GIMP_MCP_VISION_OFFLOAD=auto
export GIMP_MCP_VISION_GPU_RESERVE_MIB=256
export GIMP_MCP_VISION_DTYPE=auto
export GIMP_MCP_VISION_TIMEOUT=120
gimp-local-mcp doctor

CLIPSeg converts its coarse semantic logits into a soft mask with conservative defaults of 0.2 for the probability threshold and 2.0 for the sigmoid slope. Operators can tune those generic controls with GIMP_MCP_CLIPSEG_MASK_THRESHOLD (0.01–0.99) and GIMP_MCP_CLIPSEG_MASK_SLOPE (0.25–8.0). Higher thresholds reject weaker surrounding regions; higher slopes make the transition firmer. These settings refine a semantic mask but do not turn it into a fur/hair alpha matte.

Device and offload are separate policies:

GIMP_MCP_VISION_DEVICE=auto|cpu|cuda chooses the execution device.
GIMP_MCP_VISION_OFFLOAD=auto|none|sequential-cpu controls weight placement.
GIMP_MCP_VISION_GPU_RESERVE_MIB preserves dynamic headroom from the free VRAM measured at worker startup. GIMP_MCP_VISION_MAX_VRAM_MIB can impose an optional planning cap.
GIMP_MCP_VISION_DTYPE=auto|float32|float16|bfloat16 accepts reduced precision only after a real execution probe. AUTO remains FP32 on Pascal-class GPUs without Tensor Cores.

AUTO first executes an actual CUDA matmul; discovery alone is insufficient. It subtracts the configured reserve from current free VRAM and uses full CUDA only when estimated model storage plus workspace fits. Otherwise it uses Hugging Face Accelerate's cpu_offload when the provider supports it, or CPU. Sequential CPU offload keeps primary parameter storage in system RAM, attaches layer-wise execution hooks, moves parameters to CUDA as their modules execute, and removes them after use. It lowers persistent VRAM residency but does not lower system-RAM requirements. Disk offload is a separate slower tradeoff and is intentionally not the default.

AUTO has a bounded OOM path: full CUDA may retry sequential offload, then CPU; explicit device and offload selections fail instead of silently violating operator intent. Vision completes before any document mutation, so provider OOM cannot leave partial GIMP edits. doctor reports the placement reason, CUDA kernel probe and compiled architectures, startup free VRAM, reserve/budget, Torch allocated/reserved peaks, process RSS, and evidence from Accelerate hooks and persistent parameter devices. Torch allocator peaks and nvidia-smi process usage are different measurements.

For an explicit official SAM 3 setup, install Meta's package according to its prerequisites, obtain access to the gated checkpoint, authenticate outside MCP, and run:

.venv-sam3/bin/python tools/vision/sam3_worker.py --download-checkpoint
export GIMP_MCP_SAM3_CHECKPOINT=/absolute/path/printed/by/setup/sam3.1_multiplex.pt
export GIMP_MCP_VISION_PROVIDER=sam3
export GIMP_MCP_VISION_COMMAND="$PWD/.venv-sam3/bin/python $PWD/tools/vision/sam3_worker.py"

The worker passes load_from_HF=False to the official builder during normal operation and reports unavailable if the explicit file is absent. Use the bounded comparison command for one provider and input across placements:

python tools/vision/provider_check.py \
  --benchmark cpu,full-cuda,sequential-cpu-offload,auto

segment_subject(image_id, layer_id, prompt="red fox") snapshots a duplicate of the current GIMP image to a uniquely named temporary PNG, invokes the local worker, validates candidate artifacts, and removes the snapshot and artifacts after returning bounded summaries. It does not mutate the document. isolate_subject_vision uses the same bridge, duplicates the explicit source layer, imports the mask through a temporary RGBA layer/selection, and attaches it through the existing layer-mask gateway. isolate_subject(strategy="auto", prompt="red fox") prefers a capable semantic worker and falls back to the existing high-key contiguous-color strategy when no provider is available. Explicit high-key-background and border-color retain the heuristic.

separate_subject_to_layers(image_id, layer_id, prompt="red fox") leaves a persistent group with Subject — red fox and Background, hides but does not modify the original source, and selects the subject layer. The background mask is the exact 8-bit complement of the subject/foreground-union artifact; both layers use duplicates of the source. separate_concepts_to_layers accepts up to eight concepts, preserves distinct provider instances when returned, bounds the total generated layers to 24, reports mask overlap without assigning ownership, and derives the remainder from the soft-alpha foreground union. Provider failures happen before GIMP mutation; mask-import failures roll back generated layers, the group, source visibility, and selected-layer state.

GIMP 3.2 stores imported partial mask samples in its image-space encoding. In live validation, complementary 128/127 artifact values read back near 188/187; after decoding to linear alpha their sum was 1.0 within 0.005. Binary endpoints remained exact. This is reported as bridge behavior and is not described as learned matting.

The current refinement boundary is IdentityMaskRefiner: provider output is retained, but this is not learned alpha matting. CLIPSeg emits a coarse semantic probability mask; SAM 3 emits binary segmentation masks. Semantic/object discovery, segmentation, optional future edge/alpha refinement, artifact validation, and GIMP mask creation remain distinct stages. Coverage, border transparency, partial-alpha, edge-transition, and sampled bounding-box values are observable proxies only. The fox-on-snow benchmark has no ground-truth alpha matte, so confidence and proxy metrics must not be presented as accuracy.

On the prior 1280×960 fox benchmark, the cached CLIPSeg model reported about 603 MB of parameter storage and completed CPU inference in 0.49 seconds after a 12.66-second cold load. The new placement comparison used the same deterministic 32×32 image/prompt on the P620 with PyTorch 2.7.1+cu126 and 128 MiB reserve. CPU/full-CUDA/sequential inference took 0.272/0.178/0.307 seconds. Full CUDA peaked at 660,646,912 allocated and 687,865,856 reserved bytes; sequential offload peaked at 131,516,416 allocated and 146,800,640 reserved bytes, an 80.1% lower allocated peak. The offload run had 233 hooks, 602,990,984 meta/CPU-backed parameter bytes, zero persistent CUDA parameter bytes, and sequential_offload_verified=true. Full CUDA retained all 602,990,984 parameter bytes on CUDA. Both CUDA placements produced identical masks; compared with CPU, mean absolute difference was 0.00098 on the 8-bit mask and maximum difference was one level. Sequential RSS was higher (about 1.71 GiB) because offload trades VRAM for system RAM. These are one-machine observations, not performance guarantees.

For document navigation, start with get_current_context. It returns the open image IDs, a current-image snapshot when one can be established, the resolution source, and all selected layer IDs. GIMP 3 uses multi-layer selection, so get_selected_layers returns a list rather than inventing a single active layer. get_layer_tree recursively reports groups and children with stable IDs, parent IDs, positions, and bounded recursion/item limits. The Script-Fu server does not always expose a default-display context; when exactly one image is open, the service reports single-open-image as an explicit fallback, and it reports multiple open images as ambiguous instead of guessing.

Example requests

“Open this image and crop it to 16:9 around the subject.”
“Duplicate the background layer, desaturate it, and reduce its opacity to 40%.”
“Resize this to 2048 pixels wide while preserving aspect ratio.”
“Export a JPEG copy at this path without overwriting anything.”
“What layers are currently in this document?”
“Separate the red fox from the background and leave both on editable layers.”
“Separate the fox, trees, and snowbank into layers and report any overlap.”
“Find a GIMP procedure capable of applying Gaussian blur and describe its arguments.”

The final request is supported through PDB search and description; the current description reports procedure counts, documentation, and the explicit argument-metadata capability state. Rich argument records remain unavailable through the default Script-Fu bridge until a live, trustworthy adapter is available.

Security model

See SECURITY.md. In brief:

the MCP server is stdio-first and connects to loopback by default;
no shell, Python eval, raw Script-Fu MCP tool, or cloud image API exists;
procedure names and structured values are validated before serialization;
strings and paths are escaped as Scheme literals;
output paths must be explicit, normalized, and non-overwriting unless requested;
closing a dirty image requires an explicit discard choice.

Limitations

Live validation in this iteration used GIMP 3.2.0 on the default loopback endpoint 127.0.0.1:10008. Other GIMP 3 versions still need compatibility validation.
On the tested GIMP 3.2.0 Script-Fu environment, the legacy gimp-pdb-query and gimp-pdb-proc-exists helper bindings are unavailable. The typed PDB adapter therefore retains its explicit unavailable fallback; the filter bindings are validated independently. A future bridge adapter should use a supported GIMP-side PDB or GObject-introspection channel rather than guessing signatures.
Export metadata behavior uses GIMP’s configured defaults in v0.1; no hidden metadata is added or removed.
The tested GIMP 3.2.0 Script-Fu bridge does not expose gimp-file-export; export_image refuses to fall back to gimp-file-save, which could change the open document's associated file. Use GIMP's own export UI until a supported export binding is available.
The initial adjustment tools call stable legacy PDB adjustment procedures that GIMP 3.2 marks deprecated in favor of non-destructive filters. Only brightness/contrast and Gaussian blur have non-destructive high-level slices so far.
Native foreground extraction is unavailable through the tested GIMP 3.2.0 Script-Fu bridge. CLIPSeg is genuinely text-prompted but produces a coarse 352×352 semantic probability mask; upsampling can leave halos, soften fur, omit thin whiskers, or retain nearby regions. It does not separate instances or discover/language-label every object. Without a capable worker, auto retains the bounded high-key fallback.
The tested GIMP 3.2.0 bridge safely supports duplicate-image PNG snapshots through gimp-image-duplicate plus gimp-file-save on the duplicate. The unsafe save fallback remains prohibited for user images. The mask import bridge preserves partial alpha observed through GIMP's selection-to-mask path, but GIMP image-space mask encoding changes the raw sampled byte values for partial alpha. This is not a learned hair/fur-matting engine.
Independently prompted concept masks can overlap. The default and currently supported policy is report: layers retain their masks, overlap statistics are returned, and remainder background uses their soft union. No arbitrary first-concept ownership is imposed.
The Quadro P620 probe found compute capability 6.1 and 2 GiB total VRAM, with about 1.06 GiB free under KDE/Wayland during this iteration. The official PyTorch 2.10+cu128 wheel discovered CUDA but omitted sm_61, so its real kernel probe failed with no kernel image. PyTorch 2.7.1+cu126 includes sm_60 and completed real FP32, FP16, and BF16 matmuls. Wheel architecture support must be checked for this Pascal GPU; a newer version number is not evidence of compatibility.
Official SAM 3.1 requires gated checkpoint access. The adapter and explicit setup path are implemented, but this run had no authenticated Hugging Face account or local checkpoint, so no SAM inference or offload claim is made. Import success alone is not provider support.
get_active_image uses GIMP’s default display when the Script-Fu context provides one. If that helper is unavailable and exactly one image is open, it returns that image with the same documented single-image fallback used by get_current_context; multiple open images remain ambiguous.
Selected-layer control and recursive group inspection were validated against GIMP 3.2.0. The bridge rejects empty selection vectors, validates layer/image ownership, and reads selection state back after setting it.
Multi-call layer creation and duplication are grouped into one GIMP undo step. Additional composite operations should adopt the same internal helper as they are added.

Roadmap

Validate the high-level vertical slices against additional GIMP 3.x releases and platforms.
Add a supported GIMP-side structured PDB metadata adapter for argument names, types, defaults, and enum choices; keep the explicit unavailable fallback when the bridge cannot provide it.
Add structured non-destructive GEGL filter operations for levels, curves, and hue/saturation.
Validate document context and multi-layer selection semantics against additional GIMP 3.x releases and multi-window setups.
Add explicit export metadata policies and more file-format option models.
Add safe, persistent capability caching with GIMP version invalidation.
Validate official SAM 3.1 text, box, multi-instance, activation-memory, and Accelerate hook behavior with an authorized local checkpoint; add provider-specific preload hooks only if the measured module access pattern requires them.
Add a local alpha-matting provider behind MaskRefiner when a supported lightweight runtime is available; keep semantic segmentation and matting evidence separate.
Implement automatic object proposals with stable unlabeled candidate IDs, boxes, areas, and previews before adding any semantic labels not produced by a model.

Development

ruff format src tests
ruff check src tests
pytest -q

Live tests are marked integration and skip when 127.0.0.1:10008 is unavailable. See CONTRIBUTING.md and AGENTS.md for repository invariants.

Forge development evidence

The committed mncs-forge.toml declares a project-owned Provider Protocol 0.1 provider in tools/forge_provider.py. It parses fixed Ruff, pytest, pip, and live-GIMP checks into explicit PASS/FAIL/UNKNOWN responses. In particular, a skipped live integration test is UNKNOWN. Forge runtime ledgers and .mncs-forge/ state remain local and are intentionally not committed. The provider disables Python bytecode writes in its subprocesses so normal checks do not mutate the Forge candidate scope with generated __pycache__ files.

Available Tools

40 tools

brightness_contrastC

Apply the basic brightness/contrast adjustment to a drawable.

ParametersJSON Schema

Name	Required	Description	Default
`contrast`	Yes
`layer_id`	Yes
`brightness`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations provided, the description must fully disclose behavioral traits. It only states the action without revealing whether the adjustment modifies the drawable in place, is destructive, or has any side effects. There is no mention of reversibility or selection handling, which is expected for a filter tool.

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?

The description is a single, efficient sentence that immediately conveys the core action. There is no redundancy or filler, making it easy to parse.

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?

Given the simple nature of the tool, the description is still incomplete. It omits essential parameter details and behavioral context, and the presence of an output schema does not compensate for the lack of explanation about how the adjustment behaves or what the output represents.

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

Parameters1/5

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

Schema coverage is 0%, and the description provides no explanation of the parameters brightness, contrast, or layer_id. It does not mention units, ranges, or the meaning of these values, leaving the agent to guess the semantics solely from the schema's bare names.

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 clearly states the verb 'Apply' and the resource 'basic brightness/contrast adjustment to a drawable'. It is specific enough to distinguish from sibling tools like hue_saturation and desaturate, though it relies on the name for that differentiation rather than explicit wording.

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?

The description provides no guidance on when to use this tool versus alternatives such as hue_saturation or desaturate. It neither states usage context, prerequisites, nor exclusions, leaving the agent without direction.

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

close_imageA

Close an image; dirty images require an explicit discard=true.

ParametersJSON Schema

Name	Required	Description	Default
`discard`	No
`image_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description must convey behavior. It discloses a key behavior (dirty images require discard=true), which is useful. However, it does not mention side effects, error behaviors (e.g., what happens if an image is dirty and discard is false), or whether the operation is destructive. The disclosure is partial but adds value.

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?

The description is a single, front-loaded sentence. It immediately states the action, then adds the necessary condition. No wasted words; it earns its place.

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 a simple two-parameter tool with an output schema, the description covers the core behavior (close and discard condition). However, it omits handling of non-dirty images, error cases, and does not explicitly reference the image_id parameter. The tool is low complexity, but the description could be more 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?

The input schema has no descriptions (0% coverage), so the description must explain parameters. It explains 'discard' in the context of dirty images, adding meaningful semantics. 'image_id' is not mentioned but is self-explanatory from its name and context. The description partially compensates for the lack of schema descriptions.

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 clearly states the action ('Close an image') with a specific verb and resource. It distinguishes itself from sibling tools (e.g., list_open_images, get_active_image) by focusing solely on the close operation. The additional detail about discard makes the purpose unambiguous.

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?

The description provides a conditional usage hint: dirty images need discard=true. However, it does not explicitly state when to use this tool versus alternatives or any exclusions. It is implied that closing is for dismissing an image, but no direct comparison to other operations is given.

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

create_imageA

Create a new RGB, GRAY, or INDEXED image.

ParametersJSON Schema

Name	Required	Default
`width`	Yes
`height`	Yes
`base_type`	No	RGB

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the image types but does not mention side effects such as creating a new active document, adding to the image stack, or any required conditions. This is a thin description for a mutation tool.

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?

The description is a single, direct sentence with no wasted words. It front-loads the purpose and delivers the key variation (image types) efficiently.

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?

Given the tool's low complexity (3 parameters), the description is almost sufficient. It defines the action, the target, and the value domain for the optional parameter. The presence of an output schema reduces the need to explain return values. However, it's still slightly sparse compared to the richness implied by the sibling operations, but adequate for basic invocation.

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 input schema has no per-parameter descriptions (0% coverage), so the description must compensate. It partially does by enumerating valid values for base_type ('RGB, GRAY, or INDEXED'), but width and height remain unstated. This adds some meaning over the schema but leaves gaps.

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 'Create a new RGB, GRAY, or INDEXED image' clearly states the action (create) and resource (image), and specifies the supported image types. This distinguishes it from sibling tools like list_open_images, get_active_image, and open_image, which handle existing images rather than creating new ones.

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?

The description implies when to use the tool (when a new blank image is needed) but provides no explicit guidance about alternatives or exclusions. It does not mention that open_image or other creation-adjacent tools could be used for different purposes, so guidance is left to inference.

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

create_layerC

Create a transparent RGBA layer at the top of an image.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`width`	No
`height`	No
`opacity`	No
`image_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

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 must carry the burden of behavioral disclosure. It mentions 'transparent RGBA' and 'top of an image', hinting at color mode and position, but does not disclose side effects such as whether the new layer becomes active, how dimensions default, or any image mode prerequisites. This is minimal and incomplete.

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

Conciseness3/5

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

The description is one sentence and starts with the action, making it concise. However, it is under-specified, repeating the basic idea conveyed by the tool name without adding sufficient detail. It is efficient but lacks depth.

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?

With five parameters, no annotations, and no schema descriptions, the description needs to provide significant context. It only covers the basic action, omitting parameter semantics, behavioral effects, and usage scenarios. The output schema exists but does not compensate for the missing operational context.

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

Parameters1/5

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

Schema description coverage is 0%, so the description must compensate by explaining parameters. It does not mention any of the five parameters (name, width, height, opacity, image_id), leaving their meaning and behavior entirely unexplained. The agent cannot infer the role of each parameter from the description.

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 clearly states the action (create), the resource (a layer), and the specifics (transparent RGBA, at the top of an image). This distinguishes it from sibling tools like duplicate_layer or rename_layer.

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?

The description implies when to use the tool: when you need a new transparent layer on top. However, it does not explicitly mention when not to use it or compare it to alternatives like duplicate_layer or move_layer. The context is clear but not explicit.

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

crop_imageB

Crop an image to the supplied rectangle.

ParametersJSON Schema

Name	Required	Description	Default
`width`	Yes
`height`	Yes
`image_id`	Yes
`offset_x`	No
`offset_y`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/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 of behavioral disclosure. It does not state whether the crop modifies the image in place, creates a new image, or how offsets affect the result. This leaves the operation's safety and side effects unclear.

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?

The description is a single concise sentence with no superfluous words. It is appropriately short, though under-specified in other dimensions.

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?

Given 5 parameters and no annotations or schema descriptions, the description is inadequate for correct usage. It does not explain how the rectangle is defined or whether the operation targets the image identified by image_id.

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

Parameters2/5

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

The schema has 0% description coverage, and the description only vaguely refers to a 'supplied rectangle' without explaining the roles of width, height, offset_x, and offset_y. The agent must infer the parameter semantics from names alone.

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 uses a specific verb 'crop' and resource 'image', and the phrase 'supplied rectangle' indicates the operation scope. It clearly distinguishes from sibling tools like resize_image or rotate_image.

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?

No guidance is provided on when to use crop_image versus alternatives like resize_image or select_rectangle. The description does not mention any prerequisites or exclusions.

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

delete_layerB

Delete a layer from an image.

ParametersJSON Schema

Name	Required	Description	Default
`image_id`	Yes
`layer_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states 'Delete' without mentioning whether the deletion is permanent, if it can be undone, or any side effects on the image or other layers.

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?

The description is a single, concise sentence with no redundant words. It is front-loaded and clearly states the core action, making it efficient and appropriately sized for a simple tool.

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 simple destructive tool with two parameters and no annotations, the description is too sparse. It lacks usage context, side effects, and any indication of what the tool returns, making it minimally adequate but not complete.

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

Parameters2/5

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

The input schema has two parameters (image_id and layer_id) with 0% schema description coverage. The description does not add any meaning to these parameters, such as how to obtain valid IDs or any constraints beyond the types already specified in the schema.

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 'Delete a layer from an image' clearly specifies the verb (delete), the resource (layer), and the context (from an image), distinguishing it from sibling tools like duplicate_layer or rename_layer.

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?

No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., the layer must exist), nor does it advise caution about the destructive nature of the operation.

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

desaturateC

Desaturate a drawable using a GIMP desaturation mode.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No		DESATURATE-LUMA
`layer_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.7/5.0

Behavior2/5

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

There are no annotations, so the description carries full responsibility for disclosing behavior. It does not state whether the operation modifies the layer in place, whether it is reversible, or any side effects. For a mutation tool, this is a notable gap.

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 description is a single concise sentence that efficiently states the core action. While it lacks detail, it does not waste words and is front-loaded with the key verb and object.

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?

The tool is simple, but the description is too thin to be complete. It provides no context about return values (output schema exists but is not described in prose), no mention of undo behavior, and no hint about the mode parameter options. The level of completeness is minimal for a tool with this schema.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It mentions 'mode' indirectly but does not enumerate possible values or explain the layer_id parameter. The description adds minimal meaning beyond the schema's property names.

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 clearly states the function: to desaturate a drawable using a GIMP desaturation mode. The verb 'desaturate' and resource 'drawable' are specific, and mentioning 'GIMP desaturation mode' ties it to GIMP's method, distinguishing it from sibling tools like brightness_contrast or hue_saturation.

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?

No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or cases where another tool (e.g., hue_saturation) would be more appropriate. The usage context is not clarified beyond the basic operation.

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

describe_pdb_procedureA

Describe a live GIMP PDB procedure using runtime metadata.

ParametersJSON Schema

Name	Required	Description	Default
`procedure_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/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 of disclosing behavior. It only states that the tool 'describes' a procedure, which implies a read-only operation, but it does not mention error handling for unknown procedures, dependence on a running GIMP instance, or any other behavioral traits. This is minimal disclosure.

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?

The description is a single, concise sentence that immediately conveys the tool's purpose. It is front-loaded and contains no filler, making it efficient and easy to parse.

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?

The tool is simple with one parameter and an output schema, but the description does not specify prerequisites (e.g., GIMP must be running), how it relates to sibling tools like invoke_pdb_procedure, or what is returned. The output schema likely covers return values, but the description lacks broader context that would aid an agent in deciding to use this tool.

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 schema has a single required parameter, procedure_name, with no description and 0% schema coverage. The tool description says it describes a GIMP PDB procedure, which clearly implies that procedure_name is the name of the procedure to describe. While the tool description adds some context, it does not specify format or naming conventions, relying on the parameter's obvious intent.

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 clearly states the tool's function: 'Describe a live GIMP PDB procedure using runtime metadata.' It uses a specific verb ('Describe') and a clear resource ('live GIMP PDB procedure'), and the addition of 'runtime metadata' distinguishes it from other PDB-related tools like search_pdb or invoke_pdb_procedure.

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?

The description implies this tool is used to obtain metadata about a PDB procedure, but it does not explicitly state when to use it over alternatives like search_pdb or invoke_pdb_procedure. There is no mention of exclusions or prerequisites, leaving the usage context somewhat inferred.

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

duplicate_layerA

Duplicate a layer and insert the copy at the top of the image.

ParametersJSON Schema

Name	Required	Description	Default
`image_id`	Yes
`layer_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of disclosure. It notes that the copy is inserted at the top but does not explicitly state that the original remains unchanged or describe other side effects like attribute copying or naming. Basic behavior is disclosed, but details are lacking.

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?

The description is a single, well-structured sentence that front-loads the action and result. It contains no redundant or unnecessary information.

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 a simple two-parameter operation with an output schema, the description covers the core behavior and placement. However, it omits prerequisites (e.g., layer must exist) and does not explicitly mention that it's a mutating operation, although 'duplicate' implies creating a new layer. It is adequate but minimal.

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

Parameters2/5

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

The input schema has no descriptions, and the tool description does not explain the roles of image_id and layer_id. It merely says 'a layer' without clarifying which image contains it or what the IDs refer to. With 0% schema coverage, the description fails to compensate for the missing parameter information.

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 clearly identifies the action (duplicate), the resource (layer), and the outcome (insert copy at top). It distinguishes this tool from siblings such as create_layer and move_layer by specifying the duplication and placement.

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?

The description implies when to use the tool (when you need a copy of an existing layer) but does not explicitly compare it with alternatives or state when not to use it. The usage context is inferred rather than stated.

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

export_imageB

Export an image using the format selected by the explicit file extension.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`image_id`	Yes
`overwrite`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description carries full responsibility for disclosing behavior. It does mention the key behavior of format selection via extension, but it omits other important traits such as overwrite behavior, potential error conditions, or whether the image must be open. The description provides minimal transparency beyond the format mechanism.

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?

The description is a single sentence that is front-loaded with the core action and format-determining detail. Every word earns its place, with no filler or redundancy.

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?

Given the tool has three parameters, no annotations, and an output schema, the description is adequate for a simple export operation but lacks context on prerequisites, alternative tools, and behavior on overwrite. It provides the essential behavior but leaves gaps for the agent to infer from schema or siblings.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate by explaining parameters. It does not mention image_id, path, or overwrite directly, though the phrase 'explicit file extension' hints that the path should include the desired extension. This minimal hint adds little meaning beyond the schema's field names.

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 'Export an image using the format selected by the explicit file extension' uses a specific verb and resource, clearly stating the tool exports an image. It also distinguishes this tool from siblings like save_xcf by highlighting that the format is determined by the file extension, which is a key differentiating detail.

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?

The description implies usage for exporting to a format chosen by the file extension, but it does not explicitly compare to alternatives like save_xcf or state when not to use this tool. There is no direct exclusion or mention of other save/export tools, so guidance is only implied rather than explicit.

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

flip_imageA

Flip an image HORIZONTAL or VERTICAL.

ParametersJSON Schema

Name	Required	Description	Default
`image_id`	Yes
`direction`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/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 of behavioral disclosure. It does not state whether the flip modifies the image in-place, returns a new image, or affects the undo stack. This is a significant gap for a mutation tool, as the agent cannot infer side effects or required permissions.

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?

The description is a single, front-loaded sentence that conveys the essential action without excess words. Every part is meaningful, and it is appropriately sized for the tool's simplicity.

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?

Given the tool's simplicity and the presence of an output schema, the description is reasonably complete for basic usage. However, it lacks details on side effects (e.g., in-place modification vs. new image) and any prerequisites (e.g., image must be open), which are important for an agent to use it correctly and safely.

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 coverage is 0%, so the description must compensate. It mentions 'HORIZONTAL or VERTICAL', which suggests possible values for 'direction', but does not specify exact string formats, case sensitivity, or default behavior. The 'image_id' parameter is left entirely to the schema, so the description adds only partial value.

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 uses a specific verb ('Flip') and resource ('an image'), and clarifies the two possible axes (HORIZONTAL or VERTICAL). This clearly distinguishes it from the sibling tool 'rotate_image' which performs rotation, not mirroring.

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?

The description implies usage for flipping an image, but does not explicitly state when to prefer this over alternatives or provide any exclusions. No comparison to sibling tools like rotate_image is given, leaving some ambiguity for the agent.

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

get_active_imageA

Return the image associated with GIMP's default display, if available.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description must carry the behavioral transparency burden. It discloses the conditional nature ('if available'), which is useful, but does not explicitly state side-effect-free behavior or what happens when no image is available. This is adequate for a simple getter but not rich.

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?

The description is a single, tightly worded sentence that clearly states the action and condition without any unnecessary words.

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

Completeness5/5

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

Given the tool has no parameters, an output schema is available, and the tool is a simple retrieval, the description is complete. It notes the conditional availability, which is the key behavioral detail.

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?

The tool has zero parameters, so the description does not need to explain any. According to the baseline for 0 parameters, this is sufficient.

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 uses a specific verb ('Return') and identifies the resource ('the image associated with GIMP's default display'). This clearly distinguishes it from sibling tools like list_open_images and get_image_info, which have different scopes.

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?

No guidance is given about when to use this tool versus alternatives such as get_image_info or list_open_images. The intended use is implied by the name and description, but no explicit context or exclusions are provided.

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

get_image_infoB

Return dimensions, name, file, base type, and dirty state for an image.

ParametersJSON Schema

Name	Required	Description	Default
`image_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior2/5

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

No annotations exist, so the description carries the full burden. It only lists return fields and does not disclose side effects, error behavior, permissions, or whether the image must be open.

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?

A single sentence that front-loads the primary purpose and provides a clear list of return fields. There is no redundant or extraneous information.

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?

The tool is simple and has an output schema, so the description needn't explain return structure. However, the lack of usage guidance and parameter semantics leaves some context gaps for an agent deciding when and how to invoke it.

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

Parameters2/5

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

Schema description coverage is 0%, and the description only says 'for an image' without explaining the meaning, source, or valid values of image_id. The agent is left to infer that image_id is an identifier, but no practical guidance is given.

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 clearly states the tool returns specific image attributes (dimensions, name, file, base type, dirty state) for a given image. This distinguishes it from sibling tools like get_layer_info or get_active_image by focusing on image-level metadata.

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 guidance on when to use this tool instead of alternatives like list_open_images or get_active_image. No context is provided about typical workflows or prerequisites.

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

get_layer_infoC

Return stable properties for a layer/drawable.

ParametersJSON Schema

Name	Required	Description	Default
`image_id`	Yes
`layer_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are present, so the description carries the full burden of behavioral disclosure. 'Return' implies a read operation, but it does not mention side-effect-free behavior, error conditions, required permissions, or what 'stable properties' encompasses.

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 description is a single efficient sentence with no unnecessary words. It loses a point because it is so brief that it omits context that could be useful, but it is still concise and front-loaded.

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?

With no annotations and no output schema visible, the description alone is insufficient. It lacks behavioral context, relationship to sibling tools, and parameter clarity, making it barely adequate for a tool with only two parameters.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not mention 'image_id' or 'layer_id' at all. It adds no meaning beyond the schema's integer types and required flags, failing to compensate for the missing parameter info.

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 clearly states the operation: 'Return stable properties for a layer/drawable.' It uses a specific verb and resource, and it's distinct from sibling tools like 'list_layers' or 'get_image_info'. However, it doesn't explicitly differentiate itself from those tools.

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?

No guidance is provided on when to use this tool versus alternatives such as 'list_layers' or 'get_image_info'. There are no prerequisites, exclusions, or context cues beyond the plain description.

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

gimp_capabilitiesA

Return supported high-level operations and known v0.1 limitations.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/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. It clearly states that the tool returns information, implying a non-mutating operation, and adds context by noting it reports known v0.1 limitations. This is transparent and honest, though it does not explicitly declare safety or side effects (which are unnecessary for a return-only tool).

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?

The description is a single sentence of 10 words, front-loaded with the verb 'Return' and containing no unnecessary content. It is perfectly concise and well-structured for a simple query tool.

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?

With no parameters and an output schema that defines the return structure, the description is sufficiently complete. It communicates the tool's purpose without needing to elaborate on return values or additional context, matching the tool's low complexity.

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?

The tool has zero parameters, so the schema is trivially complete. The baseline score of 4 applies, and the description need not add parameter meaning because there are no parameters to describe.

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 uses the specific verb 'Return' and clearly identifies the resource: supported high-level operations and known v0.1 limitations. This distinguishes it from sibling tools, which are mostly action-oriented. The scope is concise and unambiguous.

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?

The description does not explicitly state when to use this tool, but the purpose is implicitly clear: to discover what operations are supported and what limitations exist. No alternatives or exclusions are mentioned, but none are needed given the tool's unique role.

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

gimp_statusA

Check the configured GIMP connection and return basic session status.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior3/5

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

Description implies a non-mutating check/return operation by using 'check', but with no annotations it does not explicitly disclose side effects, error handling, or permissions. Acceptable for a status tool but minimal.

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?

Single sentence, front-loaded with action, 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 zero-parameter status tool with output schema, the description captures the essential function, but lacks context on typical usage scenarios (e.g., pre-flight check before GIMP operations).

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?

Tool has zero parameters, so schema provides complete coverage; description need not add parameter semantics.

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?

Description uses specific verb 'check' with resource 'configured GIMP connection' and specifies output as 'basic session status'. It is clear but does not explicitly distinguish from sibling gimp_capabilities, though the function is evidently a status/health check.

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?

No guidance on when to use vs alternatives or prerequisites. Only states what it does, not when to invoke it.

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

hue_saturationC

Apply the basic hue, saturation, and lightness adjustment.

ParametersJSON Schema

Name	Required	Description	Default
`hue`	Yes
`layer_id`	Yes
`lightness`	Yes
`saturation`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of disclosing behavioral traits. It only says 'apply', implying a mutation, but gives no details about reversibility, parameter ranges, or impact on the target layer. This is minimal and largely non-transparent.

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

Conciseness3/5

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

The description is a single, concise sentence with no fluff, but it is under-specified. It is front-loaded but lacks necessary content, so it is not optimally concise—it is simply short.

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?

Given the tool has 4 required parameters, no annotations, and a minimal description, the description is insufficiently complete. It does not explain the role of layer_id, value ranges, or what the adjustment does to the image or layer. The presence of an output schema does not compensate for the lack of behavioral and parameter context.

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

Parameters2/5

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

The schema has no descriptions (0% coverage), and the description only mentions the names of the parameters (hue, saturation, lightness) without explaining their meaning, ranges, or units. It adds no practical value beyond the schema's property names.

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 clearly states the tool applies a hue, saturation, and lightness adjustment, which is a specific verb-resource combination. It is distinguishable from sibling tools like brightness_contrast and desaturate, though it does not explicitly name them as alternatives.

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 implied by the description: it is for applying basic hue/saturation/lightness adjustments. However, there is no explicit guidance about when to choose this tool over similar adjustment tools, nor any prerequisites or layer targeting advice.

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

invert_selectionC

Invert the current selection.

ParametersJSON Schema

Name	Required	Description	Default
`image_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description carries full responsibility for behavioral disclosure. It merely names the action without explaining effects like whether it modifies selection state, requires an existing selection, or returns a value.

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 description is a single, non-redundant sentence that is front-loaded with the core action. It is concise, though it could be expanded with useful context without becoming verbose.

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 tool with one parameter and an output schema, the description is under-specified. It does not connect the operation to image_id, mention preconditions, or indicate what the tool returns, leaving the agent to infer critical details.

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

Parameters2/5

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

Schema coverage for parameters is 0%, and the description does not mention image_id at all. While the parameter name is somewhat self-explanatory, the description fails to clarify how it relates to the 'current selection' or how to use it.

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 clearly states a specific operation ('invert') applied to a resource ('the current selection'). It stands apart from sibling tools like select_all, select_none, and select_rectangle by using a unique verb, though it stops short of defining what 'invert' entails in this context.

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?

No guidance is provided on when to use this tool versus other selection tools, nor are prerequisites such as an active selection or the relationship to the image_id parameter mentioned.

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

invoke_pdb_procedureA

Invoke a live PDB procedure using structured positional or keyword values.

Values may be JSON scalars, arrays, or {"scheme_symbol": "ENUM-VALUE"} objects. Arbitrary Scheme source is intentionally not accepted.

ParametersJSON Schema

Name	Required	Description	Default
`args`	No
`keywords`	No
`procedure_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral disclosure burden. It reveals an important constraint—arbitrary Scheme source is intentionally rejected—and clarifies acceptable value formats (JSON scalars, arrays, scheme_symbol objects). It also notes the procedure is 'live', indicating direct execution. These details go beyond a simple invocation statement.

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?

The description is two sentences, front-loaded with the action, and every sentence adds value. No filler or redundant statements. The format restriction is presented clearly and compactly.

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 generic invocation tool with no annotations and 0% schema coverage, the description covers the core purpose, input format, and a critical restriction. An output schema exists to describe return values, so its absence in the description is acceptable. It could be more complete with a brief note about needing the procedure signature from describe_pdb_procedure, but overall it is adequate.

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 0%, so the description must compensate. It explains the allowed value shapes ('JSON scalars, arrays, or {"scheme_symbol": "ENUM-VALUE"} objects') and the positional/keyword distinction, which maps to the args and keywords parameters. However, it doesn't explicitly name the parameters or provide examples of how to construct arguments.

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 clearly states the action ('Invoke') and the target ('a live PDB procedure'), making the tool's purpose unambiguous. It differentiates itself from sibling tools like search_pdb and describe_pdb_procedure, which are for discovery and inspection, while this tool is for execution.

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?

Guidance on when to use this tool is implied rather than explicit. The description implies callers must know the procedure name and provide structured values, but it doesn't explicitly mention consulting describe_pdb_procedure first or warn against using it for arbitrary Scheme. No clear alternatives or exclusions are stated.

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

list_layersB

List root layers in top-to-bottom order.

ParametersJSON Schema

Name	Required	Description	Default
`image_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It discloses the read-only nature via 'List' and notes the order, but it doesn't clarify what 'root layers' means (e.g., whether nested/layer groups are excluded) or any other behavioral details. It's adequate but minimal.

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?

A single, front-loaded sentence with no filler. Every word is meaningful and the structure is clear, making it highly concise.

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 a simple list operation with an output schema, the description is nearly sufficient, but it omits any connection between the action and the required 'image_id' parameter. Also, 'root layers' could benefit from a brief clarification. Overall, it's adequate but not complete.

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

Parameters1/5

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

The description makes no mention of the 'image_id' parameter. Schema coverage is 0%, so the description fails to clarify what the parameter refers to. The agent must rely on the parameter name alone, which is a significant 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 uses the specific verb 'List' with the resource 'root layers' and specifies 'top-to-bottom order', clearly differentiating this from other layer operations like get_layer_info or create_layer. It's unambiguous about what it returns.

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?

The description tells you what it does but doesn't explicitly say when to use it over alternatives, nor does it state any exclusions. The usage is implied but not directly guided, which is a minor gap given sibling tools like get_layer_info.

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

list_open_imagesA

List open images using stable GIMP image IDs.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

The description discloses one useful trait: the returned IDs are stable, which is important for referencing images later. However, with no annotations, the description carries the full burden but does not mention other behavioral aspects such as read-only nature, potential errors, or ordering. It adds some value but lacks richer context.

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?

The description is a single, front-loaded sentence that delivers the core purpose without waste. It includes the key detail about stable IDs, making it efficient and well-structured.

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 tool with no parameters and an output schema, the description covers the essential information: it lists open images and notes stable IDs. It is reasonably complete, though it could explicitly say 'all' open images or hint at usage context, but the simplicity justifies a high score.

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?

The input schema has zero parameters, so there is nothing to explain. Per the rubric, the baseline for 0 parameters is 4, and the description doesn't need to add parameter details. It correctly omits any parameter information.

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 clearly states the tool's function: 'List open images' with a specific resource (open images) and a notable detail about stable GIMP image IDs. This distinguishes it from sibling tools like get_active_image or get_image_info, which target a single image, whereas this tool lists all open images.

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?

The description provides no explicit guidance on when to use this tool versus alternatives, but the purpose is self-evident from the name and verb. It implies usage for enumerating open images, but does not mention exclusions or alternatives, so it falls short of a higher score.

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

merge_downC

Merge a layer down using a GIMP merge type.

ParametersJSON Schema

Name	Required	Default
`image_id`	Yes
`layer_id`	Yes
`merge_type`	No	EXPAND-AS-NECESSARY

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description carries full responsibility for behavioral disclosure. It mentions 'merge type' but does not explain consequences like layer destruction, changes to layer stack, or required permissions. The agent is left guessing about side effects.

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 description is a single sentence, front-loaded with the action, and contains no unnecessary fluff. However, its brevity borders on under-specification, which slightly reduces its effectiveness.

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?

Given the complexity of a merge operation and absence of annotations, the description is too sparse. It does not cover merge behavior, return values, or edge cases, making it incomplete for reliable invocation.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no parameter information beyond restating 'merge type'. The semantics of merge_type values, image_id, and layer_id are not explained, failing to compensate for the missing schema descriptions.

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 clearly states the action ('Merge') and the resource ('a layer down'), using a known GIMP operation. It distinguishes from sibling tools like duplicate_layer or delete_layer, though it doesn't explicitly differentiate from potentially similar merge operations.

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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical scenarios, or exclusions, leaving the agent without context for selection.

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

move_layerC

Move a layer to a top-level or group position.

ParametersJSON Schema

Name	Required	Description	Default
`image_id`	Yes
`layer_id`	Yes
`position`	Yes
`parent_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without revealing side effects, such as whether the layer's old position is vacated, whether parent_id must exist, or whether the operation is reversible. This is a significant gap.

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?

The description is a single, front-loaded sentence with no filler. It is concise and well-structured, though it sacrifices necessary detail.

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?

Despite the presence of an output schema, the description is incomplete for a tool with four parameters and no schema documentation. It lacks usage context, behavioral details, and parameter explanations beyond a vague hint. The agent would need to guess at required inputs and constraints.

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

Parameters2/5

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

The schema has 0% description coverage, so the description must explain parameter meanings. 'Top-level or group position' hints at parent_id and position, but it does not clarify the semantics of the position integer (e.g., zero-based index) or the role of each parameter. The four parameters remain largely undocumented for the agent.

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 uses a specific verb ('move') and resource ('layer'), and the phrase 'top-level or group position' conveys the movement scope. It distinguishes from sibling tools like rename_layer or delete_layer by indicating a repositioning action, though the notion of 'position' is somewhat ambiguous.

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?

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description does not mention typical use cases like reordering layers or moving between groups, so the agent has to infer context from the tool name alone.

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

open_imageB

Open an existing local image file in GIMP.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.4/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 of behavioral disclosure. It only states the action of opening a file, without disclosing side effects such as whether the image becomes active, what happens if the file is already open, or error behavior. This is a significant gap for a mutation-like operation.

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?

The description is a single concise sentence that communicates the core action without any redundant words. It is front-loaded with the verb and resource, making it easy to scan.

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?

The tool is simple with only one parameter and an output schema, so the description need not explain return values. However, it omits side-effect information (e.g., whether opening sets the image as active) that would help an agent reason about fallback behavior. It is adequate for a basic open operation but not rich.

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

Parameters2/5

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

The input schema has one parameter 'path' with only a title and no description, and schema description coverage is 0%. The description merely says 'existing local image file', which hints that path is a file path but does not explain required format, absolute vs relative, or supported file types. The description fails to compensate for the schema's lack of parameter detail.

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 clearly states a specific verb ('Open') and resource ('existing local image file') with a target ('in GIMP'). It distinguishes from siblings like create_image or list_open_images by specifying that it operates on existing files on disk.

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 context is implied by 'existing local image file', suggesting this is for loading files rather than creating new ones. However, there is no explicit mention of when to use this tool versus alternatives like create_image, nor any exclusions or alternative references.

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

redoB

Redo the latest undone action in an image.

ParametersJSON Schema

Name	Required	Description	Default
`image_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/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. It only states the action without disclosing side effects, error behavior (e.g., what happens if there is no undone action), or whether it modifies the image in place. Minimal behavioral context.

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?

The description is a single, succinct sentence that front-loads the verb and clearly conveys the action. No wasted words or redundant details.

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?

Given the absence of annotations and the simplicity of the tool, the description is too sparse. It omits important context such as what happens when no action is undone, whether the image is modified, and any return value expectations. The output schema exists but is not described, and the single parameter is never explained.

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

Parameters2/5

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

Schema description coverage is 0%, and the description does not mention the 'image_id' parameter at all. The parameter name is self-explanatory, but the description adds no meaning beyond the schema's title and type, failing to compensate for the lack of schema descriptions.

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 uses a specific verb 'Redo' and clearly states the resource 'the latest undone action in an image.' This distinctly differentiates it from siblings like 'undo' and identifies the exact operation performed.

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?

The description implies usage context (after an undo) but does not explicitly state when to use it versus alternatives, nor does it mention prerequisites or limitations. There is no 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.

rename_layerA

Rename a layer without changing its pixels.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`layer_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior3/5

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

Without annotations, the description carries the burden of behavioral disclosure. It does usefully state that pixels are unaffected, but it omits other behavioral context such as whether the change is reversible via undo, whether the layer name is the only metadata altered, or any required permissions or prerequisites. A bare minimum is met, but more detail would improve transparency.

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?

The description is a single sentence that is concise, front-loaded with the verb, and contains no irrelevant information. The clarifying phrase 'without changing its pixels' earns its place by distinguishing the tool from others.

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?

This is a simple tool with two parameters and an output schema, so the description does not need to explain return values. However, given no annotations, it could benefit from noting that the layer_id must reference an existing layer in the current image and that the rename is immediately applied. It is adequate but not comprehensive for a tool with no structured safety metadata.

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

Parameters2/5

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

The description provides no explanation of the 'name' and 'layer_id' parameters. Schema description coverage is 0%, and although the parameter names and types are self-explanatory, the description is expected to compensate for the low coverage. It adds no meaning beyond what the input schema already shows.

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 clearly states the action (rename a layer) and the specific resource (layer), and differentiates from sibling tools by adding 'without changing its pixels.' This distinguishes it from pixel-modifying operations like rotate_image or brightness_contrast, making the purpose unambiguous.

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?

The description implies the tool should be used when a rename is needed without altering pixel data, but it does not explicitly mention alternatives or when not to use it. The context is clear but lacks explicit exclusions or comparison to similar layer operations like duplicate_layer or set_layer_visibility.

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

resize_canvasA

Resize the canvas without scaling layer pixels.

ParametersJSON Schema

Name	Required	Description	Default
`width`	Yes
`height`	Yes
`image_id`	Yes
`offset_x`	No
`offset_y`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are present, so the description carries the behavioral transparency burden. It discloses the key behavior that layer pixels are not scaled, but omits other important behaviors such as how offsets affect positioning, what happens to layers extending beyond new bounds, or any side effects. This is partial transparency.

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?

The description is a single concise sentence that immediately states the core purpose and key behavior. It contains no filler and is easy to parse.

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?

With 5 parameters, 3 required, and no annotations, this one-sentence description is insufficient for full understanding. It lacks information about offset handling, edge cases (e.g., negative values, smaller canvas clipping), and the effect on existing layers beyond the note on scaling. The presence of an output schema does not reduce the need for behavioral context.

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

Parameters2/5

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

Schema description coverage is 0%, and the description adds no parameter details. While names like width, height, and offset_x are somewhat self-explanatory, their exact semantics—especially offset behavior and units—are not clarified. The description fails to compensate for the missing schema descriptions.

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 clearly states the action (resize the canvas) and the resource (canvas), while the phrase 'without scaling layer pixels' distinguishes it from similar tools like resize_image. This is a specific and unambiguous purpose.

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?

The description implies usage when you want to change canvas dimensions while preserving layer pixel scale, but it does not explicitly mention alternatives or when NOT to use it. Sibling tools like resize_image and crop_image exist, but no direct comparison is made.

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

resize_imageB

Scale the image and its layers to exact dimensions.

ParametersJSON Schema

Name	Required	Description	Default
`width`	Yes
`height`	Yes
`image_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It only states the action and scope, but does not reveal whether the operation is destructive, whether it modifies the image in place, whether aspect ratio is preserved, or what the return value is. This leaves significant behavioral ambiguity for such a mutation tool.

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?

The description is a single, concise sentence that immediately states the purpose. Every word earns its place, and the structure is front-loaded with the action. There is no fluff or redundancy.

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?

Despite the tool's simplicity, the description is incomplete. It lacks usage guidance, behavioral traits like destructiveness or in-place modification, and parameter clarity. Since there are no annotations, the agent is given too little context to confidently select and invoke the tool.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It adds only a general notion of 'dimensions' for width and height, but does not explain the image_id parameter or specify units. The schema itself provides only basic titles, so the match is minimal.

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 'Scale the image and its layers to exact dimensions' clearly identifies the verb (scale), the resource (image and its layers), and the specific scope (exact dimensions). This distinguishes it from the sibling tool resize_canvas, which only resizes the canvas, and from other image transforms.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention resize_canvas or other sibling tools, and lacks any exclusions or prerequisites. Usage context is entirely absent.

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

rotate_imageB

Rotate an image using ROTATE-90, ROTATE-180, or ROTATE-270.

ParametersJSON Schema

Name	Required	Description	Default
`image_id`	Yes
`rotation`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations available, the description carries the full burden. It states the basic operation but does not disclose whether the image is modified in place, whether a new image is returned, or any side effects. This is a significant gap for a mutation operation.

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?

The description is a single, front-loaded sentence with no filler. It contains only the essential information about what the tool does and the valid rotation values.

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 a simple operation, the description is minimally acceptable, but it lacks behavioral details (in-place vs. new image) and usage context. The presence of an output schema is not explained, and the overall guidance is thin.

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 the allowed values for the rotation parameter, which is valuable since the schema lacks an enum. However, the image_id parameter is not explained beyond its name, and the schema description coverage is 0%, so the description only partially compensates.

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 clearly states the tool's function: rotating an image, listing the specific allowed rotation values (90, 180, 270 degrees). This distinguishes it from sibling tools like flip_image or crop_image.

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?

No guidance is provided on when to use this tool versus alternatives, or under what circumstances rotation is appropriate. No exclusions or prerequisites are mentioned.

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

save_xcfB

Save an image as XCF; existing files require overwrite=true.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`image_id`	Yes
`overwrite`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden for behavioral disclosure. It adds the critical detail that existing files require overwrite=true, implying the default behavior will not overwrite and may fail. However, it omits other behavioral traits such as whether saving marks the image as clean, or any details about return values or errors, which would be useful given the lack of annotations.

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?

The description is a single, front-loaded sentence that efficiently conveys the core function and the key overwrite guardrail. Every word contributes value, with no waste or repetition.

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?

The tool is simple, but the description is minimal. It covers the essential purpose and the overwrite caveat, but does not mention sibling tools for comparison, nor does it elaborate on parameter usage beyond overwrite. Given the absence of annotations, a more complete description would include guidance on alternatives or expected path format, making this adequate but not exceptional.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It only clarifies the 'overwrite' parameter, leaving 'image_id' and 'path' unexplained. Though the parameter names are somewhat self-explanatory, the description does not specify the expected format for path (e.g., whether to include the .xcf extension) or how to obtain image_id. This is insufficient given zero schema descriptions.

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 clearly states the tool's function: 'Save an image as XCF'. This is a specific verb + resource combination, and the mention of XCF distinguishes it from sibling tools like export_image, which presumably handles other formats.

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?

The description provides no guidance on when to use this tool versus alternatives. The only usage hint is the overwrite condition, which is parameter-specific, not a tool-selection guideline. Siblings like export_image and open_image are not mentioned, so the agent receives no explicit direction on choosing save_xcf.

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

search_pdbB

Search live GIMP PDB procedure names by literal text.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/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 full burden. It only reveals that the search is 'live' and uses 'literal text', but does not disclose matching behavior (e.g., case-sensitivity, substring vs whole-word), result format, or behavior of the limit parameter.

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?

A single, front-loaded sentence that states the action and key constraint with no wasted words. It is appropriately minimal and scannable.

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?

The tool has a simple interface and an output schema, but the description omits usage context and behavioral details (e.g., how matching works, how limit affects results). It is minimally viable but leaves gaps that an agent would need to discover at runtime.

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

Parameters2/5

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

Schema description coverage is 0%, and the description only hints at query semantics via 'literal text'. The 'limit' parameter is not explained at all, and no additional meaning is added beyond the raw schema.

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?

Description uses a specific verb ('Search'), identifies the resource ('live GIMP PDB procedure names'), and clarifies the method ('by literal text'). This clearly distinguishes it from sibling tools like describe_pdb_procedure and invoke_pdb_procedure.

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?

No explicit guidance is given about when to prefer this over describe_pdb_procedure or invoke_pdb_procedure. The description implies its role as the search entry point but lacks any when-to-use or exclusion details.

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

select_allC

Select the entire image.

ParametersJSON Schema

Name	Required	Description	Default
`image_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.5/5.0

Behavior1/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the operation without explaining any side effects, such as replacing the existing selection, applying to the specified image_id, or whether it is reversible. This is a significant gap for a state-changing tool.

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

Conciseness3/5

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

The description is a single short sentence with no wasted words, but it is under-specified. While it is efficient, it does not mention parameters or behavior, making it too terse to be fully useful. It earns its place as a basic purpose statement but lacks needed elaboration.

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?

Despite being a simple tool, the description is incomplete. It does not clarify how the selection is applied, any requirements (e.g., image must be open), or the impact on existing selection. An output schema exists but return values are not the issue; the missing operational context makes it inadequate.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not mention the image_id parameter at all. The schema only provides the title 'Image Id' with no explanation of what it refers to or how it is used. The description fails to compensate for this lack of parameter context.

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 'Select the entire image' clearly states the tool's action (select) and target (the entire image). It distinguishes this from sibling selection tools like select_rectangle, select_ellipse, and select_layer_alpha by specifying 'entire image'.

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?

No guidance is given on when to use this tool vs alternatives. The description does not mention that this is the tool to use when the full image selection is needed, nor does it reference any sibling tools or exclude cases where other selection methods are more appropriate.

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

select_ellipseA

Replace the selection with an ellipse.

ParametersJSON Schema

Name	Required	Description	Default
`x`	Yes
`y`	Yes
`width`	Yes
`height`	Yes
`image_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description must carry the behavioral burden. It explicitly states that the selection is 'replaced', disclosing the side effect that the previous selection is lost. However, it does not explain coordinate interpretation (e.g., whether x,y is the center or top-left), units, or any operational specifics. The negative side effect is clear, but behavioral details remain minimal.

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?

The description is a single, focused sentence with no filler or redundancy. It front-loads the core action and is appropriately sized for a simple selection tool, making it highly efficient.

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?

The tool has five required parameters, zero percent schema description coverage, and no annotations. The presence of an output schema reduces the need to explain return values, but the description is far too sparse to provide the necessary context for parameter handling, coordinate system, and expected behavior. It leaves significant gaps for an AI agent.

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

Parameters1/5

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

The schema has five required parameters with zero textual description coverage. The tool description does not explain the roles of x, y, width, height, or image_id, and notably x and y are ambiguous (center vs top-left) without additional context. This is a critical omission for an AI agent to invoke the tool correctly.

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 uses a specific verb 'Replace' and a specific resource 'the selection', clearly indicating that the tool replaces the current selection with an ellipse. This distinguishes it from sibling tools such as select_rectangle, select_none, and invert_selection, so the purpose is unambiguous.

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 phrase 'Replace the selection with an ellipse' provides clear context: it is used when you want to set the selection to an elliptical shape. It does not explicitly mention alternatives or exclusions, but the usage is effectively self-evident, so it earns a 4 rather than a 5.

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

select_layer_alphaB

Replace the selection with a layer's alpha.

ParametersJSON Schema

Name	Required	Description	Default
`image_id`	Yes
`layer_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description carries full behavioral burden. It states that the existing selection is replaced, which is a key side effect, but it does not disclose other important behaviors such as requiring the image and layer to exist, potential error conditions, or whether the operation can be undone. This is minimal transparency for a mutating tool.

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?

The description is a single sentence with no wasted words. It is front-loaded with the action and resource, making it immediately scannable.

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?

The tool has a simple signature with two required parameters and an output schema, so the description partially suffices. However, it lacks context about how this selection operation relates to other selection methods and omits prerequisites for safe invocation, leaving noticeable gaps for an agent.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate for explaining parameters. It only implies that 'layer_id' refers to the layer whose alpha is used, but it does not explain 'image_id' or the relationship between the two parameters. The schema titles alone are insufficient.

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 uses a specific verb ('Replace'), a clear resource ('the selection'), and a distinguishing source ('a layer's alpha'). This clearly differentiates it from shape-based selection tools like select_rectangle and select_ellipse, and from global selections like select_all and select_none.

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?

The description gives no guidance on when to use this tool versus alternatives. It does not mention selection operation modes (e.g., add, subtract, intersect) or provide examples of when this should be chosen over other selection tools.

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

select_noneC

Clear the image selection.

ParametersJSON Schema

Name	Required	Description	Default
`image_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the high-level action, but does not explain side effects (e.g., whether the selection is cleared from all images or just the one specified), whether the operation is undoable, or why an image_id parameter is required. This lack of detail is a notable gap for a mutation-like 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?

The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a seemingly simple operation, though the extreme brevity contributes to the lack of parameter semantics. It earns full credit for conciseness but loses one point for being too sparse to be fully self-sufficient.

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?

Given the tool has a required parameter and no annotations, the description is far from complete. It does not explain the role of 'image_id', the return value (even though an output schema exists, the description doesn't hint at what it contains), or how the tool behaves in edge cases. The sibling tools provide selection context, but the description itself leaves key aspects unaddressed.

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

Parameters1/5

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

The schema coverage is 0%—the description does not mention the 'image_id' parameter at all. Since the schema only provides the type and requirement, the description should clarify why the image_id is needed and what it identifies (e.g., the image whose selection should be cleared). It provides zero added meaning.

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 'Clear the image selection' uses a specific verb ('clear') and a clear resource ('image selection'), making its purpose immediately obvious. It also distinguishes itself from sibling selection tools like select_all, invert_selection, and the various selection primitives.

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?

The description provides no guidance on when to use this tool versus alternatives like select_all or invert_selection. It does not state any context, prerequisites, or mention that it deselects the current selection, leaving the user to infer the appropriate usage scenario.

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

select_rectangleC

Replace the selection with a rectangle.

ParametersJSON Schema

Name	Required	Description	Default
`x`	Yes
`y`	Yes
`width`	Yes
`height`	Yes
`image_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description must carry the full burden of behavioral disclosure. The word 'Replace' indicates a destructive mutation of the current selection, but it does not explain coordinate origin, bounds checking, or whether the operation applies to the active image or layer. Minimal context is provided beyond the schema's parameters.

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 description is a single concise sentence with no wasted words. It is front-loaded and easy to parse. However, it is so brief that it borders on under-specification, lacking important explanatory content, though this is not a structural issue.

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?

Despite having an output schema, the description is incomplete for a five-parameter tool. It fails to specify coordinate system, units, whether the rectangle is anti-aliased, or how selection replacement interacts with existing selections. Sibling tools like select_ellipse likely share the need for such context, but this description does not provide it.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no meaning to any of the five parameters. It does not explain that x/y are top-left coordinates, width/height are in pixels, or how image_id identifies the target image. The agent must rely solely on parameter names, which are vague.

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 uses a specific verb, 'Replace', and identifies the resource as 'the selection', making the action clear. It distinguishes itself from sibling selection tools (e.g., select_ellipse, select_layer_alpha) by specifying 'rectangle'.

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?

No guidance is provided on when to use this tool versus alternatives. The description is purely functional and does not mention prerequisites, use cases, or exclusions, leaving the agent to infer usage from the schema and sibling names.

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

set_layer_modeA

Set a GIMP layer mode such as LAYER-MODE-NORMAL or LAYER-MODE-MULTIPLY.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	Yes
`layer_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are present, so the description carries the full burden for behavioral transparency. It only states the action ('Set') without disclosing side effects, prerequisites (e.g., layer must exist), whether the operation is reversible, or how invalid mode strings are handled. For a mutation tool, this is a significant gap.

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?

The description is a single sentence that states the action, target, and examples. Every word earns its place with no redundancy or unnecessary detail.

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 a simple two-parameter setter with an output schema, the description is close to sufficient. However, the lack of behavioral transparency (no annotations, no side-effect disclosure) and the absence of a full list of valid modes leaves some gaps. It meets the minimum viable standard but is not richly comprehensive.

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 0%, so the description must compensate. It adds value by providing two concrete valid values for the 'mode' parameter, which helps the agent infer the expected string format. The 'layer_id' parameter is self-explanatory from its name. While it doesn't enumerate all possible modes, the examples provide a meaningful baseline.

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 uses a specific verb ('Set') and identifies the exact resource ('GIMP layer mode'), with concrete examples (LAYER-MODE-NORMAL, LAYER-MODE-MULTIPLY). This clearly distinguishes it from sibling layer tools that set opacity, visibility, or position.

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?

The usage context is implied: use it when you want to change a layer's compositing mode. However, the description provides no explicit 'when to use vs alternatives' or exclusionary guidance, such as noting that this is not for opacity or blending adjustments. This is minimal but not misleading.

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

set_layer_opacityB

Set layer opacity from 0 to 100.

ParametersJSON Schema

Name	Required	Description	Default
`opacity`	Yes
`layer_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/5.0

Behavior2/5

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

The description is purely declarative with no mention of side effects, reversibility, error conditions, or parameter constraints beyond the range. With no annotations provided, the description carries the full burden of behavioral disclosure, which it fails to meet.

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?

The description is a single sentence with no redundant words. It is appropriately concise and front-loaded with the main action and subject.

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 simple mutating tool with no annotations, the description is too sparse. While the output schema exists, the description does not provide context about when to use the tool, how to interpret the opacity range (e.g., 0 meaning fully transparent), or any potential side effects. The tool's simplicity does not excuse the lack of usage and parameter guidance.

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

Parameters2/5

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

The schema description coverage is 0%, so the description must compensate. It does clarify that 'opacity' ranges from 0 to 100, but it gives no meaning to 'layer_id' other than what is visible in the schema (an integer). This is only partial compensation.

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 clearly states the action (Set), the target (layer opacity), and the valid range (0 to 100). This is specific enough to distinguish it from sibling tools like set_layer_visibility or set_layer_mode, which target different properties.

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 guidance on when to use this tool versus alternatives, no mention of prerequisites, and no exclusions. The intended use is only implied by the name, not explicitly stated.

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

set_layer_visibilityB

Set whether a layer is visible.

ParametersJSON Schema

Name	Required	Description	Default
`visible`	Yes
`layer_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as side effects, error conditions, or whether the operation affects only the specified layer. It is a minimal statement with no additional context.

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?

The description is one short sentence, concise and front-loaded. Every word is necessary, though it is under-specified in other dimensions.

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?

The tool is simple, but the description lacks context about required preconditions, relationship to sibling tools, or error handling. The existence of an output schema is not referenced, and the description alone is insufficient for an agent to know how to obtain a valid layer_id.

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

Parameters2/5

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

The schema has 0% description coverage, and the description does not explain the parameters. While the names (layer_id, visible) are somewhat self-explanatory, the description does not add meaning beyond what the schema already shows.

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 clearly states the action ('Set') and the resource ('layer visibility'), differentiating it from sibling tools like set_layer_opacity or set_layer_mode. It is specific and unambiguous.

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?

The description provides no information about when to use this tool, prerequisites, or alternatives. It does not mention that layer_id should come from list_layers or that it operates on the active image.

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

undoB

Undo the latest action in an image.

ParametersJSON Schema

Name	Required	Description	Default
`image_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/5.0

Behavior2/5

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

Without annotations, the description carries the full burden of behavioral disclosure, but it only states a basic fact. It does not mention side effects, whether the undo is reversible via redo, what happens if no actions exist, or any destructive implications. This leaves significant behavioral ambiguity for a mutation operation.

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?

The description is a single, front-loaded sentence that conveys the core action and resource with zero wasted words. It is appropriately sized for the tool's simplicity.

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?

Even though there is an output schema present (so return values need not be explained), the description lacks important context such as whether undo history is supported, how many levels can be undone, or what happens when no prior action exists. For a single-parameter tool, it is minimal but still leaves notable gaps in understanding the tool's operational boundaries.

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

Parameters2/5

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

The schema shows a single required parameter 'image_id' with no description (coverage 0%). The description's phrase 'in an image' vaguely relates to this parameter but does not clarify its meaning or format beyond what the parameter name/title already implies. The description fails to compensate for the schema's lack of detail.

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 clearly states the tool's function: 'Undo the latest action in an image.' It uses a specific verb ('undo') and resource ('image'), and the scope ('latest action') distinguishes it from broader operations. The sibling 'redo' makes the purpose unambiguous.

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?

No guidance is provided on when to use this tool versus alternatives like 'redo' or other image-editing actions. The description does not mention conditions (e.g., whether an undoable action exists) or exclusions, leaving the agent to infer appropriate usage.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

40 tool updatesv0.1.0Aug 8, 2026
- First observedbrightness_contrast
- First observedclose_image
- First observedcreate_image
- First observedcreate_layer
- First observedcrop_image
- First observeddelete_layer
- First observeddesaturate
- First observeddescribe_pdb_procedure
- First observedduplicate_layer
- First observedexport_image
- First observedflip_image
- First observedget_active_image
- First observedget_image_info
- First observedget_layer_info
- First observedgimp_capabilities
- First observedgimp_status
- First observedhue_saturation
- First observedinvert_selection
- First observedinvoke_pdb_procedure
- First observedlist_layers
- First observedlist_open_images
- First observedmerge_down
- First observedmove_layer
- First observedopen_image
- First observedredo
- First observedrename_layer
- First observedresize_canvas
- First observedresize_image
- First observedrotate_image
- First observedsave_xcf
- First observedsearch_pdb
- First observedselect_all
- First observedselect_ellipse
- First observedselect_layer_alpha
- First observedselect_none
- First observedselect_rectangle
- First observedset_layer_mode
- First observedset_layer_opacity
- First observedset_layer_visibility
- First observedundo

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0

Scored 2026-08-08 21:15 across 40 tools

Disambiguation5/5

Each tool targets a unique operation or resource: image lifecycle, layer properties, selections, adjustments, and PDB introspection are clearly separated. Even similar-sounding tools like resize_image vs resize_canvas or select_rectangle vs select_ellipse have distinct descriptions that prevent misselection.

Naming Consistency4/5

The vast majority follow a clear verb_noun pattern (create_image, list_layers, set_layer_opacity). Minor exceptions like gimp_status, gimp_capabilities, brightness_contrast, and hue_saturation are acceptable but deviate slightly from the dominant convention.

Tool Count2/5

With 40 tools, the server exceeds the 25+ threshold considered too many. While GIMP is complex and many operations are genuinely distinct, the count feels heavy for an MCP surface and could be streamlined without sacrificing core functionality.

Completeness4/5

The tool set covers image creation/opening/saving/export, layer CRUD and properties, transformations, selections, basic color adjustments, and undo/redo. Missing advanced features like filters and text tools are mitigated by the PDB access tools, allowing agents to invoke arbitrary GIMP procedures. Minor gaps remain, but the core workflow is complete.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

APICK AI A
app.apick
LLM chat, text tools, image generation, editing and batch image jobs
AI & Machine Learning Image & Video Processing
911
Agent-Native DesignOAuth
io.github.BuilderIO
Agent-Native design tool - create and edit visual designs with agent assistance
Design Tools Image & Video Processing Autonomous Agents
14,698
runcomfy-mcp AOAuth
io.github.runcomfy-com
Remote MCP for RunComfy: ComfyUI deployments, hosted models, LoRA training. 31 tools.
AI & Machine Learning Cloud Platforms Image & Video Processing
2
Goodeye AOAuth
dev.goodeye
Design, save, and run outcome-aligned AI workflows and verifiers, with reliable image output.
Agent Orchestration AI & Machine Learning Image & Video Processing
8024

Related MCP Servers

GIMP MCP
Image & Video Processing Design Tools
martinduartemore
A
license
Not graded
quality
D
maintenance
Enables AI models and external applications to control GIMP remotely via the Model Context Protocol, allowing image manipulation and object querying through natural language.
Updated a year ago (2025-07-13 23:33 UTC)
3
MIT
gimp-mcp
Image & Video Processing Design Tools
abelduarte
A
license
A
quality
D
maintenance
Control GIMP from AI assistants via the Model Context Protocol, enabling image editing automation through natural language commands.
Updated 5 months ago (2026-04-12 00:11 UTC)
18
5
MIT
gimp-mcp
Image & Video Processing Design Tools
constant-itis
A
license
Not graded
quality
B
maintenance
Enables AI agents to control GIMP 2.10 through its Script-Fu server, providing access to the entire GIMP procedure database with a vision feedback loop for iterative editing.
Updated a month ago (2026-07-31 22:37 UTC)
6
AGPL 3.0
gimp-mcp
Image & Video Processing Design Tools
mrfentmen
A
license
Not graded
quality
C
maintenance
Enables AI agents to control GIMP for image editing tasks such as opening, resizing, filtering, exporting, and batch processing images through Python-Fu scripting.
Updated a month ago (2026-08-08 14:01 UTC)
33
MIT