Daz3D-MCP

Overview Schema Source Related Servers Discussions Admin

render_shots

Renders a dialogue scene as a sequence of visual-novel shots, setting faces, gazes, and camera per beat and saving images plus a shots.json manifest.

Instructions

Renders a dialogue scene as a series of shots for a visual novel: for each beat it sets the faces and gazes, frames the camera (camera_shot) and renders, into NN_ images plus a shots.json listing every beat, its line and its camera. Waits until all are done; it takes about beats x max_time, so render a few beats first and ask the user before a long run.

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": {
      "beats": "<beats>"
    },
    "name": "render_shots"
  }
}

Input Schema

Name	Required	Description	Default
`only`	No	Render just these beat numbers (1-based), e.g. to redo one; the others still set their faces so the state carries over.
`beats`	Yes	The conversation in order, one beat per image.
`width`	No
`camera`	No	Camera every beat uses (created if missing).	Shot
`height`	No
`resume`	No	Keep images already in out_dir and render only the missing ones (faces, gazes and cameras are still set).
`out_dir`	No	Absolute folder; default a new folder in ~/.daz3d-mcp/renders/.
`quality`	No
`max_time`	No	Seconds per image. Set it: the total is about beats x max_time.
`previews`	No	Images to return.
`max_samples`	No	Per image.
`image_format`	No		png
`preview_size`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Nov 13, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Adds real behavior beyond the annotations (non-read-only, non-destructive, non-open-world): it blocks until all images are done, cost scales with beats x max_time, and it rewrites scene state by setting faces, gazes and cameras. It never says whether existing files in out_dir are overwritten or what happens if a render fails mid-batch, which matters for a long blocking write operation.

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 sentences, purpose front-loaded, then outputs, then the timing warning. Dense but readable; the middle sentence carries a lot of clauses that could be split for scanning, though nothing is wasted.

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?

For a 13-param batch tool with no output schema, it covers what is produced (numbered images plus shots.json with beats, lines, cameras) and the runtime model. Missing only failure/overwrite semantics and confirmation that preview images are returned, which are minor gaps at this complexity.

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 coverage is 62%, and the description clarifies the semantic core of beats (one moment of conversation, faces/gazes applied before the render) and the cost implication of max_time. Half a dozen params (only, resume, previews, out_dir, quality) get no mention and rely entirely on their schema text, so it only partially compensates.

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 concrete verb and resource ('Renders a dialogue scene as a series of shots for a visual novel') and names both outputs (NN_<name> images and shots.json). The per-beat pipeline (set faces/gazes, frame camera via camera_shot, render) makes it distinguishable from the single-shot render and camera_shot siblings.

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

Usage Guidelines4/5

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

Gives operational guidance: start with a few beats and ask the user before a long run, since runtime is roughly beats x max_time. It does not explicitly state when to prefer this over render or render_animation for non-dialogue work, so the sibling routing is left implicit.

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

Deploy Server