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.

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.

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.

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.

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.

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.

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

With no annotations provided, the description carries the full burden and does well: it declares the operation irreversible, explains that only contents are removed while the workspace is retained, and describes the confirmation contract (elicitation prompt, or explicit confirm=true for automation/tests). It omits error behavior and whether repeated invocation is safe.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the verb/resource pair, then parameter semantics, then the destructive warning — an appropriate order with little waste. The mid-sentence line break before 'what selects drawings' is a minor formatting rough edge.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter destructive tool with no annotations and no output schema, the description covers purpose, scope, irreversibility and the confirmation flow, which is most of what an agent needs. Residual gaps are the meaning/path format of 'workspace' and any post-deletion result or error reporting.

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

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 does for two of three parameters: 'what' enumerates drawings/render/scripts/orphans/all with the default, and 'confirm' explains the prompt-vs-explicit-true flow. The 'workspace' parameter is only implied rather than defined (name vs. path).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Delete) and resource (a workspace's generated files) plus the benefit (reclaim disk space). It also implicitly distinguishes itself from the sibling opentoonz_delete_workspace by clarifying that 'Only the contents are removed — the workspace itself is kept.'

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

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

Gives clear context (reclaim disk space) and explains the selection semantics of 'what', including the default of 'all'. It does not name opentoonz_delete_workspace as the alternative when the workspace itself should be removed, nor state prerequisites such as the workspace existing.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses idempotency, the folder layout created, and that the shared OpenToonz 'stuff' tree is intentionally NOT copied per workspace. It omits error/failure behavior and naming constraints, but the core behavioral traits of the operation are surfaced.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, front-loaded with the verb and the key behavioral trait (idempotent) in parentheses, then a compact explanation of layout. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 described, and the description adequately covers the folder contents and shared-tree behavior. Only the parameter contract is left unexplained, a minor gap for such a simple, single-parameter tool.

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

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

Schema coverage is 0% for the single 'name' parameter, and the description does nothing to compensate, giving no hint about naming rules, allowed characters, or uniqueness. The agent must guess what a valid workspace name looks like from the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description pairs a specific verb ("Create") with a specific resource ("workspace folder") and clarifies what a workspace contains (drawings/, render/, scripts/), which separates it cleanly from siblings like opentoonz_list_workspaces and opentoonz_delete_workspace. It does not explicitly name or contrast those siblings, but the intent is unmistakable.

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

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

Usage is only implied: an agent can infer that a workspace must exist before drawings/render/scripts work, but the description never states when to create one versus reusing an existing workspace (list_workspaces) or how it relates to scene creation. No explicit when-to-use or when-not guidance is given.

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

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

No annotations are provided, so the description carries the full burden, and it does: it declares irreversibility, describes the confirmation flow (elicitation prompt when supported, otherwise confirm=true), and explains the destructive consequence of removing scenes and renders. This is rich context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action, then the sibling distinction, then the confirmation mechanics. Every sentence earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation tool with no annotations and no output schema, the description covers consequence, irreversibility, alternative routing, and confirmation behavior—everything an agent needs to invoke it safely and correctly.

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

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. It explains the semantics of confirm—that it is the fallback confirmation mechanism when elicitation is unavailable—which is the key parameter behavior not inferable from the boolean type and default. It does not describe workspace's format, but that is a minor omission.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (delete) and resource (workspace) with explicit scope: 'including its scenes and renders.' It directly distinguishes itself from the sibling opentoonz_clean by contrasting their behaviors.

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

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

Explicitly names the alternative (opentoonz_clean) and states the selection condition: clean empties but keeps usable, this removes entirely. It also explains when confirm is needed vs. elicitation.

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

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

With no annotations, the description carries the full burden and does well on the one behavior that matters: it discloses that smoke=true launches OpenToonz, costs a few seconds, and is off by default. It stops short of broader behavioral context (e.g., whether diagnostics write files or require a valid install).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short paragraphs: the purpose is front-loaded, and the second explains the single parameter's tradeoff without repetition. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-optional-param diagnostic with an existing output schema, the description is nearly complete — return values need not be explained and the smoke semantics are covered. The one gap is the missing distinction from the similar opentoonz_health tool.

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

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

Schema coverage is 0% for the single boolean, but the description more than compensates: it defines what smoke=true actually does, that it proves runtime execution rather than mere binary existence, its cost, and its default. That is real meaning beyond `{"type": "boolean"}`.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — a 'full diagnostic' yielding 'resolved paths, versions, and prepared state' — so it's clearly distinct from the rendering/drawing/workspace siblings. However, it never differentiates itself from the very similar opentoonz_health sibling, leaving ambiguity about which to pick.

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

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

There is no statement of when to run this tool versus opentoonz_health or opentoonz_scene_info. The only conditional guidance concerns the smoke flag's runtime cost, not tool selection, so usage remains inferred.

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

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

With no annotations, the description carries the full burden and does disclose real behavior: PIL-based drawing, the supported op vocabulary, that the 'image' op composites an existing PNG, and the exact output path/format (<workspace>/drawings/<level_name>.<frame>.png). It omits overwrite semantics for an existing drawing file and any failure behavior, which are the notable remaining gaps for a file-writing tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose in the first clause, then ops structure, then the output location and downstream consumer. No filler sentences; the 'see docs/tools.md' pointer replaces what would otherwise be a long op-schema dump.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 covers the ops contract and output artifact. However, with no annotations and 0% schema coverage, the silent width/height/background parameters and the missing overwrite behavior leave the definition short of complete for a 7-parameter file-producing tool.

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

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, and it only partly does: ops is explained with its type vocabulary and structure, and frame/level_name/workspace are inferable from the documented output path. Width, height, and background get no mention anywhere, leaving three of seven parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Draw one RGBA frame'), names the concrete technique (PIL primitives) and the artifact produced (a level drawing saved to a path). The word 'one' implicitly distinguishes it from the plural sibling opentoonz_draw_frames, though it never names that sibling 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.

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

Usage is only implied through the output path being 'ready for opentoonz_import_images_as_level', which hints at a downstream workflow. It never says when to use this tool rather than opentoonz_draw_frames (plural), opentoonz_tween_frames, or opentoonz_render_frame, and gives no exclusions or prerequisites.

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

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that resulting rows are contiguous and that the scene's frame count follows what is placed, which is real consequence information. It does not say whether existing exposure/column content is overwritten, whether the change is persisted to disk, or what happens to prior timing on the level.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences that each earn their place: purpose, exposures semantics with examples, layout/frame-count consequences, and prerequisite. The core behavior is front-loaded and the examples are compact rather than verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 described. For a 6-parameter mutating tool with zero schema description coverage and no annotations, the description covers the critical exposures semantics but omits column and start_row semantics and any statement about overwrite/persistence behavior, leaving meaningful gaps.

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

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 does this well for the hardest parameter, exposures, explaining single-value vs per-drawing arrays with concrete examples ([3] vs [2, 4, 1]), and it ties level/scene to the 'already in the scene' prerequisite. However, column and start_row receive no explanation at all, leaving a substantive portion of the 6 parameters undocumented in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Time a level's drawings on the xsheet by holding each one for N frames.' An agent can immediately tell this is exposure/timing assignment, distinct from a generic cell-setter. It does not, however, explicitly contrast itself with the nearby opentoonz_set_cells, leaving sibling differentiation implicit.

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

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

It gives a clear prerequisite for use: the level must already be in the scene, and it routes the agent to opentoonz_import_images_as_level to satisfy that precondition. No alternatives or when-not-to-use conditions are stated, so it stops short of full routing guidance.

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

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

With no annotations, the description carries full behavioral burden and does so: it discloses the destructive side effect ('Previous drawings for the same level are cleared first'), the disk-safety cap (max_frames default 5000), and that fps default preserves source rate. These are exactly the traits an agent needs to invoke safely.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose in one sentence, then groups workflow, parameter tuning, and destructive caveat into tight, scannable sentences. No wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 isn't needed, and the description covers the mutation/disk behavior and key params for a complex 8-param tool. Minor gap: workspace/level_name/video semantics are left implicit.

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

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

Schema coverage is 0%, so the description must compensate, and it does for fps, start/end (seconds), max_width (downscale), and max_frames (cap/default). The remaining params workspace, level_name, and video are only indirectly covered, leaving a small gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource with output destination: extract a video's frames into drawings/<level_name>.%04d.png as a level. This distinguishes it clearly from the render tools and from opentoonz_import_images_as_level without needing the schema.

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

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

Explicitly names the downstream workflow and sibling: 'extract, then pass the returned paths to opentoonz_import_images_as_level,' and gives the condition for adjusting start/end/fps ('for more'). The agent knows both when to use it and what to do next.

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

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

No annotations are provided, so the description carries the full disclosure burden. It usefully names the three components probed, but says nothing about whether it fails fast, reports per-component status, or has side effects — though the read-only nature is strongly implied by 'availability check' and the return shape is covered by the output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One front-loaded sentence with no filler; the resource list is the only detail and it earns its place by defining the probe's scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only health probe with an output schema covering return values, the description supplies enough to call it correctly. The only missing piece is how it relates to opentoonz_doctor, which the sibling list makes relevant.

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

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

The tool takes zero parameters and the description correctly introduces none, so there is no parameter semantics to clarify. Baseline 4 applies for a parameterless tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('availability check') and enumerates exactly what is checked (runtime, tcomposer, ffmpeg), so an agent knows this is a dependency probe, not an action. It does not differentiate itself from the similarly-scoped sibling opentoonz_doctor, leaving ambiguity about which probe to prefer.

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

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

The word 'Quick' implies a lightweight pre-flight check, which hints at when to call it, but there is no explicit when-to-use, no exclusion, and no mention of opentoonz_doctor as the heavier alternative. Usage is only inferred from tone.

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

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

With no annotations, the description carries the full burden and does well: it discloses additivity (existing scene is loaded first), the RGBA PNG conversion and the <level_name>.%04d.png naming, 1:1 centred compositing, and — critically — that re-importing a level_name overwrites its drawings. It still omits permissions/workspace requirements and any failure or ordering-validation behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded in one sentence, and the following paragraphs each carry distinct information (additivity/naming/compositing, then re-import semantics). It is slightly longer than necessary but every paragraph earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 described. The description covers the non-obvious behaviors an agent needs — additivity, naming, compositing scale, and overwrite-on-reimport — but leaves workspace and start_row unexplained, which for a 6-parameter tool is a modest gap.

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

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 six undocumented parameters. It explains level_name (reuse/overwrite semantics), column (via repeated calls), scene (existing scene is loaded), and ordering of image_paths, but start_row and workspace are never mentioned, leaving real gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource ('import an ordered image sequence as a raster level') plus the side effect ('place it on the xsheet'). This clearly separates it from siblings like opentoonz_extract_frames, opentoonz_draw_frames, and opentoonz_set_cells, which write content by other means.

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

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

It gives concrete when-to-use context: call repeatedly with different level_name/column to build a multi-level scene, and re-import the same level_name to iterate on art. It does not name an alternative tool or state when *not* to use this (e.g. vs. drawing frames directly), so it falls short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return content (workspaces, scenes, rendered videos), which is useful, but says nothing about read-only nature, side effects, pagination, or performance. 'List' implies a non-destructive read, which is a mild signal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler, immediately conveying the resource and the nested content returned.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and no annotations, so the description is the only source of truth. It sketches the return shape (workspaces with scenes and rendered videos) but omits output format details and any behavioral context; adequate for a trivial parameterless list tool, but with gaps.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4 with no schema semantics to compensate for. The description adds nothing here because there is nothing to add.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List workspaces') and adds scope by noting it returns scenes and rendered videos. This distinguishes it from narrow siblings like opentoonz_scene_info, though it doesn't explicitly contrast with other list/introspection tools such as opentoonz_health or opentoonz_doctor.

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

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

There is no guidance on when to use this versus alternatives. With many read/introspection siblings (scene_info, health, doctor) plus workspace mutation tools (create/delete), the description never says when listing workspaces is the right call or what prerequisites exist.

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

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

With no annotations provided, the description carries the burden. It discloses the output path and that ranges are cheaper, but doesn't state whether rendering mutates existing files, requires a valid workspace/scene to exist, or what happens on error. Adds some useful behavior (cost of full-scene render) but leaves key operational traits uncovered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and output target, then a compact second sentence on range behavior. Two sentences, zero padding, every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter tool with 0% schema coverage and no output schema, the description is thin: it omits the meaning of workspace, scene, and out_name. It does convey the core render-range use case, but an agent would lack the parameter context needed to call it confidently.

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

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

Schema coverage is 0% and none of the parameters have descriptions in the schema, so the description must compensate. It explains start/end semantics (inclusive range, must be given together) but says nothing about workspace, scene, or out_name — out_name silently defaults to 'render' and its effect on the output path is never clarified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Render) and resource (scene to PNG frames) plus the output location and tool (tcomposer). It distinguishes itself from render_video, render_gif, and render_frame, but doesn't explicitly name them or clarify the PNG-vs-video boundary, which is the key sibling distinction.

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

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

