Skip to main content
Glama

flip

Mirror an entire image or a selected layer horizontally or vertically to correct orientation or create symmetrical artwork.

Instructions

Mirror the whole image (target=image) or one layer (target=layer). direction: horizontal or vertical.

Input Schema

NameRequiredDescriptionDefault
layerNo
targetNoimage
directionNohorizontal

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full behavioral burden. It never states whether the flip is applied in place, whether it is undoable, whether it affects the active selection or canvas dimensions, or what the caller receives back; for a mutating image operation this leaves significant gaps.

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?

Two short sentences, front-loaded with the operation and its scope split, then the direction options. Every clause carries useful information and nothing is padded.

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?

With zero required parameters, no annotations, and no output schema, the description covers the happy path of target and direction but omits what happens on success, how the layer argument is resolved, and what defaults do when arguments are omitted.

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% and no parameter has an enum, so the description legitimately adds value by enumerating target=image/layer and direction=horizontal/vertical. However, the `layer` parameter is never explained: it is unclear how a layer is identified (name vs id) or that it only applies when target=layer.

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?

"Mirror the whole image (target=image) or one layer (target=layer)" names a specific verb (mirror/flip) and resource, and immediately splits the operation by scope. An agent can distinguish it from rotate_image or crop_image without opening any schema, though no sibling is named explicitly.

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 operation itself: call this when a mirror is wanted on the image or a single layer. There is no explicit when-not guidance and no pointer to alternatives such as rotate_image or transform_layer for other transforms.

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