Skip to main content
Glama

Opentoonz Camera Move

opentoonz_camera_move

Animate an OpenToonz scene camera across a shot by keyframing pan, zoom, and rotation, then re-render to apply the move.

Instructions

Move the scene's camera over the shot — pan, zoom, and rotate.

keyframes: list of {"frame": int, "x": px, "y": px, "zoom": factor, "rotation": degrees, "ease": bool}. Only "frame" is required; the rest default to no movement (x=0, y=0, zoom=1, rotation=0, ease=false). "frame" is a 1-based shot frame — the same numbering as opentoonz_render_frame.

x/y are the camera's position in scene pixels: +x pans the view right and +y pans it up, so the artwork moves the opposite way. zoom is a magnification (2 renders the art twice as large), and rotation is in degrees, clockwise on screen, about the frame centre.

ease=true makes the camera glide out of that keyframe and into the next instead of moving at a constant speed — it eases the segment starting there, symmetrically, across every channel. Each segment eases on its own, so a run of eased keyframes settles at each pose; ease only the segments you want softened. The flag on the last keyframe does nothing, so adding ease=true to every keyframe eases the whole move.

The move is stored in the scene file as the camera's animation channels, so it survives later edits and stays editable in OpenToonz's Function Editor. Re-render to see it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sceneYes
keyframesYes
workspaceYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.8.0

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it documents default values, direction semantics for x/y/zoom/rotation, the symmetric segment-level effect of ease, and persistence details (stored as animation channels, survives edits, editable in Function Editor). This is well beyond what the empty annotations and thin schema provide.

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?

Purpose is front-loaded and the keyframe field is documented before the ease nuance. A few sentences are mildly redundant (restating that easing every keyframe eases the whole move), but overall the structure is efficient and earns its length.

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?

An output schema exists, so return values need not be explained, and the description adequately covers behavior for a no-annotation mutation tool. The only minor gap is the undocumented 'workspace' parameter.

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 coverage is 0%, so the description must compensate. It fully specifies the complex 'keyframes' object — required fields, defaults, and channel meanings — adding far more than the schema's bare array-of-object. 'workspace' and 'scene' are left undescribed, but their meaning is largely self-evident.

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?

States a specific verb and resource ('Move the scene's camera') with the concrete scope of the operation (pan, zoom, rotate). It is clearly distinguishable from rendering, drawing, and scene-management siblings.

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 rather than stated: it references 'Re-render to see it' and ties the 'frame' field to opentoonz_render_frame's numbering, which hints at the workflow. There is no explicit when-to-use/when-not guidance or named alternative for camera work.

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