Skip to main content
Glama
gimp-mcp-studio
by Onru-Labs

batch_export

Exports all open GIMP images or one selected image to a directory as PNG, JPEG, WebP, or TIFF, with configurable quality and filename patterns.

Instructions

Export all open images (or a specific one) to a directory.

Parameters:

  • output_dir: Directory to write exported files into

  • format: "png", "jpeg", "webp", "tiff" (default "png")

  • quality: JPEG/WEBP quality (default 90)

  • name_pattern: Filename template — use {name} for image name, {index} for position

  • image_index: If set, export only that image; omit to export all open images

Returns:

  • exported: list of {file_path, name, width, height}

  • count: number of files written

  • errors: list of any export errors

Input Schema

NameRequiredDescriptionDefault
formatNopng
qualityNo
output_dirYes
image_indexNo
name_patternNo{name}

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full burden. It does disclose the return payload (exported, count, errors) and partial-failure reporting, which is genuinely useful given there is no output schema. It omits whether existing files are overwritten, whether the extension is appended automatically, and whether unsaved edits are included.

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?

Front-loaded with a one-line purpose, then two scannable blocks for parameters and returns; no filler sentences. The labeled list is slightly mechanical, but every entry carries information the schema lacks.

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 5-parameter export tool with no annotations and no output schema, the description covers scope, all inputs, and the return shape, which is close to sufficient. The remaining gap is file-collision/overwrite behavior and whether writes require a writable directory or elevated permissions.

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

Parameters5/5

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

With 0% schema description coverage, the description fully compensates: every one of the 5 parameters gets meaning beyond its bare title, including the allowed format values, quality defaults and its JPEG/WEBP-only scope, and the {name}/{index} placeholders in name_pattern. The image_index note about omitting it to export all is a semantic rule the schema cannot express.

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?

States a specific verb and resource ('Export all open images ... to a directory') plus the scope toggle (all vs. a single image), so the agent can tell this is a bulk operation. It does not name the obvious single-image sibling (export_image), so differentiation is inferred rather than stated.

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 through the image_index semantics ('omit to export all open images'), which tells the agent how to switch between batch and single export. However, it never names export_image as the alternative for one-off exports, nor does it state prerequisites such as having images open or an existing/writable output_dir.

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