Skip to main content
Glama
Sign In
Daz3D-MCP

Daz3D-MCP

by MictlanLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

render_animation

Renders an animation or selected frame range with Iray, saves one image per frame, and joins them into an MP4 or GIF for playback.

Instructions

Renders the whole animation (or a frame range) with Iray, one image per frame, and joins them into an MP4 or GIF. Waits until it is done. It takes about frames x max_time: render a short range or a few frames (step) first, and ask the user before a long render.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "render_animation"
  }
}

Input Schema

NameRequiredDescriptionDefault
fpsNoVideo frame rate; default timeline fps / step.
nameNoFile name start: <name>_0000.png ...frame
stepNoRender every n-th frame (2 = half the frames).
widthNo
cameraNoCamera label; default is the active one.
heightNo
resumeNoKeep frames already in out_dir and render only the missing ones (to continue a stopped render).
out_dirNoAbsolute folder for the frames and the video; default a new folder in ~/.daz3d-mcp/renders/.
qualityNo
max_timeNoSeconds per frame. Set it: the total is about frames x max_time.
previewsNoFrames to return as images.
end_frameNoDefault: end of the timeline range.
max_samplesNoPer frame.
start_frameNoDefault: start of the timeline range.
image_formatNopng
preview_sizeNo
video_formatNoAlso join the frames into a video (needs ffmpeg; Daz Studio ships one).mp4

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A3.9/5.0
Behavior4/5

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

Adds behavior beyond the annotations: the call blocks until complete ('Waits until it is done'), the runtime is roughly frames x max_time, and partial output can be continued via resume. Annotations only say it is a non-read-only, closed-world, non-destructive write; the timing/blocking warning is the genuinely useful addition. It does not discuss what is left on disk on failure or how ffmpeg absence surfaces.

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, front-loaded with what gets produced, then the cost formula, then the caution. No filler; the parenthetical '(step)' is slightly compressed but still readable.

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 17-parameter, long-running, blocking job with no output schema, the description covers scope, duration expectation, and the main safety practice (preview short, ask before long). Remaining gaps, such as how previews and the returned images are delivered, are handled by the schema's previews/preview_size fields.

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 71%, so the schema documents most parameters (resume, out_dir, max_time, start/end_frame, video_format). The description reinforces the step and max_time cost model but adds little syntax or default meaning not already in the schema; width/height/quality/max_samples remain bare in both places.

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 clear verb+resource+scope: 'Renders the whole animation (or a frame range) with Iray, one image per frame, and joins them into an MP4 or GIF.' The output artifacts (frames + video) are explicit, so it is distinguishable from a still-render sibling by the animation scope, though no sibling is named.

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 concrete when-to guidance: 'render a short range or a few frames (step) first, and ask the user before a long render,' which is an actionable cost-control rule. It stops short of naming an alternative tool (e.g., the still 'render' sibling) for single-frame work.

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