Explains the default range behavior (whole scene) and the cheaper alternative (start+end together), which is useful when-to-use guidance. However, it doesn't address when to prefer render_frame, render_video, render_gif, or render_batch over this tool.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses per-scene failure isolation ('One scene failing does not stop the rest'), per-scene OK/FAILED reporting, and output naming, but it leaves side effects such as overwrite behavior, output location, and auth requirements unstated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is three short paragraphs with the core purpose front-loaded and no obvious filler. The parameter guidelines are dense but readable, though the final sentence about the structured payload slightly duplicates the preceding reply-format statement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter batch tool with no annotations and no output schema, the description covers core behavior, parameter applicability, output reporting, and failure isolation. It is not fully complete because out_name/workspace remain undocumented and sibling routing is left implicit.

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

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

Schema description coverage is 0%, so the description must supply parameter meaning. It does this well for most parameters: scenes defaults to every scene, kind accepts frames/video/gif, fps applies to video/gif, start/end are inclusive and frames-only, and crf/scale are video-only. However, out_name and workspace are not explained at all.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Render several scenes in one call, reporting each scene's own result.' The word 'several' and 'batch' distinguish it from single-scene render siblings such as opentoonz_render_frame or opentoonz_render_video, but 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.

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

Usage is implied for multi-scene batch rendering, but the description does not say when to choose this over single-scene render tools or over opentoonz_render_video/opentoonz_render_gif. It explains parameter applicability once the tool is selected, not when to select it.

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

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

