opentoonz-mcp

Overview Schema Source Related Servers Discussions Admin

Opentoonz Draw Frames

opentoonz_draw_frames

Draw and export an entire frame sequence from per-frame operation lists, saving each as a numbered PNG in the workspace and returning file paths.

Instructions

Draw a whole sequence of frames, one op-list per frame.

frames: list where each item is a list of ops for that frame (frame 1 first). Saves /drawings/<level_name>.%04d.png and returns the paths.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workspace": "<workspace>",
      "level_name": "<level_name>",
      "frames": "<frames>"
    },
    "name": "opentoonz_draw_frames"
  }
}

Input Schema

Name	Required	Default
`width`	No
`frames`	Yes
`height`	No
`workspace`	Yes
`background`	No	#181a2e
`level_name`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.8.0Oct 17, 2026

TDQS

A3.5/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 full burden. It does disclose a real behavioral trait beyond the schema: the file side effect and naming convention ('Saves <workspace>/drawings/<level_name>.%04d.png') and that paths are returned. However, it omits overwrite behavior when level_name collides, permission needs, and failure modes, which matters for a tool that writes a whole sequence.

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?

Three short lines, front-loaded with the action and scope, then the parameter detail, then the side effect. Every sentence earns its place; no filler or repetition.

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-value explanation is not required, yet the description still notes paths are returned. Combined with the documented frames shape and output path, an agent has enough to invoke it correctly; the only real gap is the unmentioned rendering parameters, which are low-risk defaults.

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 there are 6 parameters, so the description should compensate. It explains the most important nested parameter ('frames: list where each item is a list of ops for that frame (frame 1 first)') and ties workspace/level_name to the output path, but width, height, and background are never mentioned (their names and defaults make them largely self-explanatory).

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 ('Draw a whole sequence of frames') and the scope ('one op-list per frame') separates it implicitly from the singular sibling opentoonz_draw_frame. It is clear what the tool does, though it never names the single-frame alternative explicitly, so the differentiation is left to inference.

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 rather than stated: 'a whole sequence of frames' signals the batch case versus opentoonz_draw_frame, but there is no explicit when-to-use/when-not guidance or prerequisites (e.g. must a level already exist). Adequate but leaves routing decisions to inference.

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