Skip to main content
Glama

set_cel_z_index

Reorder a cel within its frame using a z-index offset without moving layers. Fixes per-frame overlaps like an arm appearing in front one frame and behind the next.

Instructions

Reorder one cel against the other cels in its frame, without moving any layer.

This is the fix for "the arm is in front of the body this frame and behind it the
next". The alternatives are to restructure the layer stack, which changes every other
frame too, or to duplicate the arm onto a second layer and hide one of them per
frame; a z-index is per cel, so it says exactly what it means and only where it
applies.

`z` is an offset, not a position: 0 (the default for every cel) means "wherever this
cel's layer sits in the stack", a positive number moves the cel towards the front and
a negative one towards the back. A cel draws at its layer's stack position plus `z`,
and when two cels land on the same number the one with the larger `z` draws in front.
So `z=1` on a cel one layer below another is enough to put it in front of that one.

The ordering is scoped to the layer's siblings: a layer inside a group is ordered
against that group's other layers, and the group as a whole keeps its place. Returns
`order`, the frame's competing cels back to front, which is the part a caller cannot
see for themselves.

A z-index is per cel even when the cel is linked: two frames sharing one image share
their opacity and their properties, and do not share this. Verified against the
editor, because the opposite is the reasonable guess.

`z` must be between -32768 and 32767. The editor accepts a larger number in memory
and then stores it in a 16-bit field, so saving and reopening would silently turn it
into a different one, usually of the opposite sign.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
zYes
frameYes
layerYes
filenameYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.10.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only mark it as a mutation (readOnlyHint=false). The description adds crucial behavioral depth: z is an offset not a position, default 0, positive/negative movement, tie-breaking rule, scoping to sibling layers, per-cel behavior even when linked, the exact numeric range -32768 to 32767, and why larger values cause silent corruption on save. This is far beyond structured fields.

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 front-loaded with the core purpose and alternatives, then systematically explains z semantics, scoping, and edge cases. Every sentence adds value, though the overall length is substantial; it could be trimmed slightly without losing critical information.

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 a mutation tool with four required parameters, no output schema, and minimal annotations, the description covers the tool's behavior, constraints, return value (`order`), and scoping rules in full. An agent has everything needed to invoke it correctly.

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 carry the full load. It thoroughly explains the `z` parameter (meaning, range, tie-breaking) but leaves `filename`, `layer`, and `frame` without explicit definition, relying on the reader's inference from context. This is adequate for an expert but leaves clear 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 opens with a precise verb+resource: 'Reorder one cel against the other cels in its frame, without moving any layer.' It distinguishes from sibling tools by explaining the exact problem it solves and why alternative approaches (restructuring layers, duplicating cels) are inferior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use this tool ('the fix for the arm in front of the body this frame and behind it the next') and names the concrete alternatives (restructure layer stack, duplicate layer) along with their downsides. The agent can confidently select this tool over the alternatives.

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

Deploy Server

Other Tools