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

redo

Reapply one or more previously undone operations to an image, with optional step count and image index.

Instructions

Redo one or more previously undone operations on an image.

Parameters:

  • steps: Number of redo steps (default 1)

  • image_index: Target image index (default 0)

Returns: {steps_redone}

Input Schema

NameRequiredDescriptionDefault
stepsNo
image_indexNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/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 full behavioral burden. It usefully discloses the return shape ({steps_redone}) and the per-call semantics of the steps parameter, but says nothing about error behavior when the redo history is empty, whether the operation requires an active image, or whether steps beyond the buffer are clamped. That is a meaningful gap for a history-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?

Front-loaded summary sentence followed by a compact bulleted parameter list and a one-line return note. Zero filler text; every line carries information.

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 two-optional-parameter history tool with no output schema, the definition covers purpose, defaults, and the returned field, which is most of what an agent needs. The remaining shortfall is the absence of failure-mode guidance, which matters more here because no annotations are supplied to indicate safety or mutation characteristics.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate for two bare integer properties. It does name both parameters and restates their defaults, but 'Number of redo steps' and 'Target image index' add little beyond the schema's own property titles — no units, bounds, or behavior for out-of-range values.

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 opens with a specific verb and resource: 'Redo one or more previously undone operations on an image.' That is clearly distinguishable from sibling tools like undo or the adjustment verbs. It does not explicitly name or contrast with any sibling, so it stops short of a 5.

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 phrase 'previously undone operations' implies the precondition that something must have been undone first, and that this is the counterpart to undo. But the description never states when to prefer this over undo, nor what happens if there is nothing in the redo buffer. Usage is implied rather than spelled out.

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