With no annotations, the description carries the full behavioral burden and discharges it well: the image is returned inline AND written to disk, downscaling is preview-only, the default width is 768px, and max_width=0 restores full resolution. It does not state overwrite behavior, permissions, or what happens if the frame doesn't exist, but it is far richer than a bare 'render' description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then the token-saving rationale, then the max_width escape hatch. Three tight sentences, no repetition, every clause carries information an agent would otherwise have to guess.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter tool with no annotations and no output schema, the description covers the return channel and the key sizing parameter thoroughly. The remaining gap is out_name, which determines the on-disk artifact name but is never mentioned, and no guidance on workspace/scene requirements.

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

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

Schema coverage is 0% across 5 parameters, so the description must compensate, and it does so well for max_width (default downscale to 768px, 0 means full resolution) — a parameter whose schema default of null is otherwise opaque. It says nothing about frame, scene, workspace, or out_name (the on-disk filename, default 'look'), leaving the majority of parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (render a single frame to PNG) and frames it as the agent's 'look' at the result. It also distinguishes itself from opentoonz_render and opentoonz_render_video by stating their output is never downscaled, so an agent can tell which render tool to reach for.

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

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

The description explains the intended use case (inspecting a frame cheaply, no extra round-trip) and when to vary behavior via max_width. It stops short of an explicit 'use this instead of opentoonz_render when you only need to see the result' rule, so the routing 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.

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 discloses meaningful traits: the palette cap (2–256), downscaling via max_width, no audio support, and lossy resolution trade-offs. It does not say where the output file is written or whether existing files are overwritten, which is the remaining gap for a write-to-disk tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action, then parameter guidance, then sibling routing. Every clause carries information; no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations, no output schema, and 6 parameters at 0% schema coverage, the description would need to cover more ground. It handles the rendering parameters well but leaves workspace/scene identity and output naming/location unexplained.

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

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, and it does explain fps, max_width, and colors with usable ranges and intent. However, scene, workspace, and out_name (default 'reel', i.e. where the artifact lands) are entirely undocumented in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Render a scene to a looping GIF') and immediately positions it against the sibling opentoonz_render_video by naming the distinguishing axis (audio/full resolution). An agent can select it without opening the schema.

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

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

Explicitly routes the alternative case: 'use that [render_video] for anything with audio or that must stay full resolution,' which is a concrete when-not condition. It also clarifies that frames come from the same tcomposer pass, removing a workflow ambiguity.

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

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

With no annotations, the description carries the full burden and does add real value: it discloses that audio always comes from an external file because OpenToonz audio columns are unreachable via the scripting API, that audio is AAC-encoded and truncated to video length, and the crf/scale tradeoffs. It still omits key operational behavior for a file-producing tool: output location, whether an existing file is overwritten, failure modes, and roughly how long/synchronous the render is.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and then devotes short, purposeful sentences to each optional parameter. The aside about OpenToonz audio columns is slightly discursive but justifies a non-obvious constraint, so most sentences earn their place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter, no-annotation, no-output-schema tool that writes a file, the description covers the video-specific knobs but leaves the required identifiers (workspace, scene), output naming/location, fps, and overwrite behavior to the bare schema. It is adequate to start a call but not to predict the result confidently.

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

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

Schema coverage is 0%, so the description must compensate, and it explains 3 of 7 parameters well (audio source format, crf range 0-51 and direction, scale as a positive factor). The required workspace and scene parameters, plus out_name and fps (default 24), get no semantic explanation at all, leaving nearly half the surface undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names a specific verb (render), resource (scene), and concrete output (MP4 muxed with ffmpeg), so the agent knows exactly what the tool produces. However, it never explicitly distinguishes itself from the many render siblings (opentoonz_render, opentoonz_render_gif, opentoonz_render_batch, opentoonz_render_frame), which the agent must infer from the format keyword 'MP4'.

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

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

Usage is only implied: the MP4/ffmpeg framing suggests 'use this when you want a video file', but there is no statement of when to prefer it over opentoonz_render or opentoonz_render_gif, nor any prerequisites such as the scene needing to exist or renders needing prior setup. No exclusions or alternatives are named.

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

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

With no annotations, the description carries the full behavioral burden and delivers key operational facts: execution is headless, print() output is returned via stdout, absolute paths are required, and new Renderer() deadlocks in CLI mode. It omits timeout behavior and sandbox/permission scope, but the deadlock caveat and stdout contract are genuinely valuable disclosures beyond any structured field.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and the escape-hatch framing, followed by a dense but useful API reference and critical warnings. Every element earns its place, though the inline API method list makes it dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an arbitrary-code-execution tool with an output schema already covering return values, the description supplies the API surface, output mechanism, and the critical Renderer deadlock warning. The remaining gap is that required parameters like workspace are left unexplained, but overall coverage of what an agent needs to call it correctly is strong.

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

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

Schema description coverage is 0%, so the description must explain the three parameters, but it only implies the semantics of 'code' (JS + API surface) and never addresses 'workspace' or 'timeout'. Two of three parameters remain undocumented anywhere.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Run arbitrary OpenToonz JavaScript headlessly,' and frames itself as 'the full-power escape hatch,' which signals its relationship to the specialized sibling tools. It also explicitly routes away from opentoonz_render, so an agent can differentiate it from at least one sibling without opening a schema.

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

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

Provides one explicit when-not rule (avoid new Renderer(), use opentoonz_render instead) and frames itself as the general escape hatch, but never states the broader condition of when to prefer this over the purpose-built siblings like opentoonz_set_cells or opentoonz_draw_frame. 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.

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

With no annotations, the description must carry behavioral disclosure, and it does add real value by explaining that the cell map is scanned row by row and truncated at max_rows, with the output flagging taller scenes. However, it omits any read-only framing, scene/workspace existence requirements, or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences that front-load what is reported and then qualify the one parameter with non-obvious behavior. Nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description should stand in for return-value documentation; it lists the reported fields (counts, levels, cell map) but gives no shape or format detail. It also leaves two of three parameters unexplained, so it is only adequate for a read tool.

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

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

Schema description coverage is 0%, so all three parameters rely on the description. max_rows is genuinely clarified (row-by-row scan, stops at the limit, output flags truncation), but workspace and scene carry no semantics at all beyond their names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Report) and enumerates exactly what is returned: frame/column counts, levels, and the cell map. This distinguishes it from mutation siblings like opentoonz_set_cells or opentoonz_scene_new, but it never names a sibling explicitly for contrast.

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

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

No guidance on when to reach for this instead of overlapping inspection tools (opentoonz_health, opentoonz_doctor, opentoonz_exposure). Usage is only implied by the word 'Report'; there are no conditions or exclusions stated.

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

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

With no annotations, the description carries the full burden and does disclose a key destructive trait: an existing scene may be overwritten. It also gives the default camera resolution (1920x1080) and compositing behavior (1:1, centred). It omits anything about required permissions or what happens to existing levels/cells on overwrite.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences, front-loaded with the primary action, and the follow-up compositing note is genuinely useful context rather than filler. Nothing is redundant, though it is arguably too brief given the undocumented parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 needn't be explained. However, for a 5-parameter scene-creation tool with no annotations and 0% schema coverage, the description leaves most parameters and the overwrite consequences under-specified.

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

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

Schema coverage is 0% for 5 parameters, so the description must compensate. It only gestures at resolution ('optionally setting its resolution'), leaving fps, the scene name (default 'main'), and the required workspace parameter entirely unexplained. This is a substantial gap over what the schema alone communicates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create ... an empty scene') plus the overwrite variant, so the operation is unambiguous. It does not explicitly differentiate itself from siblings like opentoonz_set_scene_settings or opentoonz_scene_info, so it falls 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.

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

Usage is only implied: 'Create (or overwrite)' hints this is the setup step that precedes drawing/rendering, but there is no explicit when-to-use versus set_scene_settings or when-not to use guidance. The overwrite caveat is useful but is behavioral rather than routing guidance.

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

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

With no annotations, the description carries the full burden. It does disclose a meaningful precondition (levels must exist) and implies overwrite semantics via 'replace', but says nothing about what happens to pre-existing xsheet content at those rows, error behavior for a missing level, or required authorization.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, zero filler, and the core operation is front-loaded before the placement schema and the routing note.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 no prose, and the description covers the operation, the placement record shape, and the level precondition. Remaining gaps are minor: no explicit statement about overwriting existing cells or failure modes when a level or scene is missing.

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

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

Schema description coverage is 0% and the placements array items are untyped objects (additionalProperties: true), so the description is the only source for the placement shape. It documents row/col/level/fid with types, which is substantial added value; only workspace/scene remain unexplained, though they are self-evident from siblings.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Place/replace cells on a scene's xsheet') and names both a sibling to use instead (opentoonz_exposure) and one whose output it depends on (opentoonz_import_images_as_level). An agent can distinguish it from the other opentoonz_* tools without opening the schema.

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

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

Gives an explicit conditional alternative: for the common 'hold each drawing for N frames' task, use opentoonz_exposure rather than computing rows manually. It also states the prerequisite that levels must already exist, pointing to the tool that creates them.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the scene file's XML is patched directly (because the scripting API lacks setters), that changes persist through later edits, and that partial updates are allowed (omitted width/height keep their value). It stops short of stating permission requirements, error behavior, or whether the change is reversible.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences that front-load the effect before the implementation detail. The example and the direct-XML note both earn their place; only minor polish is missing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 described, and the description instead covers the mutation's mechanics and follow-up actions (re-render, redraw art) that an agent genuinely needs. The only real gap is the unexplained required `workspace`/`scene` parameters.

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

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

Schema coverage is 0%, so the description must compensate, and it does partially: it explains the semantics of `width` and `height` (independently settable, omitted keeps value) and covers `fps` implicitly. But the required `workspace` and `scene` parameters are never mentioned, leaving two of five parameters undocumented anywhere.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Change') and resource ('a scene's camera resolution and/or frame rate') with a concrete example (1080p -> 720p). An agent can immediately distinguish it from the render/workspace/cell siblings without opening the schema.

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

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

Usage is implied by the effect ('re-render after changing this, and draw new art at the new size'), which tells the agent the downstream implications. However, no alternatives or when-not conditions are named, so the agent must infer that this is the way to change resolution/fps rather than, say, a render or scene_new tool.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the tool writes a rendered PNG sequence to <workspace>/drawings/<level_name>.%04d.png, states the naming pattern, and explains anchor/neutral-field behavior. It does not mention overwrite semantics or that an existing sequence may be replaced, which is a notable gap for a file-writing tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then the necessary JSON shape and field semantics. The embedded object example is justified given the empty schema, though the description could trim a little redundancy in the anchor sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, nested-object, file-producing tool, the description covers the hard parts (object shape, anchor semantics, output path, follow-up tool) and an output schema exists so return values need no prose. Remaining unstated items (resolution/background defaults, overwrite behavior) are minor but real.

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

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

Schema coverage is 0% and the start/end params are opaque additionalProperties objects, so the description's inline shape (path, xy, scale, rotation, opacity) is essential and well supplied, plus the semantic detail that xy is the CENTRE and omitted fields stay neutral. It leaves width, height, background and the frames unit unexplained, keeping it below 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Tween one drawing from a start pose to an end pose'), describes the produced artifact, and explains why the tool exists (GUI-only auto-inbetweening). An agent can distinguish this from siblings like opentoonz_draw_frames or opentoonz_render_frame immediately.

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

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

Explicitly routes the agent to the follow-up sibling opentoonz_import_images_as_level and clarifies this tool's role versus the GUI workflow. It does not state exclusions (e.g. when not to use it vs opentoonz_draw_frames for a fixed pose), so it stops short of a full 5.

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