vangard-daz-mcp
This server is an MCP bridge that lets Claude and other MCP clients control DAZ Studio through DazScriptServer—covering scene inspection, editing, animation, rendering, and cinematic automation.
Query DAZ Studio status, scene contents, node properties, morphs, hierarchies, spatial relationships, and bounding boxes
Modify node transforms, morphs, lights, cameras, materials, and visibility; set parents; batch-set properties/transforms/visibility/selection
Pose characters: look-at points/characters, reach-toward, interactive poses, emotions, body language, gaze, expression morphs, pose save/load, reset pose
Control cameras: create, list, set active, orbit, frame to node, apply composition rules/camera angles/shot types, save/load camera presets
Manage lighting: create lights, apply lighting presets, visual styles, mood/time-of-day lighting, environment and atmosphere settings
Animate: set/get/remove keyframes, clear animations, control frame range/timeline, animate conversations, camera movements, shot sequences, storyboards
Render: sync/async renders, render with specific cameras, multi-camera batch renders, animation frame-sequence export, render quality presets, cancel/monitor requests
Browse/load DAZ content library: list categories, browse files, read .duf metadata, search/load products
Manage scene state: named in-memory checkpoints, export/import node configs to JSON
Work with materials: list/get/set/copy material properties, apply presets, convert shaders to Iray Uber
Wardrobe/dForce/export: fit/unfit clothing, run dForce simulation, bake, set subdivision, export FBX/OBJ
Execute arbitrary DazScript inline or from files, with static validation, documentation help, and automatic script registration/reconnection
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@vangard-daz-mcplist all camera nodes in the scene"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
vangard-daz-mcp
Version 0.5.0 | MCP Server for DAZ Studio
A Model Context Protocol (MCP) server that exposes DAZ Studio operations to Claude and other MCP clients. Built on FastMCP and wraps the DazScriptServer HTTP plugin.
What Is This?
This MCP server allows Claude (via Claude Desktop or other MCP clients) to control DAZ Studio directly (at least these are the aspirational goals, not all of them are working just yet!):
Query scene information (figures, cameras, lights, spatial positions)
Read and modify node properties (transforms, morphs)
Discover and apply morphs, including searching by name pattern
Traverse and manipulate scene hierarchies (parent/child, skeleton)
Apply emotional expressions to characters
Coordinate multi-character interactions (look-at, reach-toward, hug, handshake)
Execute batch operations (set multiple properties in one call, 5-10x faster)
Control cameras and viewport (orbit, frame, presets)
Create keyframe animations and export as image sequences
Trigger synchronous or asynchronous renders with cancellation support
Apply professional lighting presets and cinematography composition rules
Browse and query the DAZ content library
Save and restore named scene checkpoints
Generate complete scenes from natural language descriptions
Create multi-camera shot sequences (orbit, push-in, shot-reverse-shot)
Choreograph animated conversations with dialogue beats
Record and replay operation macros for workflow automation
Execute arbitrary DazScript code
Access comprehensive DazScript documentation and examples
The server acts as a bridge: MCP Client ↔ vangard-daz-mcp ↔ DazScriptServer plugin ↔ DAZ Studio 4.5+ or 6.25+
Related MCP server: LMStudio-MCP
Prerequisites
Before using this server, you need:
DAZ Studio installed and running — compatible with:
DAZ Studio 4.5+ (legacy/classic versions)
DAZ Studio 6.25+ (current versions)
DazScriptServer plugin — must match your DAZ Studio version:
Download from: https://github.com/bluemoonfoundry/daz-script-server
Install the DS4 build for DAZ Studio 4.x, or the DS6 build for DAZ Studio 6.x
Plugin must be running on port 18811 (default)
Authentication must be configured (API token auto-generated on first run)
Python 3.11+ for running the MCP server
uv package manager (recommended) or pip
Installation
1. Install uv (if you don't have it)
macOS / Linux:
curl -LsSf https://astral.sh/uv/install.sh | shWindows (PowerShell):
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"See uv installation docs for other options.
2. Clone and install
# Clone the repository
git clone https://github.com/bluemoonfoundry/daz-mcp-server.git
cd daz-mcp-server
# Install dependencies (creates .venv automatically)
uv sync
# Verify it works
uv run vangard-daz-mcp --helpUsing pip (alternative)
git clone https://github.com/bluemoonfoundry/daz-mcp-server.git
cd daz-mcp-server
pip install .
# Run the server
vangard-daz-mcpConfiguration
Environment Variables
Configure the server via environment variables:
Variable | Default | Description |
|
| DazScriptServer hostname |
|
| DazScriptServer port |
|
| Request timeout in seconds (increase for long renders) |
| (from file) | API token for authentication |
|
| Content browser API URL (if using a separate content service) |
Authentication
The server automatically reads the API token from ~/.daz3d/dazscriptserver_token.txt (the file created by DazScriptServer).
Override with environment variable:
export DAZ_API_TOKEN="your-token-here"Important: DazScriptServer must have authentication enabled (default). The MCP server cannot connect without a valid token.
MCP Client Configuration
Claude Desktop
Config file location:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
macOS / Linux:
{
"mcpServers": {
"vangard-daz-mcp": {
"command": "uv",
"args": [
"run",
"--project",
"/absolute/path/to/daz-mcp-server",
"vangard-daz-mcp"
],
"env": {
"DAZ_HOST": "localhost",
"DAZ_PORT": "18811"
}
}
}
}Windows:
{
"mcpServers": {
"vangard-daz-mcp": {
"command": "uv",
"args": [
"run",
"--project",
"C:\\Users\\YourName\\daz-mcp-server",
"vangard-daz-mcp"
],
"env": {
"DAZ_HOST": "localhost",
"DAZ_PORT": "18811"
}
}
}
}Replace the path with the actual location where you cloned the repo. Use --project (not --directory) so uv run picks up the project's .venv.
After saving the config, restart Claude Desktop. The DAZ Studio tools will appear in Claude's tool palette.
Cursor
Add to .cursor/mcp.json in your project, or ~/.cursor/mcp.json for global access:
{
"mcpServers": {
"vangard-daz-mcp": {
"command": "uv",
"args": [
"run",
"--project",
"/absolute/path/to/daz-mcp-server",
"vangard-daz-mcp"
],
"env": {
"DAZ_HOST": "localhost",
"DAZ_PORT": "18811"
}
}
}
}VS Code (GitHub Copilot / MCP extension)
Add to .vscode/mcp.json in your workspace:
{
"servers": {
"vangard-daz-mcp": {
"type": "stdio",
"command": "uv",
"args": [
"run",
"--project",
"/absolute/path/to/daz-mcp-server",
"vangard-daz-mcp"
],
"env": {
"DAZ_HOST": "localhost",
"DAZ_PORT": "18811"
}
}
}
}Verifying the connection
After configuration, ask your MCP client:
Check if DAZ Studio is runningClaude will call daz_status. A successful response looks like:
{ "running": true, "version": "1.3.0" }If it fails, see the Troubleshooting section below.
Domain Reference Files (SKILL files)
The repository ships six SKILL files — curated knowledge documents that you can ask Claude (or any MCP client) to read before working in a particular area of DAZ Studio. They exist because LLMs have reasonable general knowledge about 3D software but will make confident, wrong assumptions about DAZ Studio specifics — inverted rotation signs, broken API methods, generation-specific bone names, and so on. Loading the right SKILL file before a task corrects those assumptions and produces dramatically better results.
How to use them
Ask Claude to read the relevant file at the start of a session or task:
Read the file SKILL_DAZ_STUDIO.md before we begin.Before writing any DazScript code, read SKILL_DAZSCRIPT.md.You can load more than one if your task spans domains:
Read SKILL_DAZ_STUDIO.md and SKILL_CINEMA.md — we're going to set up a portrait shot.SKILL file reference
File | Domain | Load when… |
DAZ Studio conventions | Starting any session — covers coordinate system inversions, camera Y-rotation being backwards, bone rotation limits, and known tool limitations | |
DazScript API | Writing or debugging custom scripts via | |
Scene management | Working with scene hierarchy, content library, spatial layout, materials, or batch operations | |
Characters & posing | Working with morphs, emotions, body language, gaze direction, wardrobe, or multi-character interactions | |
Cameras, lighting & rendering | Composing shots, setting up lighting rigs, animating cameras, or running renders | |
MCP server internals | Modifying or extending the MCP server itself — module layout, how to add tools, the script registry |
When to load SKILL_DAZ_STUDIO.md
This is the most important file and the one most likely to save you from a frustrating session. Key things it corrects:
Camera Y rotation is inverted — positive values turn the camera left, not right. Every other 3D application does this the other way.
daz_look_at_pointapplies rotations in the wrong direction — always verify in the viewport and correct manually.daz_orbit_camera_aroundaims at the figure's root (feet), not the face — use explicit world-space coordinates for portrait work instead.Genesis 9 faces +Z by default — "in front of" a character is at a positive Z coordinate.
Focal distance requires true 3D distance — using Z distance alone throws portrait shots out of focus.
Available Tools
📚 Documentation Tools
daz_script_help
Get DazScript documentation, examples, and best practices.
Arguments:
topic(string, default"overview"): Documentation topic to retrieve
Available Topics:
overview- DazScript environment basicsgotchas- Critical mistakes that cause timeouts or errorscamera- Camera creation, positioning, and aiminglight- Light creation, types, and three-point lightingenvironment- Iray environment settings and lighting modesscene- Scene management (new, save, load, selection)properties- Node properties, transforms, and morphscontent- Browsing and loading content from librarycoordinates- Coordinate system and positioning referenceposing- Figure posing, bone hierarchy, morphs vs poses, rotation gotchasmorphs- Morph discovery, searching, value ranges, and managementhierarchy- Scene hierarchy, parent-child relationships, parenting operationsinteraction- Multi-character interaction, look-at mechanics, world-space posingbatch- Batch operations patterns and performance optimizationviewport- Viewport and camera control, spherical positioning, presetsanimation- Keyframe animation, timeline control, image sequence exportrendering- Rendering workflows, multi-camera, batch render, animation export
Returns: Formatted documentation with examples
Use when: Before writing custom DazScript code to learn correct patterns and avoid common mistakes.
Example:
daz_script_help("camera") # Get camera documentation
daz_script_help("gotchas") # Learn critical gotchas🔍 Inspection Tools
daz_status
Check DAZ Studio connectivity and version.
Returns:
{
"running": true,
"version": "1.3.0"
}Use when: Verifying DAZ Studio is running and the connection works.
daz_scene_info
Get a snapshot of the current scene.
Returns:
{
"sceneFile": "/path/to/scene.duf",
"selectedNode": "Genesis 9",
"figures": [
{"name": "Genesis9", "label": "Genesis 9", "type": "DzFigure"}
],
"cameras": [
{"name": "Camera", "label": "Camera 1"}
],
"lights": [
{"name": "DistantLight", "label": "Distant Light", "type": "DzDistantLight"}
],
"totalNodes": 3247
}Use when: You need an overview of what's in the scene (characters, cameras, lights).
Note: Does not enumerate all nodes (scenes can have 1000+ nodes). Use daz_execute for fine-grained queries.
daz_get_node
Read all numeric properties of a node by its label or internal name.
Arguments:
node_label(string): Display label or internal name (e.g., "Genesis 9")
Returns:
{
"name": "Genesis9",
"label": "Genesis 9",
"type": "DzFigure",
"properties": {
"X Translate": 0.0,
"Y Translate": 0.0,
"Z Translate": 0.0,
"X Rotate": 0.0,
"Y Rotate": 0.0,
"Z Rotate": 0.0,
"Scale": 100.0,
"Head Size": 0.5
}
}Use when: You need to read transforms, morphs, or other numeric properties on a node.
daz_get_selected_nodes
Return the nodes currently selected in the DAZ Studio viewport.
Returns:
{
"count": 2,
"nodes": [
{"label": "Genesis 9", "name": "Genesis9"},
{"label": "Camera 1", "name": "Camera"}
]
}Use when: The user has manually selected items in DAZ Studio and wants the AI to act on that selection.
🔬 Morph Discovery Tools
daz_list_morphs
List all morphs (numeric properties) on a node with their current values.
Arguments:
node_label(string): Node display label or internal nameinclude_zero(bool, defaultFalse): Include morphs with zero values
Returns:
{
"morphs": [
{"label": "Height", "name": "Height", "value": 1.05, "path": "Morphs/Body"},
{"label": "Head Size", "name": "HeadSize", "value": 0.9, "path": "Morphs/Head"}
],
"count": 2,
"nodeLabel": "Genesis 9"
}Use when:
Discovering what morphs are available on a figure
Checking which morphs are currently active
Building morph selection UIs
Exploring character customization options
Example:
# List only active morphs (non-zero values)
daz_list_morphs("Genesis 9", include_zero=False)
# List ALL available morphs (warning: may return 500-1000+ morphs)
daz_list_morphs("Genesis 9", include_zero=True)Note: Genesis figures can have 1000+ morphs. Use include_zero=False to see only active morphs, or use daz_search_morphs to filter by pattern.
daz_search_morphs
Search for morphs matching a name pattern.
Arguments:
node_label(string): Node display label or internal namepattern(string): Substring to search for (case-insensitive)include_zero(bool, defaultFalse): Include morphs with zero values
Returns:
{
"morphs": [
{"label": "Smile", "name": "Smile", "value": 0.0, "path": "Morphs/Expressions"},
{"label": "Smile Open", "name": "SmileOpen", "value": 0.0, "path": "Morphs/Expressions"}
],
"count": 2,
"pattern": "smile",
"nodeLabel": "Genesis 9"
}Use when:
Finding specific morphs (e.g., all smile morphs, head morphs)
Discovering morphs by category or body part
Building filtered morph lists
Example:
# Find all smile-related morphs
daz_search_morphs("Genesis 9", "smile", include_zero=True)
# Find active head morphs only
daz_search_morphs("Genesis 9", "head", include_zero=False)
# Find all facial expression morphs
daz_search_morphs("Genesis 9", "express", include_zero=True)Common search patterns:
"smile","frown","express"- Facial expressions"head","face","nose"- Facial features"arm","leg","body"- Body parts"muscle","tone","fit"- Body definition"height","scale"- Size adjustments
🌳 Scene Hierarchy Tools
daz_get_node_hierarchy
Get complete hierarchy tree for a node with all descendants.
Arguments:
node_label(string): Root node display label or internal namemax_depth(int, default10): Maximum recursion depth (0 = unlimited)
Returns:
{
"node": "Genesis 9",
"hierarchy": {
"label": "Genesis 9",
"name": "Genesis9",
"type": "DzFigure",
"children": [
{
"label": "hip",
"name": "hip",
"type": "DzBone",
"children": [...]
}
]
},
"totalDescendants": 127
}Use when:
Understanding skeleton structure
Exploring bone relationships
Mapping complex scene hierarchies
Finding all descendants of a node
Example:
# Get skeleton hierarchy with depth limit
daz_get_node_hierarchy("Genesis 9", max_depth=3)
# Get full hierarchy (warning: Genesis 9 has 100+ bones)
daz_get_node_hierarchy("Genesis 9", max_depth=0)daz_list_children
List direct children of a node.
Arguments:
node_label(string): Parent node display label or internal name
Returns:
{
"node": "hip",
"children": [
{"label": "pelvis", "name": "pelvis", "type": "DzBone"},
{"label": "lThighBend", "name": "lThighBend", "type": "DzBone"},
{"label": "rThighBend", "name": "rThighBend", "type": "DzBone"}
],
"count": 3
}Use when:
Exploring hierarchy one level at a time
Checking if a node has children
Building custom tree structures
Example:
# List children of Genesis 9 root
daz_list_children("Genesis 9")
# Check if node has children
result = daz_list_children("Camera 1")
if result["count"] == 0:
print("No children")daz_get_parent
Get parent node of a node.
Arguments:
node_label(string): Child node display label or internal name
Returns:
{
"node": "lHand",
"parent": {
"label": "lForearmBend",
"name": "lForearmBend",
"type": "DzBone"
}
}Returns null for parent if node is a root (no parent).
Use when:
Traversing hierarchy upward
Finding what contains a node
Checking if node is a root
Example:
# Get parent of a bone
result = daz_get_parent("lHand")
print(f"Parent: {result['parent']['label']}")
# Check if node is root
result = daz_get_parent("Genesis 9")
if result["parent"] is None:
print("This is a root node")daz_set_parent
Set parent of a node (parenting operation).
Arguments:
node_label(string): Node to parentparent_label(string): New parent nodemaintain_world_transform(bool, defaultTrue): If true, adjust local transform to keep same world position
Returns:
{
"success": true,
"node": "Sword",
"newParent": "rHand",
"previousParent": null
}Use when:
Attaching props to figures (e.g., weapon to hand)
Parenting cameras to nodes
Reorganizing scene hierarchy
Attaching clothing to bones
Example:
# Attach sword to right hand (maintains position)
daz_set_parent("Sword", "rHand", maintain_world_transform=True)
# Parent camera to figure (follows figure)
daz_set_parent("Camera 1", "Genesis 9", maintain_world_transform=True)
# Attach bracelet to forearm
daz_set_parent("Bracelet", "lForearmBend", maintain_world_transform=True)Note: When maintain_world_transform=True, the node's world position stays the same, but local transform values (X/Y/Z Translate, Rotate) change to account for the new parent's transform.
⚡ Batch Operations
Batch operations allow you to modify multiple nodes or properties in a single call, significantly improving performance. Each operation has individual error handling, so failures don't abort the entire batch.
Performance benefits:
Single script call (all operations execute in one round-trip)
No HTTP/network overhead between operations
5-10x faster than individual calls for typical batches
Individual error handling without aborting the batch
Common use cases:
Applying facial expressions (multiple morphs at once)
Configuring lighting setups (multiple light properties)
Moving/rotating groups of props together
Showing/hiding groups of nodes for scene management
Resetting multiple cameras or lights to default values
daz_batch_set_properties
Set multiple properties on one or more nodes in a single call.
Arguments:
operations(array): List of operation objects, each containing:nodeLabel(string): Display label of the nodepropertyName(string): Property label or internal namevalue(float): New value for the property
Returns:
{
"results": [
{"success": true, "node": "Genesis 9", "property": "X Translate", "value": 100},
{"success": false, "node": "Missing", "error": "Node not found: Missing"}
],
"successCount": 1,
"failureCount": 1,
"total": 2
}Use when: Setting 3+ properties, applying facial expressions, configuring scene presets.
Example:
# Apply "surprised" facial expression
daz_batch_set_properties([
{"nodeLabel": "Genesis 9", "propertyName": "PHMEyesWide", "value": 0.8},
{"nodeLabel": "Genesis 9", "propertyName": "PHMBrowsUp", "value": 0.7},
{"nodeLabel": "Genesis 9", "propertyName": "PHMMouthOpen", "value": 0.4}
])
# Configure lighting setup
daz_batch_set_properties([
{"nodeLabel": "Key Light", "propertyName": "Flux", "value": 2000},
{"nodeLabel": "Fill Light", "propertyName": "Flux", "value": 800},
{"nodeLabel": "Rim Light", "propertyName": "Flux", "value": 2500}
])Performance: Setting 10 morphs via batch is ~5-10x faster than 10 individual daz_set_property calls.
daz_batch_transform
Apply the same transform properties to multiple nodes.
Arguments:
node_labels(array): List of node display labels to transformtransforms(object): Dictionary of property names to values (e.g.,{"XTranslate": 50, "YRotate": 45})
Returns:
{
"results": [
{"success": true, "node": "Prop1", "applied": ["X Translate", "Y Rotate"]},
{"success": false, "node": "Missing", "error": "Node not found: Missing"}
],
"successCount": 1,
"failureCount": 1,
"total": 2
}Use when: Moving, rotating, or scaling multiple objects by the same amount.
Example:
# Move multiple props to the right
daz_batch_transform(
["Chair", "Table", "Lamp"],
{"XTranslate": 100}
)
# Rotate and scale multiple objects
daz_batch_transform(
["Prop1", "Prop2", "Prop3"],
{"YRotate": 45, "Scale": 1.2}
)
# Reset rotation for all cameras
daz_batch_transform(
["Camera 1", "Camera 2", "Camera 3"],
{"XRotate": 0, "YRotate": 0, "ZRotate": 0}
)Note: Only properties that exist on each node are applied. Missing properties are silently skipped.
daz_batch_visibility
Show or hide multiple nodes in the viewport and renders.
Arguments:
node_labels(array): List of node display labels to modifyvisible(bool, defaultTrue): True to show nodes, False to hide them
Returns:
{
"results": [
{"success": true, "node": "Ground", "visible": false},
{"success": true, "node": "Sky Dome", "visible": false}
],
"successCount": 2,
"failureCount": 0,
"total": 2
}Use when: Scene management, testing configurations, optimizing render times.
Example:
# Hide all cameras
daz_batch_visibility(["Camera 1", "Camera 2", "Camera 3"], visible=False)
# Hide environment elements for character close-up
daz_batch_visibility(["Ground", "Sky Dome", "Background"], visible=False)
# Show all weapons
daz_batch_visibility(["Sword", "Shield", "Helmet"], visible=True)Note: Hidden nodes remain in the scene but are not visible in viewport or renders.
daz_batch_select
Select multiple nodes in the DAZ Studio scene.
Arguments:
node_labels(array): List of node display labels to selectadd_to_selection(bool, defaultFalse): If True, add to current selection; if False, replace current selection
Returns:
{
"selected": ["Genesis 9", "Genesis 8 Female"],
"count": 2,
"total": 2
}Use when: Selecting groups of nodes for inspection or operations.
Example:
# Select multiple characters
daz_batch_select(["Genesis 9", "Genesis 8 Female"])
# Add props to current selection
daz_batch_select(["Sword", "Shield"], add_to_selection=True)
# Select all lights
daz_batch_select(["Spot Light 1", "Distant Light 1", "Point Light 1"])Note: Nodes that don't exist are silently skipped. Returns count of successful selections.
📷 Viewport and Camera Control
Viewport control tools enable programmatic camera positioning, framing, and preset management for automated scene photography and consistent camera angles.
Key capabilities:
Switch active viewport camera
Position camera using spherical coordinates (orbit around target)
Auto-frame camera to show objects (calculates bounding box)
Save/load camera positions as presets (JSON-serializable)
Reusable camera angles across scenes
daz_set_active_camera
Set which camera is active in the DAZ Studio viewport.
Arguments:
camera_label(string): Display label of the camera to activate
Returns:
{
"success": true,
"camera": "Camera 1",
"previousCamera": "Perspective View"
}Use when: Switching between predefined camera angles, previewing from multiple viewpoints.
Example:
# Switch to specific camera
daz_set_active_camera("Camera 1")
# Switch back to default
daz_set_active_camera("Perspective View")daz_orbit_camera_around
Position camera orbiting around a target node at specified angle and distance.
Arguments:
camera_label(string): Camera to positiontarget_label(string): Target node to orbit arounddistance(float, default200.0): Distance from target in cmangle_horizontal(float, default45.0): Horizontal angle in degrees (0=front/+Z, 90=right/+X)angle_vertical(float, default15.0): Vertical angle in degrees (positive=above)
Returns:
{
"success": true,
"camera": "Camera 1",
"target": "Genesis 9",
"position": {"x": 141.4, "y": 151.8, "z": 141.4},
"targetPosition": {"x": 0, "y": 100, "z": 0}
}Use when: Character photography, product shots, turntable animations, establishing camera angles.
Example:
# Front 3/4 view (classic portrait angle)
daz_orbit_camera_around("Camera 1", "Genesis 9",
distance=200, angle_horizontal=45, angle_vertical=15)
# Side view from left
daz_orbit_camera_around("Camera 1", "Genesis 9",
distance=150, angle_horizontal=-90, angle_vertical=0)
# Bird's eye view
daz_orbit_camera_around("Camera 1", "Genesis 9",
distance=300, angle_horizontal=0, angle_vertical=60)
# Dramatic low angle
daz_orbit_camera_around("Camera 1", "Genesis 9",
distance=180, angle_horizontal=25, angle_vertical=-20)Angle reference:
Horizontal: 0°=front(+Z), 90°=right(+X), 180°=back(-Z), -90°=left(-X)
Vertical: positive=above horizon, negative=below
Distance guidelines (170cm tall figure):
Full body: 350-450cm
Portrait: 80-120cm
Face close-up: 30-50cm
daz_frame_camera_to_node
Frame camera to show a node by positioning at calculated distance.
Arguments:
camera_label(string): Camera to positionnode_label(string): Node to framedistance(float, optional): Distance from node center in cm. If not specified, auto-calculated as 2.5x largest bounding box dimension.
Returns:
{
"success": true,
"camera": "Camera 1",
"node": "Genesis 9",
"position": {"x": 0, "y": 100, "z": 450},
"nodeCenter": {"x": 0, "y": 100, "z": 0},
"nodeSize": {"x": 50, "y": 170, "z": 40}
}Use when: Auto-framing objects of varying sizes, consistent framing across scenes.
Example:
# Frame character (auto distance)
daz_frame_camera_to_node("Camera 1", "Genesis 9")
# Frame prop with specific distance
daz_frame_camera_to_node("Camera 1", "Sword", distance=50)
# Close-up on head
daz_frame_camera_to_node("Camera 1", "head", distance=30)Note: Camera is positioned in front (+Z) and aimed at node's bounding box center. Auto-calculated distance is 2.5x the largest dimension.
daz_save_camera_preset
Save camera position and rotation as preset data.
Arguments:
camera_label(string): Camera to save
Returns:
{
"preset": {
"label": "Camera 1",
"transforms": {
"XTranslate": 0, "YTranslate": 100, "ZTranslate": 300,
"XRotate": -10, "YRotate": 0, "ZRotate": 0,
"XScale": 1.0, "YScale": 1.0, "ZScale": 1.0
}
}
}Use when: Saving reusable camera angles, sharing camera positions across projects.
Example:
# Save camera position
preset = daz_save_camera_preset("Camera 1")
# Store to file
import json
with open("portrait_camera.json", "w") as f:
json.dump(preset, f)Note: Preset data is JSON-serializable and can be applied to any camera.
daz_load_camera_preset
Restore camera position and rotation from preset data.
Arguments:
camera_label(string): Camera to modifypreset(dict): Preset dictionary fromdaz_save_camera_preset()(must containtransformskey)
Returns:
{
"success": true,
"camera": "Camera 1",
"applied": ["XTranslate", "YTranslate", "ZTranslate", "XRotate", "YRotate", "ZRotate"]
}Use when: Restoring saved camera positions, applying same angle to multiple cameras.
Example:
# Load preset from file
import json
with open("portrait_camera.json") as f:
preset = json.load(f)
# Apply to camera
daz_load_camera_preset("Camera 1", preset["preset"])
# Apply same preset to multiple cameras
for cam in ["Camera 1", "Camera 2", "Camera 3"]:
daz_load_camera_preset(cam, preset["preset"])Note: Preset can be applied to any camera, not just the original. Useful for synchronizing multiple cameras.
daz_list_cameras
List all cameras currently in the scene.
Returns:
{
"camera_count": 2,
"cameras": [
{"name": "Camera", "label": "Camera 1", "focal_length": 65.0},
{"name": "Camera2", "label": "Wide Shot", "focal_length": 35.0}
]
}Use when: Discovering what cameras exist before calling daz_set_active_camera or daz_render_with_camera.
daz_create_camera
Create a new camera and add it to the scene.
Arguments:
label(string): Display name for the new camerax,y,z(float): World-space position in cm (defaults: 0, 150, 300)aim_at_label(string, optional): Aim the camera at this node's centrefocal_length(float, optional): Lens focal length in mm
Returns:
{
"label": "Close-up Cam",
"position": {"x": 0, "y": 160, "z": 120},
"focal_length": 85.0
}Example:
daz_create_camera("Close-up Cam", x=0, y=160, z=120,
aim_at_label="Genesis 9", focal_length=85)Note: Use daz_list_cameras to confirm the camera was added, and daz_set_active_camera to switch the active viewport.
🎬 Animation System
Animation tools enable keyframe-based property animation. Set keyframes at specific frames, and DAZ Studio interpolates smoothly between them. Supports animating any numeric property (transforms, morphs, lights, cameras).
Key capabilities:
Set/get/remove keyframes on properties
Timeline control (current frame, frame range)
Export animations as image sequences
Copy and offset animations between properties
Inspect keyframe data programmatically
Common use cases:
Character animation (walk cycles, gestures, facial expressions)
Camera animation (dolly, pan, zoom)
Product turntables (360° rotation)
Morph animations (smile fade, eye blink)
Multi-character choreography
daz_set_keyframe
Set a keyframe on a property at specified frame.
Arguments:
node_label(string): Node display labelproperty_name(string): Property label or internal nameframe(int): Frame number (0-based)value(float): Value at this frame
Returns:
{
"success": true,
"node": "Genesis 9",
"property": "X Translate",
"frame": 0,
"value": 0.0
}Use when: Creating animations, defining key poses.
Example:
# Animate movement (0 to 100cm over 30 frames)
daz_set_keyframe("Genesis 9", "XTranslate", frame=0, value=0)
daz_set_keyframe("Genesis 9", "XTranslate", frame=30, value=100)
# Animate rotation (0 to 90 degrees)
daz_set_keyframe("Genesis 9", "YRotate", frame=0, value=0)
daz_set_keyframe("Genesis 9", "YRotate", frame=60, value=90)
# Animate morph (fade in smile)
daz_set_keyframe("Genesis 9", "PHMSmile", frame=0, value=0)
daz_set_keyframe("Genesis 9", "PHMSmile", frame=15, value=0.8)Note: DAZ Studio interpolates between keyframes automatically. Setting keyframe at existing frame updates the value.
daz_get_keyframes
Get all keyframes for a property.
Arguments:
node_label(string): Node display labelproperty_name(string): Property label or internal name
Returns:
{
"keyframes": [
{"frame": 0, "value": 0.0},
{"frame": 30, "value": 100.0}
],
"count": 2
}Use when: Inspecting animations, copying keyframes, checking if property is animated.
Example:
# Get keyframes
result = daz_get_keyframes("Genesis 9", "XTranslate")
for kf in result['keyframes']:
print(f"Frame {kf['frame']}: {kf['value']}")
# Copy keyframes to another node
for kf in result['keyframes']:
daz_set_keyframe("Genesis 8", "XTranslate", kf['frame'], kf['value'])daz_remove_keyframe
Remove a keyframe at specified frame.
Arguments:
node_label(string): Node display labelproperty_name(string): Property label or internal nameframe(int): Frame number
Returns:
{
"success": true,
"node": "Genesis 9",
"property": "X Translate",
"frame": 15,
"removed": true
}Use when: Removing specific keyframes, editing animation timing.
Example:
# Remove keyframe
daz_remove_keyframe("Genesis 9", "XTranslate", frame=15)Note: Returns removed: false if no keyframe exists at that frame (not an error).
daz_clear_animation
Remove all keyframes from a property.
Arguments:
node_label(string): Node display labelproperty_name(string): Property label or internal name
Returns:
{
"success": true,
"node": "Genesis 9",
"property": "X Translate",
"removed": 5
}Use when: Clearing animations, resetting properties to static state.
Example:
# Clear animation
result = daz_clear_animation("Genesis 9", "XTranslate")
print(f"Removed {result['removed']} keyframes")
# Clear all transform animations
for prop in ["XTranslate", "YTranslate", "ZTranslate", "XRotate", "YRotate", "ZRotate"]:
daz_clear_animation("Genesis 9", prop)Note: More efficient than removing keyframes individually.
daz_set_frame
Set current animation frame.
Arguments:
frame(int): Frame number to move to
Returns:
{
"success": true,
"frame": 30,
"previousFrame": 0
}Use when: Previewing animation, rendering specific frames.
Example:
# Jump to frame 30
daz_set_frame(30)
# Render all frames
info = daz_get_animation_info()
for frame in range(info['startFrame'], info['endFrame'] + 1):
daz_set_frame(frame)
daz_render(output_path=f"frame_{frame:04d}.png")Note: Scene updates to show animated state at the frame.
daz_set_frame_range
Set animation frame range (start and end).
Arguments:
start_frame(int): First frame (typically 0)end_frame(int): Last frame
Returns:
{
"success": true,
"startFrame": 0,
"endFrame": 119,
"previousStart": 0,
"previousEnd": 30
}Use when: Defining animation length before creating keyframes.
Example:
# 4-second animation (120 frames at 30fps)
daz_set_frame_range(0, 119)
# 10-second animation
daz_set_frame_range(0, 299)Note: Frame range is inclusive (frames 0-119 = 120 frames). Duration = (end - start + 1) / fps.
daz_get_animation_info
Get animation timeline info (current frame, range, fps).
Returns:
{
"currentFrame": 0,
"startFrame": 0,
"endFrame": 119,
"fps": 30.0,
"totalFrames": 120,
"durationSeconds": 4.0
}Use when: Checking timeline state before rendering, calculating duration.
Example:
# Get timeline info
info = daz_get_animation_info()
print(f"Animation: {info['durationSeconds']} seconds ({info['totalFrames']} frames)")
# Render entire animation
for frame in range(info['startFrame'], info['endFrame'] + 1):
daz_set_frame(frame)
daz_render(output_path=f"frame_{frame:04d}.png")Note: FPS is typically 30 in DAZ Studio.
🎥 Advanced Rendering Control
Advanced rendering tools provide programmatic control for multi-camera rendering, animation export, and batch rendering operations.
Key capabilities:
Render from specific camera without changing viewport
Batch render from multiple cameras
Export animations as image sequences
Query render settings
Automated rendering workflows
Common use cases:
Multi-angle product shots (front, side, top, perspective)
Character turntables (8-16 camera angles)
Animation export (frame-by-frame image sequences)
Test renders from multiple angles
Multi-camera animation rendering
daz_render_with_camera
Render from specific camera without changing active viewport camera.
Arguments:
camera_label(string): Camera to render fromoutput_path(string, optional): Output file path (if not specified, renders to viewport)
Returns:
{
"success": true,
"camera": "Camera 1",
"outputPath": "/path/to/render.png"
}Use when: Multi-camera batch renders, testing camera angles without disrupting viewport.
Example:
# Render from specific camera
daz_render_with_camera("Camera 1", output_path="/renders/cam1.png")
# Render from multiple cameras
for cam in ["Front", "Side", "Top"]:
daz_render_with_camera(cam, output_path=f"/renders/{cam}.png")Note: Viewport camera remains unchanged. Previous render camera is restored automatically.
daz_get_render_settings
Get current render settings and configuration.
Returns:
{
"renderToFile": true,
"outputPath": "/path/to/output.png",
"currentCamera": "Camera 1",
"aspectRatio": 1.777,
"aspectWidth": 16,
"aspectHeight": 9
}Use when: Verifying render configuration before batch operations, debugging render issues.
Example:
# Check render settings
settings = daz_get_render_settings()
print(f"Render camera: {settings['currentCamera']}")
print(f"Aspect: {settings['aspectWidth']}x{settings['aspectHeight']}")
# Verify configuration
if not settings['renderToFile']:
print("Warning: Render configured for viewport, not file")daz_batch_render_cameras
Render from multiple cameras in sequence.
Arguments:
cameras(list[string]): List of camera labelsoutput_dir(string): Output directorybase_filename(string, default"render"): Base filename (camera name is appended)
Returns:
{
"success": true,
"rendered": [
{"camera": "Front", "outputPath": "/renders/product_Front.png"},
{"camera": "Side", "outputPath": "/renders/product_Side.png"}
],
"total": 2
}Use when: Product photography, turntable renders, multi-angle test renders.
Example:
# Render from multiple cameras
daz_batch_render_cameras(
cameras=["Front", "Side", "Top", "Perspective"],
output_dir="/renders",
base_filename="product"
)
# Generates: product_Front.png, product_Side.png, product_Top.png, product_Perspective.png
# Turntable (8 cameras around character)
cameras = [f"Cam_{angle}" for angle in [0, 45, 90, 135, 180, 225, 270, 315]]
daz_batch_render_cameras(cameras, "/renders/turntable", "angle")Note: Camera names in filenames have non-alphanumeric chars replaced with underscores. Previous render camera is restored after batch.
daz_render_animation
Render animation frame range as image sequence.
Arguments:
output_dir(string): Output directorystart_frame(int, optional): First frame (default: animation range start)end_frame(int, optional): Last frame (default: animation range end)filename_pattern(string, default"frame"): Filename pattern (frame number appended)camera(string, optional): Camera to render from (default: current render camera)
Returns:
{
"success": true,
"rendered": [
{"frame": 0, "outputPath": "/animation/frame_0000.png"},
{"frame": 1, "outputPath": "/animation/frame_0001.png"}
],
"total": 120,
"frames": {"start": 0, "end": 119}
}Use when: Exporting animations, creating video sequences.
Example:
# Render entire animation (uses animation range)
daz_render_animation(output_dir="/animation")
# Generates: frame_0000.png, frame_0001.png, ..., frame_0119.png
# Render specific frame range
daz_render_animation(
output_dir="/animation/clip",
start_frame=30,
end_frame=60,
filename_pattern="clip"
)
# Render animation from specific camera
daz_render_animation(
output_dir="/animation",
camera="Camera 1"
)
# Convert to video (using ffmpeg)
# ffmpeg -framerate 30 -i frame_%04d.png -c:v libx264 -pix_fmt yuv420p output.mp4Note: Frame numbers zero-padded to 4 digits (0000-9999). Timeline position and render camera restored after completion.
📐 Spatial Query Tools
These tools let you query the world-space position, size, and relationships of scene nodes.
daz_get_world_position
Get world-space position, local position, rotation, and scale of a node.
Arguments:
node_label(string): Node display label or internal name
Returns:
{
"node": "Genesis 9",
"worldPosition": {"x": 0, "y": 0, "z": 0},
"localPosition": {"x": 0, "y": 0, "z": 0},
"rotation": {"x": 0, "y": 0, "z": 0},
"scale": {"x": 1, "y": 1, "z": 1}
}Use when: Finding exact world coordinates of a character or prop before placing another object relative to it.
daz_get_bounding_box
Get bounding box (min/max corners, center, dimensions) of a node.
Arguments:
node_label(string): Node display label or internal name
Returns:
{
"node": "Genesis 9",
"min": {"x": -30, "y": 0, "z": -15},
"max": {"x": 30, "y": 170, "z": 15},
"center": {"x": 0, "y": 85, "z": 0},
"width": 60, "height": 170, "depth": 30
}Use when: Auto-framing cameras, checking object sizes, placing objects on surfaces.
daz_calculate_distance
Calculate distance and direction vector between two nodes.
Arguments:
from_label(string): Source nodeto_label(string): Target node
Returns:
{
"from": "Alice",
"to": "Bob",
"distance": 120.5,
"direction": {"x": 0.707, "y": 0, "z": 0.707}
}Use when: Checking if two characters are within interaction range, positioning props relative to figures.
daz_get_spatial_relationship
Natural-language spatial relationship between two nodes.
Arguments:
from_label(string): Reference nodeto_label(string): Target node
Returns:
{
"from": "Camera 1",
"to": "Genesis 9",
"distance": 300.0,
"direction": "in front of",
"angle": 5.2,
"overlap": false
}Use when: Describing scene layout in natural language, verifying camera placement.
daz_check_overlap
Check if two nodes have overlapping bounding boxes.
Arguments:
node1_label(string): First nodenode2_label(string): Second node
Returns:
{
"overlapping": true,
"penetrationDepth": {"x": 2.1, "y": 0, "z": 0}
}Use when: Detecting interpenetration between characters, validating poses before rendering.
🔬 Property Introspection Tools
daz_inspect_properties
List all properties on a node, optionally filtered by type.
Arguments:
node_label(string): Node display label or internal namefilter_type(string, default"all"): One of"all","numeric","transform","morph","bool","string"
Returns:
{
"node": "Spot Light 1",
"properties": [
{"label": "Flux", "name": "Flux", "type": "numeric", "value": 1500},
{"label": "Shadow Softness", "name": "Shadow Softness", "type": "numeric", "value": 0.5}
],
"count": 2
}Use when: Discovering what properties are settable on a node (lights, cameras, props).
Example:
# List all numeric properties on a spotlight
daz_inspect_properties("Spot Light 1", filter_type="numeric")
# List transform properties only
daz_inspect_properties("Genesis 9", filter_type="transform")daz_get_property_metadata
Get detailed metadata (min, max, default, type, path) for a single property.
Arguments:
node_label(string): Node display label or internal nameproperty_name(string): Property label or internal name
Returns:
{
"node": "Spot Light 1",
"property": "Flux",
"type": "numeric",
"value": 1500,
"default": 1500,
"min": 0,
"max": 100000,
"path": "General/Luminous Flux"
}Use when: Finding valid ranges before setting a property, validating property names.
daz_validate_script
Static analysis of DazScript code for known anti-patterns. Does not require a DAZ Studio connection.
Arguments:
script(string): DazScript source code to analyze
Returns:
{
"valid": false,
"issues": [
{"severity": "error", "line": 3, "message": "Bare return at top level — wrap in IIFE"},
{"severity": "warning", "line": 7, "message": "getElementID() is not a function — use .elementID property"}
],
"issueCount": 2
}Use when: Before running a custom script via daz_execute, to catch common mistakes early.
💡 Lighting Preset Tools
daz_apply_lighting_preset
Create a professional lighting setup in one command.
Arguments:
preset(string): Lighting preset namesubject_label(string): Node to light (preset positions lights relative to subject's bounding box)
Presets:
three-point— Key (front-right) + Fill (front-left) + Rim (back). General-purpose.rembrandt— Key (45° side, high) + dim Fill. Dramatic portrait.butterfly— Key (directly front, high). Glamour/beauty lighting.split— Key (90° side). Half face lit, half in shadow. Moody.loop— Key (35° side) + Fill + Rim. Natural-looking portrait.
Returns:
{
"success": true,
"preset": "three-point",
"subject": "Genesis 9",
"lights": ["Key Light", "Fill Light", "Rim Light"]
}All presets: aim lights at the subject's face height, set environment mode to Scene Only, and remove existing lights with the same names first.
Use when: Setting up a scene for rendering without manually positioning individual lights.
Example:
# Classic portrait lighting
daz_apply_lighting_preset("three-point", "Genesis 9")
# Dramatic moody lighting
daz_apply_lighting_preset("rembrandt", "Genesis 9")daz_validate_scene
Validate scene quality for rendering — checks lighting, cameras, collisions.
Returns:
{
"score": 75,
"issues": [
{"category": "lighting", "severity": "medium", "message": "Only one light source — consider adding fill or rim light"},
{"category": "collision", "severity": "high", "message": "Alice and Bob bounding boxes overlap by 5cm"}
],
"breakdown": {
"lighting": 60,
"cameras": 100,
"figures": 100,
"collisions": 50
}
}Score: 0-100. Issues reduce the score. Checks: bounding box collisions between figures, insufficient lighting, no cameras, no figures.
Use when: Before rendering to catch common setup problems.
daz_list_lights
List all lights currently in the scene.
Returns:
{
"light_count": 3,
"lights": [
{"name": "SpotLight", "label": "Key Light", "intensity": 10000, "shadow_type": "Raytraced"},
{"name": "DistantLight", "label": "Sun", "intensity": 5000, "shadow_type": "None"}
]
}Use when: Checking what lights exist before modifying or deleting them.
daz_create_light
Create a new light and add it to the scene.
Arguments:
light_type(string):"spot","distant", or"point"label(string): Display name for the new lightx,y,z(float): World-space position in cm (defaults: 0, 200, 200)flux(float, optional): Light intensity in DAZ flux unitsaim_at_label(string, optional): Aim the light at this node's centre
Returns:
{
"label": "Key Light",
"type": "spot",
"position": {"x": 150, "y": 250, "z": 200},
"flux": 10000
}Example:
daz_create_light("spot", "Key Light", x=150, y=250, z=200,
flux=10000, aim_at_label="Genesis 9")Note: For complete multi-light setups use daz_apply_lighting_preset or daz_apply_visual_style instead.
daz_set_scene_atmosphere
Configure the DAZ Studio environment node (HDRI dome, Sun-Sky, ambient lighting).
Arguments:
environment_mode(int, optional):0=Sun-Sky Only,1=Dome Only,2=Sun-Sky+Dome,3=Scene Only (use3when relying on scene lights)environment_intensity(float, optional): Brightness of dome/sun-sky (0.0–10.0)draw_dome(bool, optional): Whether the HDRI image is visible as the backgrounddome_rotation(float, optional): Horizontal rotation of HDRI dome in degrees (0–360)sun_light_intensity(float, optional): Sun component brightness in modes 0 or 2
Returns:
{
"changesApplied": ["environment_mode → 3"],
"changeCount": 1,
"currentEnvironmentMode": 3
}Example:
# Required before using lighting presets so dome doesn't wash out scene lights
daz_set_scene_atmosphere(environment_mode=3)
# Dimmed HDRI dome blended with scene lights
daz_set_scene_atmosphere(environment_mode=1, environment_intensity=0.2, draw_dome=True)daz_apply_visual_style
Apply a holistic cinematic visual style — creates/reconfigures three named lights (Style_Key, Style_Fill, Style_Rim) with ratios and angles tuned for the chosen look. Sets environment to Scene Only mode automatically.
Arguments:
style_name(string): One of"cinematic","noir","golden-hour","blue-hour","high-key","low-key","documentary","fantasy"subject_label(string, optional): Node to aim lights atintensity(float, default1.0): Scale factor for all light flux (0.1–5.0)
Returns:
{
"styleName": "cinematic",
"lights": [
{"role": "key", "label": "Style_Key", "flux": 12000, "angle": 45},
{"role": "fill", "label": "Style_Fill", "flux": 3000, "angle": -45},
{"role": "rim", "label": "Style_Rim", "flux": 8000, "angle": 180}
],
"lightingRatios": {"keyToFill": 4.0, "keyToRim": 1.5}
}Example:
daz_apply_visual_style("cinematic", subject_label="Genesis 9")
daz_apply_visual_style("noir", subject_label="Alice", intensity=0.8)Note: Fine-tune individual lights afterward with daz_set_property("Style_Key", "Flux", 15000).
🎭 Emotional Direction
daz_set_emotion
Apply an emotional expression to a character (morphs + body language).
Arguments:
character_label(string): Character display labelemotion(string): Emotion nameintensity(float, default0.7): Strength of the expression (0.0–1.0)
Supported emotions: happy, sad, angry, surprised, fearful, disgusted, neutral, excited, bored, confident, shy, loving, contemptuous
Returns:
{
"success": true,
"character": "Genesis 9",
"emotion": "happy",
"intensity": 0.7,
"applied": ["PHMSmile", "PHMBrowsUp", "chest_forward"],
"notFound": ["PHMEyeSquintL"]
}Missing morphs (due to figure generation differences) are reported in not_found without raising an error.
Use when: Quickly applying a recognizable expression instead of manually searching for morph names.
Example:
# Apply full happy expression
daz_set_emotion("Alice", "happy")
# Subtle confident look
daz_set_emotion("Bob", "confident", intensity=0.4)📚 Content Library Navigation
daz_list_categories
List subdirectories in the content library under a parent path.
Arguments:
parent_path(string, default""): Path relative to content library root (e.g.,"People/Genesis 9")
Returns:
{
"path": "People/Genesis 9",
"categories": ["Characters", "Hair", "Clothing", "Expressions"],
"count": 4
}Use when: Browsing the content library to discover available categories.
Example:
# List top-level categories
daz_list_categories("")
# Browse Genesis 9 subcategories
daz_list_categories("People/Genesis 9")daz_browse_category
List .duf files in a content library category.
Arguments:
category_path(string): Path relative to content library rootsort_by(string, default"name"): Sort order:"name"or"date"
Returns:
{
"path": "People/Genesis 9/Hair",
"files": [
{"name": "Ade Hair", "path": "/Library/People/Genesis 9/Hair/Ade Hair.duf"},
{"name": "Braid Updo", "path": "/Library/People/Genesis 9/Hair/Braid Updo.duf"}
],
"count": 2
}Use when: Finding content file paths to load with daz_load_file.
daz_get_content_info
Read metadata from a .duf file without loading it.
Arguments:
file_path(string): Absolute path to.duffile
Returns:
{
"name": "Ade Hair",
"type": "wearable",
"requires": ["Genesis 9"],
"author": "Daz Originals",
"description": "Long flowing hair for Genesis 9"
}Use when: Checking compatibility or requirements before loading content.
daz_search_content
Search the content library by keyword.
Arguments:
query(string): Search querymax_results(int, default10): Maximum results to return
Returns: {"results": [{"name": "...", "path": "...", "type": "..."}], "count": N}
daz_load_product
Load a product from the DAZ content library by product name.
Arguments:
product_name(string): Product name to search for and load
Returns: {"success": true, "product": "...", "loaded": [...]}
🎬 Scene Composition / Cinematography
daz_apply_composition_rule
Position camera using a photography composition rule.
Arguments:
camera_label(string): Camera to positionsubject_label(string): Subject to compose aroundrule(string, default"rule-of-thirds"): Composition rule
Rules:
rule-of-thirds— Subject on right vertical third at eye levelgolden-ratio— Subject at 1.618 golden sectioncenter-frame— Subject centered, symmetricleading-lines— Low angle with diagonal offset
Returns:
{
"success": true,
"camera": "Camera 1",
"subject": "Genesis 9",
"rule": "rule-of-thirds"
}daz_frame_shot
Frame camera using a standard cinematic shot type.
Arguments:
camera_label(string): Camera to positionsubject_label(string): Subject to frameshot_type(string): Shot type name
Shot types and distances:
extreme-close-up— 25 cm (eyes/mouth detail)close-up— 50 cm (face)medium-close-up— 90 cm (head and shoulders)medium-shot— 140 cm (waist up)medium-full— 200 cm (knees up)full-shot— 400 cm (whole body)wide-shot— 700 cm (body + environment)
Returns:
{
"success": true,
"camera": "Camera 1",
"subject": "Genesis 9",
"shotType": "medium-shot",
"distance": 140
}Example:
# Frame a portrait shot
daz_frame_shot("Camera 1", "Genesis 9", "close-up")
# Frame full body
daz_frame_shot("Camera 1", "Genesis 9", "full-shot")daz_apply_camera_angle
Apply a standard camera angle preset relative to a subject.
Arguments:
camera_label(string): Camera to positionsubject_label(string): Subject to angle towardangle(string, default"eye-level"): Camera angle preset
Angles:
eye-level— Neutral, camera at subject's eye heighthigh-angle— Above subject, looking down (vulnerable)low-angle— Below eye level, looking up (powerful)dutch-angle— Eye level + 15° Z-roll (unsettling)overhead— Directly above (bird's-eye)worms-eye— Ground level looking upover-shoulder— Behind and to one side
Returns:
{
"success": true,
"camera": "Camera 1",
"subject": "Genesis 9",
"angle": "low-angle"
}💾 Scene Checkpoint System
daz_save_scene_state
Save current scene state (transforms, morphs, light properties) as a named checkpoint.
Arguments:
checkpoint_name(string): Name for this checkpoint
What is captured:
All figures/skeletons: transform properties + active (non-zero) morph values
All cameras: transform properties
All lights: transform properties + Flux, Shadow Softness, Spread Angle
What is NOT captured: Materials, geometry, HDR dome settings, parenting relationships.
Returns:
{
"success": true,
"checkpoint": "before_lighting_test",
"nodesCaptured": 5,
"savedAt": "2026-04-09T10:15:00"
}Important: Checkpoints are stored in MCP server process memory and are lost if the server restarts.
Example:
# Safe experimentation workflow
daz_save_scene_state("before_lighting_test")
daz_apply_lighting_preset("rembrandt", "Genesis 9")
# Don't like it?
daz_restore_scene_state("before_lighting_test")daz_restore_scene_state
Restore scene state from a named checkpoint.
Arguments:
checkpoint_name(string): Name of checkpoint to restore
Returns:
{
"success": true,
"checkpoint": "before_lighting_test",
"nodesRestored": 5
}daz_list_checkpoints
List all saved checkpoints in the current session.
Returns:
{
"checkpoints": [
{"name": "before_lighting_test", "savedAt": "2026-04-09T10:15:00", "nodeCount": 5},
{"name": "pose_v2", "savedAt": "2026-04-09T10:32:00", "nodeCount": 5}
],
"count": 2
}daz_export_node_config
Export scene node properties to a portable JSON file for reuse across scenes or after server restarts. Complements in-memory checkpoints with persistent, file-based storage.
Arguments:
output_path(string): Absolute path for the output.jsonfilenode_labels(list, optional): Specific node labels to capture; if omitted captures all skeletons, cameras, and lightsinclude_types(list, optional): Property categories to capture:"transforms","morphs","lights","cameras"(default: all)
Returns:
{
"outputPath": "C:/shots/hero_pose.json",
"nodeCount": 3,
"propertyCount": 18,
"morphCount": 5,
"fileSizeBytes": 4096
}Example:
# Export current pose and morphs for Genesis 9
daz_export_node_config(
"C:/poses/alice_surprised.json",
node_labels=["Alice"],
include_types=["transforms", "morphs"]
)
# Export a camera rig for reuse in other scenes
daz_export_node_config("C:/presets/interview_cameras.json",
node_labels=["Camera A", "Camera B"],
include_types=["transforms", "cameras"])daz_import_node_config
Apply a previously exported node config file to the current scene. Nodes are matched by exact label.
Arguments:
input_path(string): Absolute path to the.jsonconfig filenode_labels(list, optional): Subset of nodes to import from the fileskip_missing(bool, defaultTrue): Silently skip nodes that don't exist in the current scenescale_transforms(float, default1.0): Scale factor for translation values (e.g.0.01to convert cm→m)
Returns:
{
"totalNodes": 2,
"successCount": 2,
"failureCount": 0,
"skippedCount": 0
}Example:
# Restore a full scene setup
daz_import_node_config("C:/shots/hero_pose.json")
# Import only Alice's pose from a multi-character file
daz_import_node_config("C:/shots/crowd.json", node_labels=["Alice"])🗺️ Scene Layout & Proximity
daz_get_scene_layout
Full spatial map of all scene nodes with positions and bounding boxes.
Arguments:
include_types(list, optional): Filter by type. Values:"figures","cameras","lights","props". Omit for all types.
Returns:
{
"nodes": [
{
"label": "Genesis 9", "type": "DzFigure",
"position": {"x": 0, "y": 0, "z": 0},
"boundingBox": {"min": {...}, "max": {...}, "center": {...}}
}
],
"count": 8
}Use when: Getting a complete overview of scene spatial layout before adding or moving objects.
daz_find_nearby_nodes
Find all nodes within a radius of a target node.
Arguments:
target_label(string): Center node to search aroundradius(float, default200.0): Search radius in cminclude_types(list, optional): Filter by type:"figures","cameras","lights","props"
Returns:
{
"target": "Alice",
"radius": 200,
"nearby": [
{"label": "Bob", "type": "DzFigure", "distance": 120.5, "direction": "front-right"},
{"label": "Chair", "type": "prop", "distance": 85.0, "direction": "right"}
],
"count": 2
}Direction labels: front, front-right, right, back-right, back, back-left, left, front-left
Use when: Finding all characters or props near a subject, checking interaction range.
⚡ Async Rendering Tools
For long-running operations (full renders, animation export, multi-camera batch), async tools return immediately with a request_id. The script executes serially on DAZ Studio's main thread — the scene is locked while it runs, so subsequent scene modifications queue behind it.
Key constraint: DAZ Studio is single-threaded. Async means the HTTP connection is released immediately — execution is still serial.
daz_render_async
Submit a render asynchronously. Returns immediately with a request_id.
Arguments:
output_path(string, optional): Output file path
Returns:
{
"request_id": "render-a3f2b891",
"status": "queued",
"submitted_at": "2026-04-09T10:15:00"
}daz_render_with_camera_async
Submit a camera-specific render asynchronously.
Arguments:
camera_label(string): Camera to render fromoutput_path(string, optional): Output file path
daz_batch_render_cameras_async
Submit a multi-camera batch render asynchronously.
Arguments:
cameras(list[string]): Camera labelsoutput_dir(string): Output directorybase_filename(string, default"render"): Base filename
daz_render_animation_async
Submit an animation render asynchronously.
Arguments:
output_dir(string): Output directorystart_frame(int, optional): First frameend_frame(int, optional): Last framefilename_pattern(string, default"frame"): Filename prefixcamera(string, optional): Camera to render from
daz_get_request_status
Poll the status of an async request (non-blocking, lightweight).
Arguments:
request_id(string): Request ID from an async submit tool
Returns:
{
"request_id": "render-a3f2b891",
"status": "running",
"progress": 0.0,
"elapsed_ms": 3200,
"queue_position": 0
}Status values: queued, running, completed, failed, cancelled
daz_get_request_result
Fetch the final result of an async request.
Arguments:
request_id(string): Request IDwait(bool, defaultTrue): If True, blocks until complete (up totimeout_seconds)timeout_seconds(int, default300): Max wait time whenwait=True
Returns (completed):
{
"success": true,
"result": {...},
"request_id": "render-a3f2b891",
"duration_ms": 45230,
"completed_at": "2026-04-09T10:15:47",
"status": "completed"
}daz_cancel_request
Cancel a queued or running async request.
Arguments:
request_id(string): Request ID to cancel
Queued requests are removed immediately. Running requests set a cancel flag and call killRender().
Returns:
{
"request_id": "render-a3f2b891",
"status": "cancelled",
"cancelled_at": "2026-04-09T10:15:05"
}daz_list_requests
List all active and recently completed async requests.
Arguments:
status_filter(string, optional): Filter by status:"queued","running","completed","failed","cancelled"
Returns:
{
"requests": [...],
"total": 3,
"queued": 1,
"running": 1,
"completed": 1
}daz_set_render_quality
Set render quality preset before rendering.
Arguments:
preset(string): One of"draft","preview","good","final"
Preset | Typical time | Use case |
| 30s–2min | Quick composition check |
| 2–5min | Client review |
| 10–20min | High quality review |
| 30min–2hr | Final output |
Returns:
{
"preset": "draft",
"settings": {"Max Samples": 100, "Render Quality": 0.5}
}daz_render_batch
Submit a batch of render variants atomically — all validated before any render is queued, each independently cancellable.
Arguments:
variants(list): List of render specs. Each must includeoutput_path. Optional per-variant overrides:width,height,camera,engine,iray_samples,figure/figures,morphs.base(dict, optional): Default settings shared by all variants (overridden by matching keys in each variant).
Returns:
{
"request_ids": ["rnd-a1b2c3d4", "rnd-e5f6g7h8"],
"total": 2
}Example — product photography with expression variants:
daz_render_batch(
base={"figure": "Genesis 9", "width": 1920, "height": 1080},
variants=[
{"output_path": "C:/out/neutral.png", "morphs": {"Smile": 0.0}},
{"output_path": "C:/out/smile.png", "morphs": {"Smile": 1.0}},
{"output_path": "C:/out/serious.png", "morphs": {"Brow Down": 0.5}},
]
)Use daz_get_request_status / daz_get_request_result to monitor each request_id. Up to 100 variants per call.
Async workflow example:
# 1. Set quality and submit
daz_set_render_quality("final")
req = daz_render_async("/renders/final.png")
# 2. Poll status
while True:
status = daz_get_request_status(req["request_id"])
if status["status"] in ("completed", "failed", "cancelled"):
break
# come back later...
# 3. Or use wait=True in one step
result = daz_get_request_result(req["request_id"], wait=True, timeout_seconds=3600)daz_wait_for_scene_event
Block until a specific DAZ Studio scene event fires, using a Server-Sent Events (SSE) stream.
Arguments:
event_types(list[string]): One or more event types to wait fortimeout_seconds(int, default30): Max wait time before raising an error
Available event types:
render.started, render.finished, render.progress, scene.loaded, scene.saved, node.added, node.removed, node.renamed, selection.primary_changed, time.changed, playback.started, playback.stopped, light.added, light.removed, camera.added, camera.removed, skeleton.added, skeleton.removed
Returns:
{
"type": "render.finished",
"ts": "2026-01-01T12:00:05Z",
"data": {}
}Example:
# Fire a render then block until it finishes
daz_render_async("/renders/final.png")
event = daz_wait_for_scene_event(["render.finished"], timeout_seconds=3600)
# Wait for a scene load or save
daz_wait_for_scene_event(["scene.loaded", "scene.saved"], timeout_seconds=60)Note: Requires DazScriptServer to support the GET /scene/events SSE endpoint (available in DazScriptServer v2.5+).
🎬 Cinematic Director Workflow
The cinematic module (tools/cinematic.py) provides 22 high-level tools for professional scene creation. The tools below are a selection of the most commonly used ones; additional tools include daz_animate_camera_movement, daz_create_camera_path, daz_create_character_path, daz_arrange_characters, daz_choreograph_action, daz_setup_shot_coverage, daz_create_camera_rig, daz_animate_light, daz_create_light_sequence, daz_plan_shot, daz_create_storyboard, daz_set_focus_point, daz_animate_focus_pull, daz_time_expression, and daz_sync_character_beats.
daz_create_shot_sequence
Create multi-camera shot sequences for cinematic storytelling.
Automatically creates and positions multiple cameras with keyframe animations for standard cinematic sequences.
Arguments:
sequence_type(string): Type of sequence - "establishing-medium-closeup", "shot-reverse-shot", "orbit", "push-in"characters(list[string]): List of character labels (1-2 depending on sequence)duration(int, default 120): Total duration in frames
Sequence Types:
"establishing-medium-closeup"- Three cameras at different distances (wide → medium → close-up)"shot-reverse-shot"- Two over-shoulder cameras for conversation (requires 2 characters)"orbit"- Single animated camera orbiting 360° around subject"push-in"- Single animated camera dollying from wide to close-up
Returns:
{
"cameras": [
{"label": "Wide Shot", "position": {...}, "frameRange": {"start": 0, "end": 59}},
{"label": "Medium Shot", "position": {...}, "frameRange": {"start": 60, "end": 119}}
],
"totalFrames": 180,
"sequenceType": "establishing-medium-closeup",
"subject": "Genesis 9"
}Example:
# Establishing sequence
daz_create_shot_sequence("establishing-medium-closeup", ["Genesis 9"], duration=180)
# Conversation cameras
daz_create_shot_sequence("shot-reverse-shot", ["Alice", "Bob"], duration=240)
# 360° turntable
daz_create_shot_sequence("orbit", ["Genesis 9"], duration=300)daz_animate_conversation
Choreograph animated conversation between two characters with look-at and emotion keyframes.
Arguments:
char1_label(string): First character labelchar2_label(string): Second character labeldialogue_beats(list[dict]): List of dialogue beats, each containing:speaker(string): Who's speaking (char1 or char2)startFrame(int): Beat start frameendFrame(int): Beat end frameemotion(string): Emotion name - "happy", "sad", "angry", "surprised", "neutral"intensity(float, optional): Emotion intensity 0.0-1.0 (default: 0.7)
Returns:
{
"char1": "Alice",
"char2": "Bob",
"beatsApplied": [
{
"beat": 1,
"speaker": "Alice",
"frameRange": {"start": 0, "end": 60},
"emotion": "happy",
"actions": ["Applied happy emotion (3 morphs)", "Listener looks at speaker"]
}
],
"totalFrames": 180,
"beatCount": 3
}Example:
daz_animate_conversation(
"Alice",
"Bob",
[
{"speaker": "Alice", "startFrame": 0, "endFrame": 60, "emotion": "happy"},
{"speaker": "Bob", "startFrame": 60, "endFrame": 120, "emotion": "surprised"},
{"speaker": "Alice", "startFrame": 120, "endFrame": 180, "emotion": "neutral"}
]
)Features:
Listener automatically looks at speaker during dialogue beat
Emotion morphs applied at beat start
Head/neck rotation for natural look-at behavior
Compatible with shot-reverse-shot camera sequences
daz_create_scene
Generate complete scene from natural language description.
Automatically creates lighting, cameras, and character positioning based on text description using template-based keyword matching.
Arguments:
description(string): Natural language scene descriptioncharacters(list[string], optional): Character labels already in scene
Supported Scene Types:
"dining" / "dinner" / "meal" - Dining scene with characters facing across table
"interview" / "meeting" / "business" - Interview setup with professional lighting
"portrait" / "headshot" / "photo" - Portrait photography with three-point lighting
"conversation" / "talking" / "chat" - Conversation scene with shot-reverse-shot cameras
Generic - Default three-point lighting for unrecognized descriptions
Returns:
{
"sceneType": "dining",
"description": "romantic dinner for two",
"charactersUsed": 2,
"actions": [
"Scene type: Dining/meal scene",
"Positioned characters facing each other across table distance",
"Applied warm romantic lighting"
],
"cameras": [
{"label": "Wide Shot", "type": "wide", "purpose": "Establishing shot of dining scene"},
{"label": "Over Shoulder 1", "type": "over-shoulder", "purpose": "Conversation angle"}
],
"suggestions": [
"Add table prop for dining scene",
"Add plates, glasses, or food props for realism",
"Consider adding candles for romantic dinner mood"
]
}Example:
# Romantic dinner
daz_create_scene("romantic dinner for two", ["Alice", "Bob"])
# Job interview
daz_create_scene("job interview", ["Interviewer", "Candidate"])
# Professional portrait
daz_create_scene("professional portrait", ["Genesis 9"])What Gets Created:
Scene-appropriate lighting (2-3 spot lights)
Character positioning based on scene type
Multiple cameras at strategic angles
Environment mode set to Scene Only
Actionable suggestions for enhancement
daz_start_recording
Start recording a macro to capture sequence of operations.
Arguments:
macro_name(string): Unique macro name (1-64 chars, letters/digits/hyphens/underscores)description(string, optional): Macro description
Returns:
{
"success": true,
"macro_name": "portrait_setup",
"description": "Standard portrait lighting and framing",
"started_at": "2026-04-10T15:30:00",
"message": "Recording macro 'portrait_setup'. Call daz_stop_recording() when done."
}Example:
# Start recording
daz_start_recording("portrait_setup", "Standard portrait workflow")
# Perform operations (these will be recorded)
daz_apply_lighting_preset("three-point", "Genesis 9")
daz_frame_shot("Camera 1", "Genesis 9", "medium-close-up")
# Stop and save
daz_stop_recording()daz_stop_recording
Stop recording current macro and save to library.
Returns:
{
"success": true,
"macro_name": "portrait_setup",
"operation_count": 2,
"saved_at": "2026-04-10T15:31:00",
"message": "Macro 'portrait_setup' saved with 2 operations."
}daz_replay_macro
Replay a saved macro with optional parameter substitution.
Arguments:
macro_name(string): Name of macro to replayparameters(dict, optional): Parameter values for substitution
Returns:
{
"success": true,
"macro_name": "portrait_setup",
"results": [],
"successful_count": 2,
"failed_count": 0
}Example:
# Replay for different character
daz_replay_macro("portrait_setup", parameters={"subject": "Alice"})Note: Parameter substitution not yet implemented in Phase 1 - placeholder for future.
daz_list_macros
List all saved macros in the library.
Returns:
{
"macros": [
{
"name": "portrait_setup",
"description": "Standard portrait workflow",
"operation_count": 2,
"saved_at": "2026-04-10T15:31:00"
}
],
"count": 1
}Note: Macros are session-only (lost when MCP server restarts).
🎨 Material Tools
daz_list_materials
List all materials (surfaces) on a node.
Arguments:
node_label(string): Node display label or internal name
Returns: {"materials": [{"name": "Skin", "index": 0}, ...], "count": N}
daz_get_material
Get all properties of a single material on a node.
Arguments:
node_label(string): Node display labelmaterial_name(string): Material/surface name
Returns: {"node": "...", "material": "Skin", "properties": {"Diffuse Color": ..., "Glossy Reflectivity": ...}}
daz_set_material_property
Set a property on a material surface.
Arguments:
node_label(string): Node display labelmaterial_name(string): Material/surface nameproperty_name(string): Property name (e.g., "Diffuse Color", "Glossy Reflectivity")value: New value (number, color string, or boolean)
daz_apply_material_preset
Apply a material preset .duf file to a node.
Arguments:
node_label(string): Node to apply preset topreset_path(string): Absolute path to preset.duffile
daz_copy_material
Copy a material from one node to another.
Arguments:
source_label(string): Source nodesource_material(string): Source material nametarget_label(string): Target nodetarget_material(string, optional): Target material name (defaults to same as source)
daz_convert_to_iray_uber
Upgrade every material zone on a node from the legacy DzDefaultMaterial shader to genuine
DzUberIrayMaterial. Content merged into a scene as raw DSON (a hand-authored .duf, or output
from a from-scratch scene-merge exporter) reliably lands as DzDefaultMaterial — which doesn't
even read modern channel fields like image_file — no matter how complete its channel data is.
This goes through Daz's own shader-preset application codepath instead (the same thing that
runs when a user drags a Shader Preset from Smart Content onto a figure), which reliably promotes
every zone. Resets every channel to shader defaults — follow with daz_set_material_property
per zone to restore actual values/maps.
Arguments:
node_label(string): Node whose materials should be upgradedpreset_path(string, optional): Absolute path to apreset_shader-type.duf. Defaults to Daz Studio's own stock "!Iray Uber Base" preset, resolved automatically via the content manager.
👗 Wardrobe & dForce Tools
daz_list_fitted_items
List all clothing/hair items fitted to a figure.
Arguments:
figure_label(string): Figure to inspect
Returns: {"figure": "...", "fittedItems": [{"label": "...", "type": "..."}], "count": N}
daz_fit_clothing
Fit a clothing item to a figure (auto-follow skeleton).
Arguments:
clothing_label(string): Clothing node to fitfigure_label(string): Target figure
daz_unfit_item
Unfit a clothing/hair item from its figure.
Arguments:
item_label(string): Item to unfit
daz_run_dforce_simulation
Run dForce cloth simulation on a node.
Arguments:
node_label(string): Node to simulate (ornullfor all dForce items)start_frame(int, optional): Start frameend_frame(int, optional): End frame
daz_bake_simulation
Bake dForce simulation results to static geometry.
Arguments:
node_label(string, optional): Node to bake (ornullfor all)
daz_set_dforce_property
Set a dForce simulation property on a node.
Arguments:
node_label(string): Node with dForce modifierproperty_name(string): dForce property namevalue(float): New value
daz_get_figure_info
Get detailed information about a figure (generation, fitted items, bone count).
Arguments:
figure_label(string): Figure to inspect
daz_set_subdivision
Set subdivision level on a node.
Arguments:
node_label(string): Node to modifylevel(int): Subdivision level (0=base, 1=one level, etc.)
daz_export_fbx
Export a node (or full scene) to FBX format.
Arguments:
node_label(string, optional): Node to export (ornullfor scene)output_path(string): Absolute path for output.fbxfile
daz_export_obj
Export a node to OBJ format.
Arguments:
node_label(string, optional): Node to export (ornullfor scene)output_path(string): Absolute path for output.objfile
🌿 New Character & Lighting Tools (v0.4.0)
daz_set_body_language
Apply full-body posture language to a character (beyond facial expressions).
Arguments:
character_label(string): Character to posestance(string): Body language archetype (e.g.,"confident","defeated","alert","relaxed")intensity(float, default0.7): Intensity 0.0–1.0
daz_direct_gaze
Control where a character's eyes are directed at the sub-expression level.
Arguments:
character_label(string): Characterdirection(string): Gaze direction (e.g.,"camera","up","down","left","right","away")intensity(float, default1.0): Intensity 0.0–1.0
daz_set_mood_lighting
Apply a mood-based lighting setup (emotional/atmospheric presets).
Arguments:
mood(string): Lighting mood (e.g.,"romantic","tense","hopeful","melancholy","dramatic")subject_label(string): Primary subject to light
daz_apply_time_of_day
Configure scene lighting to simulate a time-of-day atmosphere.
Arguments:
time_of_day(string): Time preset (e.g.,"dawn","morning","noon","golden-hour","dusk","night")subject_label(string): Primary subject in the scene
daz_auto_improve_scene
Automatically detect and fix common scene quality issues (lighting gaps, camera positioning, intersections).
Returns: {"improvements": [...], "score_before": N, "score_after": N}
daz_suggest_next_action
Suggest the next logical action based on current scene state.
Returns: {"suggestions": [{"action": "...", "reason": "...", "tool": "..."}]}
daz_get_performance_stats
Get MCP server performance metrics (request counts, latencies, tool call frequencies).
daz_explain_last_error
Get a human-readable explanation of the last error with suggested fixes.
daz_check_compatibility
Check if a content asset is compatible with a figure.
Arguments:
asset_path(string): Absolute path to.dufassetfigure_label(string): Figure to check compatibility against
✏️ Modification Tools
daz_set_property
Set a numeric property on a scene node.
Arguments:
node_label(string): Node display label or internal nameproperty_name(string): Property display label or internal namevalue(float): New value
Returns:
{
"node": "Genesis 9",
"property": "X Translate",
"value": 50.0
}Units:
Translation: centimeters
Rotation: degrees
Morphs: typically 0-1 or percentage
Use when: Moving nodes, adjusting morphs, or changing any numeric property.
Example:
daz_set_property(node_label="Genesis 9", property_name="X Translate", value=100.0)daz_load_file
Load a DAZ Studio file into the scene.
Arguments:
file_path(string): Absolute path to file (.duf,.daz,.obj,.fbx, etc.)merge(bool, defaultTrue): If true, merge into scene; if false, replace scene
Returns:
{
"success": true,
"file": "/path/to/character.duf"
}Use when: Loading characters, props, scenes, or any content files.
Example:
daz_load_file(file_path="/Library/Genesis 9/Character.duf", merge=True)daz_save_scene
Save the current DAZ Studio scene to disk.
Arguments:
file_path(string, optional): Absolute path for Save As. If omitted, saves to the scene's current filename (equivalent to Ctrl+S).
Returns: {"saved": true, "file_path": "/path/to/scene.duf"}
Note: If the scene has never been saved and no file_path is given, provide an explicit path to avoid DAZ opening a dialog.
daz_save_scene_copy
Save a copy of the current scene to a new path without changing the scene's active filename.
Arguments:
path(string): Absolute destination path
Returns: {"ok": true, "path": "/path/to/copy.duf", "source": "/path/to/original.duf", "method": "file-copy"}
Example:
daz_save_scene_copy("C:/backups/hero_v02.duf")Note: Use this for backups and snapshots. Use daz_save_scene when you actually want to switch to a new file.
daz_delete_node
Remove a node and its children from the scene.
Arguments:
node_label(string): Display label or internal name of the node to delete
Returns: {"deleted": "Key Light", "child_count": 0}
Note: Destructive — cannot be undone without reloading from file. Save the scene first with daz_save_scene if you need a recovery point.
daz_set_render_output
Configure render output path and/or image dimensions.
Arguments:
output_path(string, optional): Absolute path for the rendered image (e.g."C:/renders/hero_shot.png")width(int, optional): Render image width in pixelsheight(int, optional): Render image height in pixels
At least one argument must be provided.
Returns: {"changed": ["outputPath", "width", "height"], "current": {...}}
Example:
daz_set_render_output(output_path="C:/renders/scene01.png", width=1920, height=1080)🎬 Rendering Tools
daz_render
Trigger a render using current DAZ Studio render settings.
Arguments:
output_path(string, optional): Absolute path for output image (e.g.,"C:/renders/output.png")
Returns:
{
"success": true
}Notes:
Uses DAZ Studio's currently configured render settings (dimensions, quality, engine)
Blocks until render completes (increase
DAZ_TIMEOUTfor long renders)If
output_pathis omitted, uses DAZ Studio's configured output path
Use when: Rendering the current scene setup.
🎭 Multi-Character Interaction Tools
daz_look_at_point
Make character look at a world-space point with cascading body involvement.
Arguments:
character_label(string): Character display label or internal nametarget_x(float): World X coordinate (cm) to look attarget_y(float): World Y coordinate (cm) to look attarget_z(float): World Z coordinate (cm) to look atmode(string, default"head"): How much body to involve"eyes"- Only rotate eyes"head"- Eyes + head rotation"neck"- Eyes + head + neck"torso"- Eyes + head + neck + chest"full"- Complete body rotation including hip
Returns:
{
"success": true,
"character": "Genesis 9",
"mode": "head",
"rotatedBones": ["lEye", "rEye", "head"]
}Use when: Making a character look at a specific point in 3D space with natural body movement.
Example:
# Look at point in front at eye level
daz_look_at_point("Genesis 9", 0, 160, 200, mode="head")
# Full body turn to look behind
daz_look_at_point("Genesis 9", 0, 140, -150, mode="full")daz_look_at_character
Make one character look at another character's face.
Arguments:
source_label(string): Character who will looktarget_label(string): Character to look atmode(string, default"head"): Body involvement level (same options asdaz_look_at_point)
Returns:
{
"success": true,
"source": "Alice",
"target": "Bob",
"mode": "head",
"targetPosition": {"x": 50, "y": 163, "z": 0},
"rotatedBones": ["lEye", "rEye", "head"]
}Use when: Creating eye contact or attention between characters.
Example:
# Alice looks at Bob
daz_look_at_character("Alice", "Bob", mode="head")
# Bob turns whole body to face Alice
daz_look_at_character("Bob", "Alice", mode="full")daz_reach_toward
Position character's arm to reach toward a world-space point using pseudo-IK.
Arguments:
character_label(string): Character display label or internal nameside(string): Which arm:"left"or"right"target_x(float): World X coordinate (cm) to reach towardtarget_y(float): World Y coordinate (cm) to reach towardtarget_z(float): World Z coordinate (cm) to reach toward
Returns:
{
"success": true,
"character": "Genesis 9",
"side": "right",
"targetDistance": 45.3,
"bones": ["right shoulder", "right forearm", "right hand"]
}Use when: Positioning hands to grasp objects, point at things, or reach toward targets.
Example:
# Reach right hand toward object at chest height
daz_reach_toward("Genesis 9", "right", 50, 130, 80)
# Reach left hand toward object on left side
daz_reach_toward("Genesis 9", "left", -60, 100, 50)Note: Uses simplified IK approximation. For precise hand positioning, load artist-created pose presets.
daz_interactive_pose
Coordinate two characters for interactive poses.
Arguments:
char1_label(string): First character display labelchar2_label(string): Second character display labelinteraction_type(string, default"face-each-other"): Type of interaction"face-each-other"- Position and rotate to face each other"hug"- Both characters hug with arms around each other"shoulder-arm"- Char1 puts arm around char2's shoulders"handshake"- Both extend right hands for handshake
distance(float, optional): Spacing between characters in cm
Returns:
{
"success": true,
"char1": "Alice",
"char2": "Bob",
"interactionType": "hug",
"applied": ["facing", "hug arms"]
}Use when: Creating common two-character interactions quickly.
Example:
# Position characters facing each other at conversation distance
daz_interactive_pose("Alice", "Bob", "face-each-other", distance=120)
# Create tight hug
daz_interactive_pose("Alice", "Bob", "hug", distance=30)
# Bob puts arm around Alice's shoulders
daz_interactive_pose("Bob", "Alice", "shoulder-arm")Note: These are simplified interaction poses. Fine-tune positions afterward using daz_set_property.
daz_reset_pose
Zero all bone rotations on a figure, returning it to its rest pose.
Arguments:
node_label(string): Figure to resetzero_transforms(bool, defaultFalse): If True, also zero the root XYZ translation and reset Scale to 1.0
Returns: {"node": "Genesis 9", "bones_reset": 127, "transforms_zeroed": false}
Note: Does not affect morph values or animation keyframes.
daz_save_pose
Capture all bone rotations from a figure and save to a portable JSON pose file.
Arguments:
figure_label(string): Source figurepose_name(string): Human-readable name stored in the fileoutput_path(string): Absolute path for the.jsonoutput file
Returns: {"success": true, "bone_count": 127, "file": "/path/to/pose.json"}
Example:
daz_save_pose("Genesis 9", "Hero Idle", "C:/poses/hero_idle.json")daz_load_pose
Apply a saved pose file to a figure.
Arguments:
figure_label(string): Target figurepose_path(string): Absolute path to the.jsonpose filebone_group(string, default"full"): Filter which bones to apply —"full","arms_only","legs_only", or"spine"
Returns: {"success": true, "bones_applied": 127, "bones_skipped": 0}
Example:
# Apply full pose
daz_load_pose("Genesis 9", "C:/poses/hero_idle.json")
# Apply only the arms from a pose to a different character
daz_load_pose("Alice", "C:/poses/reaching.json", bone_group="arms_only")🔧 Low-Level Tools
daz_execute
Execute arbitrary inline DazScript code.
Arguments:
script(string): DazScript (JavaScript) source codeargs(dict, optional): JSON object accessible in script asargsvariable
Returns:
{
"success": true,
"result": 42,
"output": ["line from print()"],
"error": null,
"request_id": "a3f2b891"
}Script Requirements:
Wrap returning scripts in IIFE:
(function(){ return 42; })()Global objects available:
Scene,App,MainWindowAccess args via:
var value = args.myKey;
Use when: You need fine-grained control or operations not covered by high-level tools.
Example:
script = "(function(){ return Scene.getNumNodes(); })()"daz_execute_file
Execute a DazScript file from disk.
Arguments:
script_file(string): Absolute path to.dsaor.dsfileargs(dict, optional): JSON object accessible asargsin the script
Returns: Same format as daz_execute
Use when: Running complex scripts stored in files, especially scripts that use include() or getScriptFileName().
Features
🚀 Script Registry
High-level tools (daz_scene_info, daz_get_node, etc.) use the DazScriptServer script registry:
Scripts are registered once at startup via
_registry.pySubsequent calls execute by ID (no retransmission)
Auto-reregistration on 404 (when DAZ Studio restarts)
🔄 Automatic Reconnection
If DAZ Studio restarts and clears the session registry, the server automatically detects 404 responses, re-registers all scripts, and retries the operation.
🛡️ Error Handling
Connection failures → Clear error messages ("Ensure DAZ Studio is running...")
Timeouts → Actionable guidance (increase
DAZ_TIMEOUT)Authentication failures → Token file location in error message
Script errors → Full error details with line numbers and captured output
🏗️ Modular Architecture (v0.4.0)
The server was refactored from a single 15,000-line server.py into 13 focused tool modules under tools/. A shared _mcp.py holds the FastMCP instance and all execute helpers, avoiding circular imports. Import-time side effects register all @mcp.tool() decorators when tools/__init__.py is imported.
🎬 Cinematic Director Workflow
22 high-level cinematic tools for professional scene creation:
Scene Generation: Create complete scenes from natural language (5 templates: dining, interview, portrait, conversation, generic)
Shot Sequences: Multi-camera cinematography (establishing shots, shot-reverse-shot, orbit, push-in)
Camera Animation: Dolly, push-in, orbit paths with keyframe control
Conversation Choreography: Automated dialogue animation with look-at behavior and emotion timing
Lighting Animation: Animated light sequences, mood lighting, time-of-day
Shot Planning: Storyboard creation, shot coverage, focus/DOF control
Macro System: Record and replay operation sequences for workflow automation (session-based)
Usage Examples
Example 1: Check Status
# In Claude Desktop, just ask:
"Check if DAZ Studio is running"
# Claude will use daz_status and report backExample 2: Load and Position Character
1. Load Genesis 9 from /Library/Genesis 9/Genesis9.duf
2. Move it 100cm to the right
3. Get the current scene infoClaude will:
Call
daz_load_file(file_path="/Library/Genesis 9/Genesis9.duf", merge=True)Call
daz_set_property(node_label="Genesis 9", property_name="X Translate", value=100.0)Call
daz_scene_info()and report the results
Example 3: Custom Lighting Setup
Execute this DazScript to create a three-point light setup:
- Key light at (200, 200, 200) pointing at origin
- Fill light at (-100, 150, 150) pointing at origin
- Rim light at (0, 180, -200) pointing at originClaude will use daz_execute with the appropriate DazScript code.
Example 4: Batch Rendering
Render the current scene to these output paths:
- C:/renders/front.png
- C:/renders/side.png
- C:/renders/back.png
Between each render, rotate the character 90 degrees.Claude will loop through, adjusting rotation and calling daz_render for each output.
Example 5: Generate Complete Scene (Phase 4)
Create a romantic dinner scene with Alice and BobClaude will:
Call
daz_create_scene("romantic dinner for two", ["Alice", "Bob"])Positions characters facing each other
Creates warm romantic lighting (2 spot lights)
Creates wide shot and over-shoulder cameras
Returns suggestions: add table, plates, candles
Report the created cameras and lighting setup
Suggest next steps based on the suggestions
Example 6: Animated Conversation (Phase 4)
Create an animated conversation between Alice and Bob:
- Alice speaks happily from frame 0-60
- Bob responds with surprise from 60-120
- Alice concludes neutrally from 120-180Claude will:
Call
daz_animate_conversation("Alice", "Bob", [...dialogue beats...])Sets up look-at behavior (listener looks at speaker)
Applies emotion morphs at beat boundaries
Animates head/neck rotation for natural movement
Call
daz_create_shot_sequence("shot-reverse-shot", ["Alice", "Bob"], 180)Creates over-shoulder cameras for conversation
Report the animation setup and suggest render workflow
Troubleshooting
"Cannot connect to DAZ Studio"
Cause: DazScriptServer plugin is not running or not listening on the expected port.
Solutions:
Open DAZ Studio
Go to Window → Panes → Daz Script Server
Click Start Server
Verify it's running on port 18811 (or update
DAZ_PORTenv var)
"Authentication failed (HTTP 401)"
Cause: API token is missing or incorrect.
Solutions:
Check DazScriptServer UI shows authentication is enabled
Verify token file exists:
~/.daz3d/dazscriptserver_token.txtCopy token exactly from DazScriptServer UI
Set
DAZ_API_TOKENenvironment variable if using custom location
"Request timed out after 30s"
Cause: Script or render took longer than the timeout.
Solutions:
Increase timeout:
export DAZ_TIMEOUT=120.0Update Claude Desktop config with larger timeout in
envsectionRestart Claude Desktop after config change
"Script execution failed" or "Node not found"
Cause: DazScript error (syntax, missing node, wrong property name).
Solutions:
Check the error message for line numbers and details
Verify node labels match exactly (case-sensitive)
Use
daz_get_nodeto discover available property namesTest scripts manually in DAZ Studio Script IDE first
Development
Running Tests
# Run all tests
uv run pytest tests/ -v
# Run specific test
uv run pytest tests/test_server.py::test_daz_status_ok -vProject Structure
vangard-daz-mcp/
├── src/vangard_daz_mcp/
│ ├── server.py # Entry point: imports _mcp and tools package
│ ├── _mcp.py # Shared FastMCP instance, lifespan, execute helpers
│ ├── _client.py # httpx client singleton + env config
│ ├── _errors.py # Error handling helpers
│ ├── _registry.py # Script pre-registration at startup
│ ├── dazscript_docs.json # DazScript documentation (daz_script_help)
│ └── tools/
│ ├── __init__.py # Imports all 13 modules (registers @mcp.tool decorators)
│ ├── spatial.py # World position, bounding box, distance, layout (7 tools)
│ ├── transform.py # Node properties, batch ops, visibility, selection (7 tools)
│ ├── scene.py # Load/save, hierarchy, checkpoints (11 tools)
│ ├── figure.py # Posing, look-at, IK, interaction, pose library (7 tools)
│ ├── morph.py # Morphs, emotions, body language, gaze (6 tools)
│ ├── camera_light.py # Cameras, lights, presets, mood/time-of-day (15 tools)
│ ├── render.py # Sync/async render, batch, animation export (16 tools)
│ ├── animation.py # Keyframes, timeline, frame range (7 tools)
│ ├── material.py # Materials: list, get, set, presets, copy (5 tools)
│ ├── utility.py # Status, execute, docs, validate, macros (18 tools)
│ ├── content.py # Content browser, search, compatibility (6 tools)
│ ├── cinematic.py # Shot sequences, camera paths, storyboard (22 tools)
│ └── wardrobe.py # Clothing, dForce, subdivision, export (10 tools)
├── tests/
│ └── test_server.py # Test suite with respx mocks
├── pyproject.toml # Project config (version, dependencies)
├── ASYNC_OPERATIONS.md # Design doc for async rendering system
├── IMPLEMENTATION_PLAN.md # Phased feature roadmap
└── README.mdArchitecture
FastMCP 3.x server with stdio transport (138 tools registered)
Modular tool package: 13 focused modules under
tools/;@mcp.tool()decorators fire at import time via the sharedmcpinstance from_mcp.py, avoiding circular imports withserver.pyhttpx.AsyncClient for HTTP requests to DazScriptServer; managed in
_client.pysingletondazpy SDK (installed from PyPI as
dazpy>=2.6.0): synchronous Python SDK; all dazpy calls wrapped inasyncio.to_threadviarun_dazpy()Script registry (
_registry.py): high-level tool scripts pre-registered at startup, executed by ID; auto-re-registered on 404 when DAZ Studio restartslifespan context manages httpx client initialization and cleanup
Requirements
Python: 3.11+
Dependencies:
fastmcp>=2.0- MCP server frameworkhttpx>=0.27- Async HTTP clientdazpy>=2.6.0- Synchronous Python SDK for DazScriptServer (installed from PyPI)
Dev Dependencies:
pytest>=8.0pytest-asyncio>=0.24respx>=0.21- HTTP mocking for tests
Limitations
DAZ Studio must be running locally (no remote DAZ Studio support); compatible with DAZ Studio 4.5+ and 6.25+
DazScriptServer plugin must be installed and active — ensure you install the version matching your DAZ Studio installation
All scene operations execute on DAZ Studio's main thread — operations are serialized even with async tools
While a render is running, no other scene operations can execute (scene is locked)
Scene checkpoints are in-memory only and lost if the MCP server restarts
No support for binary data (rendered images must be saved to disk, not returned directly)
Related Projects
DazScriptServer: https://github.com/bluemoonfoundry/daz-script-server
The HTTP plugin this server wraps
Required prerequisite
Model Context Protocol: https://modelcontextprotocol.io
Specification this server implements
FastMCP: https://github.com/jlowin/fastmcp
Framework used to build this server
Contributing
Contributions welcome! Areas for improvement:
Support for binary data (screenshot capture, returning rendered images directly)
Integration tests with a real DAZ Studio instance
More DazScript documentation topics in
dazscript_docs.jsonAdditional lighting presets and emotion definitions
Remote DAZ Studio support (connect to DAZ Studio on a different machine)
License
This project is provided as-is for use with DAZ Studio.
Author: Blue Moon Foundry
For questions or issues, please open an issue on GitHub.
Available Tools
70 toolsdaz_apply_camera_angleA
Apply a standard camera angle preset relative to a subject.
Maintains the camera's current horizontal distance from the subject while adjusting vertical position and aim to achieve the specified angle. If the camera is closer than 50 cm it defaults to 250 cm.
Args: camera_label: Node label of the camera to reposition. subject_label: Node label of the subject. angle: One of: - "eye-level" — Camera at subject's eye height (neutral, default) - "high-angle" — Camera above subject (~1.5× head height), looking down - "low-angle" — Camera at shin level, looking up (powerful/dominant) - "dutch-angle" — Eye level with 15° Z-roll (unsettling, tense) - "overhead" — Camera directly above (bird's-eye view) - "worms-eye" — Camera at ground level looking straight up - "over-shoulder" — Camera behind and to one side of subject
Returns: Dict with camera, subject, angle, camera_position, and descriptive note.
| Name | Required | Description | Default |
|---|---|---|---|
| camera_label | Yes | ||
| subject_label | Yes | ||
| angle | No | eye-level |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses important behaviors: it maintains horizontal distance, adjusts vertical position, and defaults distance if under 50 cm. It also lists all angle options. It lacks details on error handling or prerequisites, but covers core behavior well.
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 well-structured with a title, detailed paragraphs, and a bullet-like list for angle options. It is somewhat lengthy but all information is relevant. Minor verbosity could be trimmed, but overall efficient.
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?
Given the tool's simplicity (3 parameters, simple output) and the presence of an output schema, the description covers functionality, parameters, behavior, defaults, and return fields. It lacks information on error conditions or required permissions, but is largely complete for its purpose.
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?
With 0% schema description coverage, the provider relies entirely on the tool description. It fully explains each parameter: camera_label and subject_label are node labels, and angle is a string with all valid values listed. This adds essential meaning beyond the schema.
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 uses a specific verb ('Apply') and resource ('camera angle preset'), and clarifies it is relative to a subject. It clearly distinguishes this tool from sibling tools like daz_orbit_camera_around or daz_frame_camera_to_node by specifying presets.
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 provides clear context on when to use the tool (applying standard angle presets) and includes behavioral details like maintaining horizontal distance and defaulting if too close. However, it does not explicitly contrast with alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_apply_composition_ruleA
Position camera so subject is framed according to a photography composition rule.
The camera maintains approximately its current horizontal distance from the subject while adjusting position and aim to satisfy the chosen rule.
Args: camera_label: Node label of the camera to reposition. subject_label: Node label of the subject to frame. rule: One of: - "rule-of-thirds" — Subject on right vertical third at eye level (default) - "golden-ratio" — Subject at the golden section (1.618 proportion) - "center-frame" — Subject centred, symmetric framing - "leading-lines" — Low angle with diagonal offset toward subject
Returns: Dict with camera, subject, rule, camera_position, and explanation string.
| Name | Required | Description | Default |
|---|---|---|---|
| camera_label | Yes | ||
| subject_label | Yes | ||
| rule | No | rule-of-thirds |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses that the camera maintains horizontal distance while adjusting position and aim, and explains each rule's effect. However, it does not mention if keyframes are set or how conflicts are handled.
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 well-structured: a one-sentence purpose, a behavioral note, a clear Args list, and a Returns section. No redundant information, every sentence adds value.
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?
Given the tool has 3 parameters and a described output, the description covers behavior, parameters, and return values. However, it could mention error handling or constraints (e.g., node existence) and the approximate nature of distance maintenance could be clarified.
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 input schema has 0% description coverage, so the description fully compensates by detailing each parameter (camera_label, subject_label, rule) with explanations and rule options. This provides clear semantics beyond the schema's raw type information.
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 clearly states the tool's function: positioning a camera to frame a subject according to a composition rule. It lists specific rules and notes that the camera maintains horizontal distance, distinguishing it from generic framing tools.
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 explicit guidance on when to use this tool versus siblings like daz_frame_camera_to_node or daz_look_at_character. The description implies usage for compositional rules but does not mention alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_apply_lighting_presetA
Create a professional photography lighting setup in one command.
Removes any existing lights with the same names, creates new lights at positions calculated relative to the subject's bounding box, aims each light at the subject's face height, and sets the environment to scene-lights-only mode (disables the dome).
Available presets: three-point - Key (front-right) + Fill (front-left) + Rim (back). The most versatile general-purpose lighting setup. rembrandt - Key (45° side, high) + dim Fill. Creates triangle of light under opposite eye. Dramatic portrait lighting. butterfly - Key directly in front, high. Glamour/beauty lighting. Creates butterfly shadow under the nose. split - Key directly to one side (90°). Half face lit, half in shadow. Moody, high-contrast. loop - Key (35° side) + Fill + Rim. Natural-looking portrait. Small loop shadow on opposite cheek.
Args: preset: Lighting preset name (see above) subject_label: Optional node label to anchor lights around. If omitted, lights are placed relative to scene origin at 170cm height.
Returns: { "preset": "three-point", "subject": "Genesis 9", "lights_created": [ {"label": "Key Light", "type": "DzSpotLight", "position": {"x": 150, "y": 180, "z": 150}, "flux": 2000} ], "environment_mode": "Scene Only (3)" }
| Name | Required | Description | Default |
|---|---|---|---|
| preset | Yes | ||
| subject_label | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides key behavioral details: removal of existing lights with same names, relative positioning to subject's bounding box, aiming at face height, and disabling the dome. However, it does not cover potential mutations beyond those mentioned, such as whether the scene is saved or if permissions are required.
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 well-structured: a one-line summary, behavioral details, preset list with explanations, args section, and returns example. It is concise yet comprehensive, with no wasted words.
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?
The description covers side effects, parameter defaults, preset explanations, and return format (including JSON example). It does not mention error conditions or limitations, but given the presence of an output schema, it is largely sufficient.
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%, but the description thoroughly explains both parameters: 'preset' with a list of options and descriptions, and 'subject_label' with default behavior (scene origin at 170cm). This adds significant value beyond the bare schema.
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 clearly states the tool creates a professional photography lighting setup. It details the actions: removing existing lights, creating new lights relative to the subject, aiming at face height, and setting environment mode. This differentiates it clearly from sibling tools like daz_apply_camera_angle or daz_apply_composition_rule.
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 what the tool does but does not explicitly state when to use it versus alternatives or when not to use it. It implicitly suggests use for lighting setup but lacks explicit guidance on context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_batch_render_camerasA
Render from multiple cameras in sequence.
Renders the same scene from multiple camera angles in a single operation. Each camera generates a separate output file with the camera name appended.
Args: cameras: List of camera labels to render from. output_dir: Output directory for rendered images. base_filename: Base filename (default: "render"). Camera name is appended automatically.
Returns:
success: true on success
rendered: Array of {camera, outputPath} objects
total: Total number of cameras attempted
Example: # Render from multiple preset cameras daz_batch_render_cameras( cameras=["Front", "Side", "Top", "Perspective"], output_dir="/path/to/renders", base_filename="character" ) # Generates: character_Front.png, character_Side.png, etc.
# Render turntable (8 cameras around character)
cameras = [f"Cam_{angle}" for angle in [0, 45, 90, 135, 180, 225, 270, 315]]
daz_batch_render_cameras(cameras, "/path/to/turntable", "frame")
# Render all cameras in scene
scene_info = daz_scene_info()
all_cameras = [cam['label'] for cam in scene_info['cameras']]
daz_batch_render_cameras(all_cameras, "/path/to/renders")Note: - Camera names in filenames have non-alphanumeric chars replaced with underscores - All renders use current scene state (same lighting, poses, etc.) - Previous render camera is restored after batch completes - Cameras that don't exist are skipped
| Name | Required | Description | Default |
|---|---|---|---|
| cameras | Yes | ||
| output_dir | Yes | ||
| base_filename | No | render |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: file naming with underscore replacement, use of current scene state, restoration of previous camera, and skipping non-existent cameras. This is comprehensive.
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 well-structured with sections (brief intro, Args, Returns, Example, Note). It is concise yet thorough, with every paragraph adding value.
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?
Given the tool's complexity and presence of output schema, the description covers input parameters, return values, examples, and behavioral notes. It is complete for an agent to use 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?
The schema has 0% description coverage, but the description adds full meaning: cameras as list of labels, output_dir as directory, base_filename default with auto-appended camera name. Examples further clarify usage.
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 clearly states 'Render from multiple cameras in sequence,' specifying the verb (render), resource (cameras), and scope (batch). It distinguishes from siblings like single-camera renders and async variants.
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 provides examples and notes on when to use the tool (multiple cameras) and behavior (skipping non-existent cameras). However, it does not explicitly state when not to use it compared to alternatives like single-camera renders, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_batch_render_cameras_asyncA
Queue renders from multiple cameras — each becomes its own async request.
Submits one async render per camera and returns all request IDs immediately. Renders execute serially (DAZ is single-threaded), so they queue behind any already-running request. Each camera render is independently cancellable.
Args: cameras: List of camera display labels. output_dir: Directory where rendered images are saved. base_filename: Filename prefix. Output is _.png.
Returns: { "request_ids": ["script-XXXXXXXX", ...], "total": 3, "cameras": ["Cam_0", "Cam_45", "Cam_90"] }
Example: batch = await daz_batch_render_cameras_async( cameras=["Cam_0", "Cam_45", "Cam_90"], output_dir="/renders/turntable" ) # Monitor all renders for req_id in batch["request_ids"]: result = await daz_get_request_result(req_id, wait=True)
| Name | Required | Description | Default |
|---|---|---|---|
| cameras | Yes | ||
| output_dir | Yes | ||
| base_filename | No | render |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that renders execute serially due to DAZ being single-threaded, queuing behind running requests, and that each render is independently cancellable. It does not mention file overwrite behavior or prerequisites, but the disclosed traits are sufficient for typical use.
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 well-structured with a one-line summary, behavioral details, clearly labeled Args/Returns sections, and a complete example. Every sentence adds value without 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?
Given the lack of annotations and output schema not shown, the description covers behavior, parameters, and return structure comprehensively. It could mention error cases or prerequisites (e.g., camera labels must exist), but the provided details are sufficient for correct invocation.
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 has 0% description coverage, but the description fully explains each parameter: cameras as 'List of camera display labels.', output_dir as 'Directory where rendered images are saved.', and base_filename with the naming pattern. The example reinforces usage.
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 clearly states the tool queues renders from multiple cameras into individual async requests. It distinguishes itself from siblings like daz_batch_render_cameras (likely synchronous) and other single-camera render tools by highlighting async behavior and multi-camera capability.
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 when to use the tool (multiple camera renders asynchronously) and provides an example of monitoring renders with daz_get_request_result. However, it does not explicitly state when not to use it or compare to alternatives like daz_render_async or daz_batch_render_cameras.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_batch_selectA
Select multiple nodes in the DAZ Studio scene.
Args: node_labels: List of node display labels to select. add_to_selection: If True, add to current selection; if False, replace current selection (default: False).
Returns:
selected: Array of node labels that were successfully selected
count: Number of nodes selected
total: Total number of node labels provided
Example: # Select multiple characters daz_batch_select(["Genesis 9", "Genesis 8 Female"])
# Add props to current selection
daz_batch_select(["Sword", "Shield"], add_to_selection=True)
# Select all lights in scene
daz_batch_select(["Spot Light 1", "Distant Light 1", "Point Light 1"])Note: Selection affects which nodes appear in the Scene/Parameters panes in DAZ Studio. Some operations apply to the current selection. Nodes that don't exist are silently skipped.
| Name | Required | Description | Default |
|---|---|---|---|
| node_labels | Yes | ||
| add_to_selection | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that non-existent nodes are silently skipped and explains the add_to_selection behavior. It also notes the effect on DAZ Studio UI, providing sufficient behavioral context for a non-destructive 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?
The description is well-structured with Args, Returns, Example, and Note sections. It is concise and every sentence adds value without 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?
Given the tool's moderate complexity (2 parameters, output schema present), the description covers all necessary aspects: purpose, parameters, return values, examples, and behavioral notes. It is complete.
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 description compensates well. It defines node_labels as 'list of node display labels to select' and add_to_selection with its effect and default. Examples further clarify usage.
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 clearly states 'Select multiple nodes in the DAZ Studio scene.' It uses a specific verb ('select') and resource ('nodes'), and the examples distinguish it from sibling tools like daz_batch_visibility or daz_batch_transform.
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 that selection affects UI panes and that some operations apply to the current selection, providing context for when to use. However, it does not explicitly exclude scenarios or mention alternatives for single-node selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_batch_set_propertiesA
Set multiple properties on one or more nodes in a single call.
Executes multiple property-setting operations with individual error handling. Failed operations don't abort the entire batch - each operation returns success status and error details.
Args: operations: List of operation objects, each containing: - nodeLabel (str): Display label of the node - propertyName (str): Property label or internal name - value (float): New value for the property
Returns:
results: Array of result objects with success, node, property, value, error
successCount: Number of successful operations
failureCount: Number of failed operations
total: Total number of operations attempted
Example: # Set multiple properties on different nodes daz_batch_set_properties([ {"nodeLabel": "Genesis 9", "propertyName": "XTranslate", "value": 100}, {"nodeLabel": "Genesis 9", "propertyName": "YRotate", "value": 45}, {"nodeLabel": "Camera 1", "propertyName": "ZTranslate", "value": 300} ])
# Apply multiple morphs to a character
daz_batch_set_properties([
{"nodeLabel": "Genesis 9", "propertyName": "PHMSmile", "value": 0.5},
{"nodeLabel": "Genesis 9", "propertyName": "PHMEyesWide", "value": 0.3},
{"nodeLabel": "Genesis 9", "propertyName": "PHMBrowsUp", "value": 0.4}
])Note: This is significantly more efficient than calling daz_set_property individually for each operation. All operations execute in a single script call to DAZ Studio.
| Name | Required | Description | Default |
|---|---|---|---|
| operations | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses individual error handling for each operation, that failed operations do not abort the batch, and that operations execute in a single script call. As there are no annotations, it bears full burden and does so adequately, though it could mention whether operations are atomic or if partial effects are committed.
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 well-organized with sections for purpose, args, returns, examples, and a note. Every sentence adds value, examples are clear, and the structure is easy to parse. No redundant information.
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?
Given the lack of annotations and presence of an output schema, the description provides complete context: purpose, argument semantics, return structure, usage guidance, and examples. It addresses the tool's complexity (batch operations with error handling) comprehensively.
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 description adds substantial meaning beyond the input schema, which only defines 'operations' as an array of objects. It specifies each operation object contains nodeLabel, propertyName, and value, with types and descriptions, compensating for the schema's additionalProperties: true and lack of detail.
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?
Description clearly states the tool sets multiple properties on one or more nodes in a single call. It distinguishes itself from the sibling daz_set_property by emphasizing batch efficiency. The verb 'Set' and resource 'multiple properties on nodes' are precise.
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?
Explicit note states this tool is more efficient than calling daz_set_property individually, guiding the agent to use it for batch operations. However, it does not explicitly list scenarios where it is not appropriate or alternative tools beyond daz_set_property.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_batch_transformA
Apply the same transform properties to multiple nodes.
Useful for moving, rotating, or scaling multiple objects by the same amount. Only properties that exist on each node are applied (missing properties are silently skipped).
Args: node_labels: List of node display labels to transform. transforms: Dictionary of property names to values (e.g., {"XTranslate": 50, "YRotate": 45}).
Returns:
results: Array of result objects with success, node, applied properties, error
successCount: Number of nodes successfully transformed
failureCount: Number of nodes that failed
total: Total number of nodes attempted
Example: # Move multiple props to the right daz_batch_transform( ["Prop1", "Prop2", "Prop3"], {"XTranslate": 100} )
# Rotate and scale multiple objects
daz_batch_transform(
["Chair", "Table", "Lamp"],
{"YRotate": 45, "Scale": 1.2}
)
# Reset rotation for all cameras
daz_batch_transform(
["Camera 1", "Camera 2", "Camera 3"],
{"XRotate": 0, "YRotate": 0, "ZRotate": 0}
)Note: Transform properties include: XTranslate, YTranslate, ZTranslate, XRotate, YRotate, ZRotate, Scale, XScale, YScale, ZScale.
| Name | Required | Description | Default |
|---|---|---|---|
| node_labels | Yes | ||
| transforms | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description adds behavioral context: missing properties are silently skipped, and return structure is detailed. However, it doesn't mention permissions, reversibility, or other side effects. With no annotations, description carries full burden but is adequate.
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?
Well-structured with Args, Returns, Example, and Note sections. Front-loaded with purpose. Each sentence serves a purpose; no fluff.
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?
Given 2 parameters and existence of output schema, description covers operation, fallback behavior (silent skip), return structure, and examples. Missing error handling details, but output schema likely covers that. Sufficient for a batch 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 description must compensate. It explains node_labels as 'list of node display labels' and transforms as 'dictionary of property names to values', with a list of valid transform properties and examples. This adds significant meaning beyond the raw schema.
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 clearly states it applies the same transform properties to multiple nodes. Examples and list of transform properties further clarify. It distinguishes from siblings like daz_batch_set_properties (sets arbitrary properties) and daz_batch_select (selects nodes).
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 says 'Useful for moving, rotating, or scaling multiple objects by the same amount.' This provides clear context, but it doesn't explicitly contrast with alternatives (e.g., daz_set_property for single node) or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_batch_visibilityA
Show or hide multiple nodes in the viewport and renders.
Args: node_labels: List of node display labels to modify. visible: True to show nodes, False to hide them (default: True).
Returns:
results: Array of result objects with success, node, visible state, error
successCount: Number of nodes successfully modified
failureCount: Number of nodes that failed
total: Total number of nodes attempted
Example: # Hide all cameras daz_batch_visibility(["Camera 1", "Camera 2", "Camera 3"], visible=False)
# Show multiple props
daz_batch_visibility(["Sword", "Shield", "Helmet"], visible=True)
# Hide environment elements for character close-up
daz_batch_visibility(["Ground", "Sky Dome", "Background"], visible=False)Note: Hidden nodes are not visible in the viewport or renders, but remain in the scene. Use this for scene management, testing different configurations, or optimizing render times.
| Name | Required | Description | Default |
|---|---|---|---|
| node_labels | Yes | ||
| visible | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, description carries full burden. It discloses that hidden nodes remain in scene, affects viewport and renders, and includes return structure. Missing details on undo behavior or batch size limits, but adequate.
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?
Well-structured with Args, Returns, Example, Note sections. Purpose is front-loaded. Slightly long but each section adds value. Could be more concise but still efficient.
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?
Covers purpose, parameters, returns, behavioral note, and examples. Output schema is described in text. No mention of permissions or prerequisites, but sufficient for most use cases.
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% (no descriptions in schema), but description fully explains both parameters: node_labels (list of labels) and visible (boolean, default true). Adds examples showing usage. Adds meaning beyond schema types.
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?
Description clearly states it shows or hides multiple nodes in viewport and renders. Verb+resource combination is specific and distinct from siblings like daz_batch_select or daz_batch_transform.
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 context on when to use (scene management, testing, render optimization) but does not explicitly state when not to use or compare to alternative tools like daz_batch_set_properties.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_browse_categoryA
List .duf content files in a content library category path.
Searches all configured DAZ content directories and deduplicates by filename.
Args: category_path: Relative path within content directories (e.g. "People/Genesis 9/Hair"). sort_by: Sort order — only "name" is currently supported (alphabetical).
Returns: Dict with category, items (list of {name, filename, full_path}), and count.
Example: daz_browse_category("People/Genesis 9/Hair") daz_browse_category("Props/Furniture")
| Name | Required | Description | Default |
|---|---|---|---|
| category_path | Yes | ||
| sort_by | No | name |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses that it searches all configured directories, deduplicates by filename, and that sort_by only supports 'name'. This covers key behavioral traits for a read-only listing tool. Minor omission: no mention of error behavior for invalid categories.
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 concise and well-structured: a one-line summary, then details, args, returns, and an example. Every sentence serves a purpose without fluff. The example is helpful.
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?
Given the tool's simplicity (2 parameters, read-only), the description covers purpose, parameters, return structure, and deduplication behavior. With an output schema present, return details are sufficient. Missing edge cases like invalid category path, but overall complete for the tool's complexity.
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% (no parameter descriptions in schema), so the description must compensate. It thoroughly explains both parameters: category_path as a relative path with an example, and sort_by as currently supporting only 'name'. This adds significant meaning beyond the schema's type/default.
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 clearly states the tool lists .duf content files in a category path. It uses a specific verb ('list') and resource ('content files'), and distinguishes it from siblings like daz_list_categories by focusing on browsing files within a category, not listing categories.
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 implies usage for browsing files by category but does not explicitly state when to use this tool versus alternatives such as daz_list_categories or daz_get_content_info. No guidance on when not to use it is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_calculate_distanceA
Calculate the distance between two nodes.
Returns total distance, horizontal distance, vertical distance, and the direction vector. All distances in centimeters.
Args: node1_label: Display label of the first node node2_label: Display label of the second node
Returns: { "node1": "Genesis 9", "node2": "Camera 1", "distance": 250.5, "vector": {"dx": 0.0, "dy": 50.0, "dz": 245.0}, "horizontal_distance": 245.0, "vertical_distance": 50.0 }
| Name | Required | Description | Default |
|---|---|---|---|
| node1_label | Yes | ||
| node2_label | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return structure (total distance, horizontal/vertical distance, direction vector) and units (centimeters), and provides an example. However, it does not mention potential errors or prerequisites (e.g., node existence), which is a minor gap.
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 clear and front-loaded with the main action and return summary. The example is helpful but adds length. It could be slightly more concise, but overall efficient.
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?
Given no annotations and no output schema in the input schema, the description provides comprehensive context: inputs, return structure, units, and an example. It fully equips an agent to use the tool 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?
The input schema has 0% description coverage for parameters. The description fully explains both parameters ('node1_label: Display label of the first node' and similarly for node2), adding crucial meaning beyond the schema's type-only definition.
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 clearly states 'Calculate the distance between two nodes' with specific verb and resource, and details the return values. It distinguishes itself from siblings like daz_check_overlap or daz_get_spatial_relationship by focusing on distance metrics.
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 implies usage for distance calculations but does not provide explicit guidance on when to use this tool versus alternatives like daz_check_overlap or daz_reach_toward. No when-not-to-use or prerequisite conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_cancel_requestA
Cancel a queued or running async request.
For queued requests: cancellation is immediate. For running renders: sends a killRender() signal; may take a few seconds to take effect.
Args: request_id: Request ID returned by an async submission tool.
Returns: {"request_id": "...", "status": "cancelled", "cancelled_at": "..."}
Raises ToolError if the request is already finished (completed/failed/cancelled) or not found.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses cancellation behavior (immediate for queued, killRender for running, potential delay), error cases, and the return format. This is comprehensive and transparent.
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 efficiently structured: a one-sentence summary followed by clear bullet points for behavior, args, returns, and errors. Every sentence serves a purpose without 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?
Given the tool's single parameter and straightforward operation, the description covers all necessary aspects: purpose, behavior nuances, input specification, output format, and error handling. It is fully complete for an AI agent to use 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?
The schema provides only type 'string' for request_id with zero description coverage. The tool's description adds critical context: 'Request ID returned by an async submission tool,' which is essential for correct usage. Thus, it adds significant meaning beyond the schema.
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 clearly states the tool's purpose: cancel a queued or running async request. It uses a specific verb ('Cancel') and resource ('async request'), and distinguishes from sibling tools like status or result retrieval.
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 when to use the tool (for queued or running requests) and outlines behavioral differences (immediate vs. killRender signal). It also notes error conditions (already finished or not found). However, it does not explicitly mention when not to use or suggest alternatives, so it loses a point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_check_overlapA
Check if two nodes have overlapping bounding boxes (collision detection).
Uses axis-aligned bounding box (AABB) intersection. Returns whether they overlap, the penetration depth, and a suggestion for resolving the collision.
Args: node1_label: Display label of the first node node2_label: Display label of the second node
Returns: { "node1": "Alice", "node2": "Bob", "overlapping": true, "penetration_depth": 15.0, "suggestion": "Move Bob 20 cm in +X direction to resolve collision" }
| Name | Required | Description | Default |
|---|---|---|---|
| node1_label | Yes | ||
| node2_label | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses use of axis-aligned bounding box (AABB) intersection, return fields (overlap, penetration depth, suggestion). No annotations provided, so description carries the burden adequately.
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?
Well-structured with summary, algorithm, args, and returns. Slightly verbose with the example, but front-loaded with key purpose.
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?
Covers purpose, parameters, algorithm, and return format. No output schema but inline example suffices. Complete for a simple collision detection 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%, but the description explicitly defines the two parameters (node1_label, node2_label) as display labels, adding full meaning beyond the schema.
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 clearly states it checks overlapping bounding boxes (collision detection) between two nodes, using a specific verb and resource, and distinguishes from siblings like daz_calculate_distance.
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 context is clear for collision detection, but there is no explicit guidance on when not to use or comparison with alternatives. The purpose is specific enough that an agent can infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_clear_animationA
Remove all keyframes from a property.
Clears all animation data from a property, returning it to a static (non-animated) state. More efficient than removing keyframes individually.
Args: node_label: Display label of the node. property_name: Property label or internal name.
Returns:
success: true
node: node label
property: property label
removed: number of keyframes removed
Example: # Clear animation from a property result = daz_clear_animation("Genesis 9", "XTranslate") print(f"Removed {result['removed']} keyframes")
# Clear all transform animations
transforms = ["XTranslate", "YTranslate", "ZTranslate",
"XRotate", "YRotate", "ZRotate"]
for prop in transforms:
daz_clear_animation("Genesis 9", prop)Note: - Removes all keyframes in a single operation - More efficient than calling daz_remove_keyframe() repeatedly - Property retains its current value after clearing - Returns count of keyframes that were removed
| Name | Required | Description | Default |
|---|---|---|---|
| node_label | Yes | ||
| property_name | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It explains that all keyframes are removed in one operation, the property retains its current value, and it returns a count of removed keyframes. No contradictions exist.
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 efficient and well-structured: a one-line summary, args, returns, example, and note. Every sentence serves a purpose, and key details are front-loaded.
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 simple removal tool, the description covers inputs, outputs, and behavior completely. The return values are documented, and the example shows typical usage. Given the lack of annotations, this is thorough.
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 schema coverage is 0%, so the description must explain parameters. It does so by defining node_label as 'Display label of the node.' and property_name as 'Property label or internal name.' while providing concrete examples. While not exhaustive, it adds significant meaning beyond the schema.
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 clearly states 'Remove all keyframes from a property' and differentiates from sibling tools like daz_remove_keyframe by noting efficiency gains. It uses a specific verb and resource, making the tool's function unambiguous.
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 gives explicit guidance: use when wanting to clear all animation data from a property, and it's more efficient than using daz_remove_keyframe repeatedly. The note and example further clarify appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_executeA
Execute inline DazScript code in DAZ Studio.
Scripts run in the DAZ Studio JavaScript environment. Global objects: Scene (DzScene), App (DzApp), MainWindow.
⚠️ CRITICAL GOTCHAS - READ BEFORE WRITING SCRIPTS:
❌ NEVER use Action classes (DzNewCameraAction, DzNewLightAction, etc.) They pop modal dialogs and cause TIMEOUTS. ✅ Use direct constructors: new DzBasicCamera(), new DzSpotLight()
❌ NEVER set "Point At" property for camera/light aiming. ✅ Use: node.aimAt(new DzVec3(x, y, z))
✅ Wrap scripts returning values in IIFE: (function(){ return Scene.getNumNodes(); })()
✅ Environment node is ALWAYS Scene.getNode(1) - not findNodeByLabel()
For detailed examples and documentation, use the daz_script_help tool first.
Args:
script: DazScript (JavaScript) source code to execute.
args: Optional JSON object accessible in script as args variable.
Returns: Object with keys: success, result, output (list of print() lines), error.
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | ||
| args | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses behavior: scripts run in JS environment with Scene, App, MainWindow global objects; warns that Action classes cause modal dialogs and timeouts; provides workarounds for aiming and wrapping IIFE. Also describes return format.
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?
Well-structured with bullet points for gotchas, front-loaded with basic purpose. Slightly verbose due to detailed gotchas, but each sentence earns its place given the tool's complexity. Could be trimmed slightly.
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?
Given the tool's complexity (executing arbitrary code), the description is complete: covers purpose, global objects, critical pitfalls, parameter semantics, return structure, and references a documentation tool. Output schema exists, so return details are acceptable.
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 description adds full meaning: script is source code, args is optional JSON accessible as `args` variable. This is critical for correct usage.
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?
Clearly states it executes inline DazScript code in DAZ Studio. Distinguishes from siblings like daz_execute_file (file-based) and daz_validate_script (validation). The verb 'execute' is precise, and resource 'DazScript' is specific.
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 explicit critical gotchas (what to avoid) and instructs to use daz_script_help for documentation. Implies when to use this tool (inline scripts) vs alternatives (e.g., daz_execute_file for files), though not explicitly listing exclusions. Clear context for safe usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_execute_fileA
Execute a DazScript file on disk inside DAZ Studio.
Args:
script_file: Absolute path to the .dsa/.ds script file on the DAZ Studio machine.
args: Optional JSON-serialisable object accessible inside the script as args.
Returns: Object with keys: success, result, output (list of print() lines), error.
| Name | Required | Description | Default |
|---|---|---|---|
| script_file | Yes | ||
| args | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes inputs and return values (success, result, output, error) but does not disclose side effects, permissions, or whether execution is synchronous. Since no annotations exist, description carries full burden but partially addresses it.
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?
Concise one-line purpose followed by clear parameter and return bullet points. No redundant information.
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?
Adequate for a simple execution tool with two parameters and a structured output. Could mention environment constraints like file path accessibility, but overall complete.
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?
Each parameter (script_file with absolute path and file extensions, args as JSON object accessible in script) is fully explained beyond the schema, which had 0% coverage.
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 clearly states the tool executes a DazScript file on disk, using specific verbs and resource. It implicitly differentiates from sibling 'daz_execute' which likely runs inline scripts.
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 use this tool versus alternatives like daz_execute or daz_validate_script. The description only explains the tool itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_find_nearby_nodesA
Find all scene nodes within a specified radius of a target node.
Uses world-space positions to calculate distances. Returns nodes sorted nearest-first with cardinal direction labels.
Args: node_label: Label of the centre node to search around. radius: Search radius in centimetres (default 100 cm). include_types: Filter by type — "figures", "cameras", "lights", "props". None means return all types within radius.
Returns: Dict with center_node, radius, nearby_nodes (list of {label, type, distance, direction}), and count.
Example: daz_find_nearby_nodes("Genesis 9", radius=150) # everything within 1.5 m daz_find_nearby_nodes("Chair", radius=80, include_types=["figures"]) # people near chair
| Name | Required | Description | Default |
|---|---|---|---|
| node_label | Yes | ||
| radius | No | ||
| include_types | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that it uses world-space positions and returns direction labels, but does not mention performance, side effects, or limitations like max radius or hidden nodes.
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 well-structured with a clear first sentence, an explanation, an args list, a returns section, and examples. No redundant or unnecessary information.
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 tool with 3 parameters and an output schema, the description covers behavior, parameters, and return structure. It could explicitly mention handling of empty results or edge cases, but overall complete.
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% (no parameter descriptions in schema), but the description fully documents each parameter including defaults, types, and valid options, and provides examples. This adds significant meaning beyond the schema.
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 clearly states it finds all scene nodes within a specified radius of a target node using world-space positions. This distinguishes it from sibling tools like daz_calculate_distance or daz_get_spatial_relationship.
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 how distances are calculated and that results are sorted nearest-first with direction labels. It provides usage context but does not explicitly state when to use this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_frame_camera_to_nodeA
Frame camera to show a node by positioning at calculated distance.
Positions the camera to frame the specified node in view. Calculates the node's bounding box and positions the camera at an appropriate distance to show the entire object. Camera is positioned in front (+Z) and aimed at the node's center.
Args: camera_label: Display label of the camera to position. node_label: Display label of the node to frame. distance: Optional distance from node center in cm. If not specified, calculated as 2.5x the largest dimension of the node's bounding box.
Returns:
success: true on success
camera: camera label
node: node label
position: camera world position {x, y, z}
nodeCenter: node bounding box center {x, y, z}
nodeSize: node bounding box size {x, y, z}
Example: # Frame a character (auto distance) daz_frame_camera_to_node("Camera 1", "Genesis 9")
# Frame a prop with specific distance
daz_frame_camera_to_node("Camera 1", "Sword", distance=50)
# Frame entire scene
daz_frame_camera_to_node("Camera 1", "Scene", distance=500)
# Close-up on head
daz_frame_camera_to_node("Camera 1", "head", distance=30)Note: - Auto-calculated distance is 2.5x the largest bounding box dimension - Camera is positioned in front of the node (+Z direction) - Camera is aimed at the center of the node's bounding box - Useful for automatically framing objects of varying sizes
| Name | Required | Description | Default |
|---|---|---|---|
| camera_label | Yes | ||
| node_label | Yes | ||
| distance | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: it explains the camera is positioned in front (+Z), aimed at the center, and calculates distance as 2.5x the largest bounding box dimension. It also details the return values (position, nodeCenter, nodeSize). This is comprehensive behavioral disclosure.
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 well-structured: summary sentence, detailed explanation, parameter list, return values, examples, and notes. Every sentence serves a purpose, and the information is front-loaded efficiently.
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?
Given the tool's simplicity (3 parameters, 2 required) and the presence of an output schema (though not shown), the description is complete. It explains behavior, parameters, return values, and provides multiple examples covering common use cases.
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 input schema lacks descriptions (0% coverage), but the description fully compensates: it explains camera_label and node_label as display labels, and distance as optional with auto-calculation formula (2.5x largest dimension). This adds critical meaning beyond the schema.
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 clearly states the tool's purpose: 'Frame camera to show a node by positioning at calculated distance.' It specifies the verb (frame), resource (camera and node), and distinguishes from sibling tools like daz_orbit_camera_around or daz_set_active_camera by focusing on framing a specific node in view.
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 provides usage context with examples and a note, indicating when to use auto-distance vs manual distance. However, it does not explicitly compare to sibling tools or state when not to use this tool, which would elevate clarity further.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_frame_shotA
Frame camera to subject using a standard cinematic shot type.
Calculates camera distance and height from the subject's bounding box, then positions and aims the camera accordingly. Genesis figures face +Z, so the camera is placed in front (positive Z direction).
Args: camera_label: Node label of the camera to reposition. subject_label: Node label of the subject to frame. shot_type: One of: - "extreme-close-up" — Eyes/mouth detail (~25 cm) - "close-up" — Face and head (~50 cm) - "medium-close-up" — Head and shoulders (~90 cm) - "medium-shot" — Waist up (~140 cm) - "medium-full" — Knees up (~200 cm) - "full-shot" — Entire body (~400 cm) - "wide-shot" — Body within environment (~700 cm)
Returns: Dict with camera, subject, shot_type, distance, camera_height, and framing description.
| Name | Required | Description | Default |
|---|---|---|---|
| camera_label | Yes | ||
| subject_label | Yes | ||
| shot_type | No | medium-shot |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the calculation of camera distance and height, placement relative to the subject, and lists all shot types with distances. It lacks details on prerequisites (e.g., subject must be a Genesis figure) or error conditions, but core behavior is well explained.
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 well-structured with sections for args and returns, front-loaded purpose, but is somewhat verbose. Each sentence adds value.
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?
Given the tool's complexity (3 parameters, no annotations, but has output schema), the description provides thorough parameter details and output format. It could mention if the camera must already exist or error handling.
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%, but the description adds comprehensive meaning for all parameters: camera_label and subject_label are clearly defined, and shot_type is explained with a full list of options and their distances.
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 clearly states the tool frames a camera to a subject using cinematic shot types, with specific verb and resource. However, it does not explicitly differentiate from sibling camera tools like daz_look_at_character or daz_orbit_camera_around.
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 is provided on when to use this tool versus alternatives. It describes what it does but not the context or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_get_animation_infoA
Get animation timeline info (current frame, range, fps).
Returns information about the current animation timeline state, including the current frame, frame range, and frames per second.
Returns:
currentFrame: current timeline position
startFrame: first frame of animation range
endFrame: last frame of animation range
fps: frames per second
totalFrames: total number of frames (endFrame - startFrame + 1)
durationSeconds: animation duration in seconds
Example: # Get timeline info info = daz_get_animation_info() print(f"Current frame: {info['currentFrame']}") print(f"Range: {info['startFrame']}-{info['endFrame']}") print(f"Duration: {info['durationSeconds']} seconds") print(f"FPS: {info['fps']}")
# Render entire animation
info = daz_get_animation_info()
for frame in range(info['startFrame'], info['endFrame'] + 1):
daz_set_frame(frame)
daz_render(output_path=f"output/frame_{frame:04d}.png")
# Check if at end of animation
info = daz_get_animation_info()
if info['currentFrame'] >= info['endFrame']:
print("At end of animation")Note: - FPS is typically 30 in DAZ Studio - Frame range is inclusive (both start and end are included) - totalFrames includes both start and end frames - Use before rendering animation to know frame count
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool's behavior as a read-only retrieval of animation timeline information. It details all return fields, including the calculation of totalFrames and durationSeconds, and notes that FPS is typically 30. No side effects or destructive actions are implied.
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 well-structured and front-loaded with a one-line summary, followed by a list of return values, practical examples, and concise notes. Every sentence adds essential information without 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?
Given that there are no parameters and an output schema exists, the description is complete. It covers all aspects of the tool's purpose, return values, and usage context, including edge cases like the inclusive frame range and typical FPS. The examples also demonstrate integration with other tools.
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 has no parameters, so the baseline is 4. The description adds value by explaining each return field in detail (e.g., totalFrames = endFrame - startFrame + 1, durationSeconds calculation) and provides examples that demonstrate usage. This goes beyond what the empty schema provides.
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 clearly states 'Get animation timeline info (current frame, range, fps)', which is a specific verb+resource. It distinguishes from sibling tools like daz_set_frame (which sets a frame) and daz_render_animation (which renders), as it focuses solely on retrieving timeline state.
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 explicitly advises to use it 'before rendering animation to know frame count' and provides examples for iterating over frames, checking the end of animation, and getting duration. It clarifies typical FPS and the inclusive nature of the frame range, giving clear context for when and how to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_get_bounding_boxA
Get the axis-aligned bounding box of a node.
Returns min/max corners, center point, and dimensions. Use this to auto-calculate camera distance, detect collisions, or anchor lights relative to a character's actual size.
Args: node_label: Display label of the node
Returns: { "node": "Genesis 9", "min": {"x": -30.0, "y": 0.0, "z": -15.0}, "max": {"x": 30.0, "y": 175.0, "z": 15.0}, "center": {"x": 0.0, "y": 87.5, "z": 0.0}, "width": 60.0, "height": 175.0, "depth": 30.0 }
| Name | Required | Description | Default |
|---|---|---|---|
| node_label | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It does not disclose behavioral traits such as idempotency, side effects, permissions, or error handling. While the description hints at read-only nature, it does not explicitly confirm safety or constraints.
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?
Description is well-structured: starts with purpose, then lists return values, provides usage context, documents the single argument, and includes a return example. Every sentence adds value 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?
Given the tool's simplicity and presence of an output schema, the description covers purpose, parameters, returns, and example. It could be improved by mentioning edge cases (e.g., node not found) or assumption that node exists.
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 only parameter, 'node_label', is explained as 'Display label of the node', adding semantic meaning beyond the schema's bare type definition. This clarifies that it expects a human-readable label, not an internal identifier.
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?
Description clearly states it gets the axis-aligned bounding box of a node, specifying exact return values (min/max, center, dimensions). This is distinct from sibling tools like daz_get_world_position or daz_check_overlap, making its purpose unambiguous.
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 specific use cases: auto-calculating camera distance, collision detection, anchoring lights. However, it does not explicitly contrast itself with alternatives or state when not to use it, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_get_content_infoA
Read metadata from a .duf content file without loading it into the scene.
Parses the JSON structure of a .duf file to extract name, type, contributor, and other available metadata fields.
Args: file_path: Absolute path to a .duf file on disk.
Returns: Dict with name, type, file_version, contributor, revision, modified, and any scene-level asset info found in the file.
Raises: ToolError: If the file does not exist, is not readable, or is not valid JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description effectively discloses the tool's behavior: it parses the JSON structure, extracts specific fields, and raises errors for missing or invalid files. It does not detail edge cases or performance, but overall is transparent.
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 concise and well-structured, with a clear opening sentence followed by additional details in a standard Args/Returns/Raises format. Slightly longer than necessary but efficient.
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 simple read tool with one parameter, the description covers all essential aspects: purpose, input requirements, output structure (dict with fields), and error conditions. Complete for its complexity.
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 only parameter 'file_path' is thoroughly described in the Args section as an absolute path to a .duf file, adding meaning beyond the schema's type string.
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 clearly states the tool reads metadata from a .duf content file without loading it into the scene, using specific verbs and a clear resource. It distinguishes from siblings like daz_load_file by emphasizing the read-only operation on unloaded files.
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 provides clear context for when to use the tool (to obtain metadata without loading the file), but does not explicitly state when not to use it or mention alternatives among siblings. This is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_get_keyframesA
Get all keyframes for a property.
Returns all keyframes currently set on a property, including frame numbers and values. Useful for inspecting existing animations or copying keyframes.
Args: node_label: Display label of the node. property_name: Property label or internal name.
Returns:
keyframes: Array of {frame, value} objects
count: Number of keyframes
Example: # Get keyframes for a property result = daz_get_keyframes("Genesis 9", "XTranslate") print(f"Found {result['count']} keyframes:") for kf in result['keyframes']: print(f" Frame {kf['frame']}: {kf['value']}")
# Copy keyframes to another property
keyframes = daz_get_keyframes("Genesis 9", "XTranslate")
for kf in keyframes['keyframes']:
daz_set_keyframe("Genesis 8", "XTranslate", kf['frame'], kf['value'])
# Check if property is animated
result = daz_get_keyframes("Genesis 9", "YRotate")
if result['count'] > 0:
print("Property is animated")Note: - Returns empty array if property has no keyframes - Keyframes are returned in frame order - Frame numbers are integers, values are floats
| Name | Required | Description | Default |
|---|---|---|---|
| node_label | Yes | ||
| property_name | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return structure (keyframes array, count), edge cases (empty array if no keyframes), ordering (frame order), and types (integers for frames, floats for values). No contradictions.
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?
Well-structured with introduction, Args, Returns, Example, and Note. Every sentence adds value. Front-loaded with purpose. 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?
Covers all essential information: purpose, parameters, return values, edge cases, and usage examples. Output schema is not included but described. Sufficient for agent to use 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 coverage is 0%, but the description's Args section adds meaningful descriptions: 'Display label of the node' and 'Property label or internal name'. Examples demonstrate correct usage with string literals.
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?
Description clearly states 'Get all keyframes for a property' with specific verb and resource. Examples and context differentiate from sibling tools like daz_set_keyframe and daz_remove_keyframe.
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 explicit contexts: 'inspecting existing animations' and 'copying keyframes'. Examples show when to use and how to combine with daz_set_keyframe. Missing explicit 'when not to use' but clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_get_nodeA
Return all numeric properties of a scene node by its label or internal name.
Useful for reading transforms (X Translate, Y Translate, Z Translate, X Rotate, Y Rotate, Z Rotate, Scale), morph dials, and any other numeric property on the node.
Args: node_label: The display label or internal name of the node (e.g. "Genesis 9"). Label is matched first; internal name is the fallback.
Returns a dict with:
name: internal node name
label: display label
type: DazScript class name (e.g. DzFigure, DzBone, DzCamera)
properties: mapping of property label → current numeric value
| Name | Required | Description | Default |
|---|---|---|---|
| node_label | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Discloses matching priority (label first, internal name fallback) and return dict structure. Clearly implies read-only behavior, though not explicitly stated.
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?
Description is well-structured but slightly verbose (includes full Args/Returns sections). However, all sentences are useful and front-loaded with purpose.
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?
Covers parameter, matching behavior, and return format. Given output schema exists, description provides sufficient context for AI to use tool 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 coverage is 0%, but description explains node_label thoroughly: display label or internal name with example and matching priority. Adds significant value beyond schema.
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?
Description clearly states the tool returns all numeric properties of a scene node by label or internal name, with examples (transforms, morph dials). It distinguishes from siblings by focusing on numeric property retrieval.
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 says 'useful for reading transforms... and any other numeric property' implying when to use, but lacks explicit when-not-to-use or comparison with sibling tools like daz_inspect_properties.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_get_node_hierarchyA
Get complete hierarchy tree for a node with all descendants.
Returns the full hierarchical structure of a node, including all children, grandchildren, etc. Useful for understanding skeleton structure, bone relationships, and complex scene hierarchies.
Args: node_label: Display label or internal name of the root node. max_depth: Maximum recursion depth (default 10, 0 = unlimited). Use to limit deep hierarchies (e.g., Genesis 9 skeleton has 100+ bones).
Returns:
node: Root node label
hierarchy: Nested structure with:
label: Node display label
name: Internal name
type: DazScript class name
children: List of child hierarchies (recursive)
totalDescendants: Total number of descendants
Example: # Get skeleton hierarchy with depth limit result = daz_get_node_hierarchy("Genesis 9", max_depth=3) # Returns nested structure: hip -> abdomen -> chest -> ...
# Get full hierarchy (warning: can be large)
result = daz_get_node_hierarchy("Genesis 9", max_depth=0)
# Returns complete skeleton with all 100+ bones
# Get prop hierarchy
result = daz_get_node_hierarchy("Sword", max_depth=5)| Name | Required | Description | Default |
|---|---|---|---|
| node_label | Yes | ||
| max_depth | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the return format (nested structure with children recursively), includes totalDescendants count, and warns about large output for max_depth=0. It does not mention side effects or performance, but for a read tool this is adequate.
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 well-structured with sections for Args, Returns, and Examples, and is front-loaded with the main purpose. Every sentence adds value, though it could be slightly more concise without losing clarity.
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?
Given 2 parameters, an output schema, and the description covering return structure, usage tips, and multiple examples, the tool definition is complete for its purpose. It addresses typical use cases and potential pitfalls.
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?
Despite 0% schema description coverage, the description fully explains both parameters: node_label is the display label or internal name, max_depth has a default of 10 and effect (0=unlimited). It provides practical tips like limiting depth for deep hierarchies, adding significant value beyond the schema.
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 clearly states the tool gets the complete hierarchy tree for a node with all descendants, specifying the verb 'get' and the resource 'hierarchy tree'. It distinguishes itself from sibling tools like daz_get_node or daz_list_children by returning the full nested structure recursively.
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 provides context on when to use the tool (e.g., understanding skeleton structure, bone relationships) and includes examples with different use cases (depth-limited, full hierarchy). It warns about large outputs for deep hierarchies but does not explicitly exclude alternatives, though the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_get_parentA
Get parent node of a node.
Returns the immediate parent of a node, or null if the node is a root node (no parent). Useful for traversing hierarchy upward.
Args: node_label: Display label or internal name of the child node.
Returns:
node: Child node label
parent: Parent node object with label, name, type, or null if no parent
Example: # Get parent of a bone result = daz_get_parent("lHand") # Returns: {"parent": {"label": "lForearmBend", "name": "lForearmBend", ...}}
# Check if node is root (has no parent)
result = daz_get_parent("Genesis 9")
# result["parent"] == null
# Traverse hierarchy upward
node = "lIndex3"
while True:
result = daz_get_parent(node)
if not result["parent"]:
break
print(f"Parent of {node}: {result['parent']['label']}")
node = result["parent"]["label"]| Name | Required | Description | Default |
|---|---|---|---|
| node_label | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It specifies return null for root nodes and provides example outputs, but lacks details on permissions, side effects, or limitations.
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?
Description is fairly long with detailed Args/Returns and examples, but well-structured and front-loaded with purpose. Could be slightly more concise but value justifies 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?
Given the simple tool with output schema, description covers return format, edge case (null for root), and usage examples. No major 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 single parameter node_label has 0% schema description coverage; the description adds meaning by explaining it can be a display label or internal name, going beyond the schema.
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 clearly states 'Get parent node of a node' and distinguishes from siblings like daz_get_node_hierarchy and daz_list_children by focusing on immediate parent retrieval.
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 provides clear usage context ('useful for traversing hierarchy upward') and concrete examples, but does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_get_property_metadataA
Get detailed metadata for a single named property on a node.
Accepts either the display label (e.g. "Luminous Flux (Lumen)") or the internal name (e.g. "Flux"). Use this to validate a value is within min/max range before setting it.
Args: node_label: Display label of the node property_name: Property label or internal name
Returns: { "label": "Luminous Flux (Lumen)", "name": "Flux", "type": "DzFloatProperty", "current_value": 1500.0, "default_value": 1500.0, "min": 0.0, "max": 100000.0, "is_animatable": true, "path": "Light/Photometrics", "node": "Spotlight 1" }
| Name | Required | Description | Default |
|---|---|---|---|
| node_label | Yes | ||
| property_name | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: accepts label or internal name, returns a detailed JSON object with constraints, and implies no destructive side effects.
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 concise, front-loaded with purpose, and includes a helpful example JSON response without unnecessary fluff.
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?
Given the moderate complexity and presence of an output schema (implicitly shown), the description provides all necessary context for a getter 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%, but the description explains the two parameters (node_label, property_name) with examples, adding meaningful guidance beyond the bare schema.
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 clearly states it retrieves detailed metadata for a single named property on a node, distinguishing it from sibling tools like daz_get_node or daz_inspect_properties.
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 explicitly recommends using this tool to validate a value within min/max range before setting, providing clear context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_get_render_settingsA
Get current render settings and configuration.
Returns information about the current render configuration, including render target, output path, aspect ratio, and render camera.
Returns:
renderToFile: true if rendering to file, false if to viewport
outputPath: current output file path (or null)
currentCamera: label of current render camera (or null for viewport camera)
aspectRatio: aspect ratio value
aspectWidth: aspect width component
aspectHeight: aspect height component
Example: # Check render settings settings = daz_get_render_settings() print(f"Render camera: {settings['currentCamera']}") print(f"Output: {settings['outputPath']}") print(f"Aspect: {settings['aspectWidth']}x{settings['aspectHeight']}")
# Verify render is configured correctly before batch render
settings = daz_get_render_settings()
if not settings['renderToFile']:
print("Warning: Render is configured for viewport, not file output")Note: - Aspect ratio determines render dimensions relative to each other - Pixel dimensions cannot be set reliably via DazScript - currentCamera may be null if using active viewport camera
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses the return format, lists all fields, and notes important behaviors (e.g., pixel dimensions cannot be set reliably, currentCamera may be null). This is thorough, though it could mention that it is a non-destructive read operation, which is implicit.
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 concise and well-structured: an overview sentence, a 'Returns' bullet list, an example, and a 'Note' section. Every section adds value without redundancy. It is front-loaded with the purpose.
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?
Given that the tool has no parameters and an output schema exists, the description fully explains what the tool does, what it returns, and provides usage context. Limitations are noted, making it complete for an agent to invoke.
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 has zero parameters, so schema coverage is trivially 100%. The description adds value by detailing the returned fields, which is beyond the input schema's scope. Baseline for no parameters is 4, and the description meets that.
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 clearly states 'Get current render settings and configuration.' It uses a specific verb ('Get') and resource ('render settings'), and the returns section lists exactly what is retrieved. There is no ambiguity, and it distinguishes itself from sibling tools (e.g., daz_set_render_quality) by being a read-only query.
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 does not explicitly state when to use this tool versus alternatives. However, the example provides a practical usage scenario (checking settings before batch render), which implies its role. There is no mention of when not to use it or comparison to similar tools like daz_get_scene_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_get_request_resultA
Get the result of a completed async request.
Args: request_id: Request ID returned by an async submission tool. wait: If True (default), block until the request finishes (up to timeout). If False, return immediately with current status even if not done. timeout_seconds: Max seconds to wait when wait=True (default 3600 = 1 hour).
Returns when complete: { "request_id": "script-XXXXXXXX", "status": "completed", "success": true, "result": {...}, # same as sync tool result "output": [...], # captured DazScript print() output "error": null, "duration_ms": 267000, "completed_at": "2026-04-08T..." }
Raises ToolError if the request failed.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | ||
| wait | No | ||
| timeout_seconds | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fully covers blocking behavior, non-blocking mode, timeout, error raising, and the full return structure. Highly transparent.
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?
Well-structured with Args and Returns sections, front-loaded purpose. Every sentence is informative without 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?
Covers parameters, behavior, return format, and error handling. The included output schema in the description compensates for any lack of schema coverage. Complete for an async result 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?
Despite 0% schema description coverage, the description thoroughly explains each parameter's purpose and behavior (request_id source, wait blocking vs polling, timeout max wait). Adds significant value beyond schema.
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?
Clearly states the tool retrieves the result of a completed async request, with a specific verb and resource. Distinguishes from siblings like daz_get_request_status and daz_cancel_request.
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?
Describes the async request context and parameters wait/timeout, implying usage after async submission. Lacks explicit when-not or alternatives but is clear enough for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_get_request_statusA
Get the current status of an async request (non-blocking, always fast).
Safe to call frequently — reads directly from the server's in-memory map without executing any DazScript.
Args: request_id: Request ID returned by an async submission tool.
Returns: { "request_id": "script-XXXXXXXX", "status": "running", # queued | running | completed | failed | cancelled "progress": 0.0, # 0.0 while running (DAZ single-frame renders have no # mid-frame progress), 1.0 when complete "elapsed_ms": 45000, # present while running "queue_position": 2 # present while queued }
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully covers behavioral traits: it is non-blocking, fast, reads from in-memory map without executing DazScript, and is safe to call frequently. It also explains the return format and value ranges (e.g., progress 0.0 while running, 1.0 when complete). No contradictions.
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 concise with a clear title line, then body, and structured Args/Returns sections. Every sentence adds unique value: purpose, safety, implementation detail, and full return documentation. No redundancy or fluff.
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?
Given the simple one-parameter tool with an output schema described in the description, the coverage is complete. It explains all possible statuses, progress behavior, and conditional fields. The context signals show 0% schema description coverage, but the description compensates fully.
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 input schema only defines request_id as required string with 0% description coverage. The description adds context: 'request_id: Request ID returned by an async submission tool.' This source guidance provides meaning beyond the schema, though it does not specify format constraints.
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 clearly states 'Get the current status of an async request' and emphasizes it is 'non-blocking, always fast'. This distinguishes it from siblings like daz_get_request_result (which retrieves final results) and daz_cancel_request (which modifies state). The verb+resource is specific and unambiguous.
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 says 'Safe to call frequently' and implies use for polling status. It does not explicitly exclude use after completion or compare to alternatives, but the purpose and return structure (including progress, queue_position, elapsed_ms) clearly indicate it is for monitoring ongoing requests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_get_scene_layoutA
Get a spatial map of all scene nodes with positions and bounding boxes.
Provides a bird's-eye view of where everything is positioned in the scene, useful for reasoning about character spacing, prop placement, and camera coverage.
Args: include_types: List of node type strings to include. Defaults to all types. Valid values: "figures", "cameras", "lights", "props".
Returns: Dict with nodes (list of {label, type, position, bounds?}) and count.
Example: daz_get_scene_layout() # everything daz_get_scene_layout(["figures", "cameras"]) # characters + cameras only daz_get_scene_layout(["lights"]) # just lights with flux values
| Name | Required | Description | Default |
|---|---|---|---|
| include_types | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only query through the verb 'Get' and the nature of the output, but it does not explicitly state that the tool is non-destructive or safe, nor does it mention any side effects or permissions needed.
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 well-structured with a one-line summary, a contextual paragraph, and clearly labeled Args, Returns, and Example sections. Every sentence adds value, and there is no redundancy or extraneous content.
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?
Given the tool's moderate complexity and the presence of an output schema, the description covers the purpose, parameter, return structure, and an example. It lacks only error handling or performance notes, but for a simple query tool, it is sufficiently complete.
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 schema coverage is 0%, meaning the schema provides no description for parameters. The description compensates fully with an Args section listing valid values ('figures', 'cameras', 'lights', 'props') and explaining the default behavior, adding significant meaning beyond the raw schema.
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 clearly states the tool 'Get a spatial map of all scene nodes with positions and bounding boxes.' It uses a specific verb and resource, and the mention of 'bird's-eye view' distinguishes it from siblings like daz_get_node or daz_get_world_position, which focus on individual nodes.
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 provides context ('useful for reasoning about character spacing, prop placement, and camera coverage') but does not explicitly indicate when to use this tool versus alternatives like daz_get_node or daz_get_bounding_box. No 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_get_spatial_relationshipA
Get the spatial relationship between two nodes in natural language.
Returns direction (front, back, left, right, above, below), angles, distance, and whether their bounding boxes overlap.
Horizontal angle uses DAZ coordinate system: 0°=front(+Z for Genesis figures), 90°=right(+X), 180°=back(-Z), -90°=left(-X).
Args: node1_label: The reference node (e.g. "Genesis 9") node2_label: The target node to describe relative to node1 (e.g. "Camera 1")
Returns: { "node1": "Genesis 9", "node2": "Camera 1", "distance": 250.5, "direction": "front", "angle_horizontal": 5.0, "angle_vertical": 12.0, "relative_position": "Camera 1 is front above of Genesis 9 (250 cm away)", "overlapping": false }
| Name | Required | Description | Default |
|---|---|---|---|
| node1_label | Yes | ||
| node2_label | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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 explains the coordinate system, angle conventions, and output structure in detail, providing comprehensive behavioral transparency.
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 well-structured with a clear title, explanation of angle system, args, and returns. It is detailed but not verbose, with every sentence adding value.
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?
Given the output schema exists, description does not need to explain return values, but it provides an example. The tool is simple with two required string parameters, and the description covers them thoroughly.
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 description adds all parameter meaning. It explains that node1_label is the reference node and node2_label is the target relative to node1, which is essential for correct invocation.
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 clearly states the tool gets spatial relationship between two nodes in natural language, listing specific outputs (direction, angles, distance, overlapping). It distinguishes from siblings like daz_calculate_distance and daz_check_overlap by providing a combined relationship description.
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 when to use it (to get spatial relationship in natural language) but does not explicitly state when not to use it or provide alternatives. However, the sibling list implies other tools for specific aspects, so usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_get_world_positionA
Get world-space position, local position, rotation, and scale of a node.
Useful for understanding where nodes are in 3D space before making relative positioning decisions.
Args: node_label: Display label of the node (e.g. "Genesis 9", "Camera 1")
Returns: { "node": "Genesis 9", "world_position": {"x": 0.0, "y": 0.0, "z": 0.0}, "local_position": {"x": 0.0, "y": 0.0, "z": 0.0}, "rotation": {"x": 0.0, "y": 0.0, "z": 0.0}, "scale": {"x": 1.0, "y": 1.0, "z": 1.0} }
| Name | Required | Description | Default |
|---|---|---|---|
| node_label | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, but the description transparently lists the returned data (position, rotation, scale) and input (node_label), implying it is a read-only query without side effects.
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 concise (two sentences plus a clear Args and Returns block), front-loaded with the purpose, and every part adds value without 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?
Given the simplicity (one parameter, no nested objects), the description fully explains input and output, including an example of the return structure, making it complete for the tool's scope.
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 schema only defines 'node_label' as a string with no description, but the tool description adds explicit meaning: 'Display label of the node (e.g. "Genesis 9", "Camera 1")', compensating for 0% schema coverage.
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 clearly states the verb 'Get' and the resource 'world-space position, local position, rotation, and scale of a node', distinguishing it from sibling tools that modify or apply transformations.
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 mentions it is 'useful before making relative positioning decisions', which provides context, but does not give explicit when-not-to-use or alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_inspect_propertiesA
List all properties on a node with their types, values, and constraints.
Use this to discover what properties are available on a node before using daz_set_property. Much more reliable than guessing property names.
Args: node_label: Display label of the node property_type: Filter type — one of: "all" - all properties "numeric" - all numeric (float/bool) properties "transform" - XTranslate/YTranslate/ZTranslate/XRotate/YRotate/ZRotate/Scale "morph" - numeric properties that are not transforms "bool" - boolean properties only "string" - string properties only
Returns: { "node": "Spotlight 1", "properties": [ { "label": "Luminous Flux (Lumen)", "name": "Flux", "type": "DzFloatProperty", "value": 1500.0, "min": 0.0, "max": 100000.0, "path": "Light/Photometrics", "is_animatable": true } ], "count": 45 }
| Name | Required | Description | Default |
|---|---|---|---|
| node_label | Yes | ||
| property_type | No | all |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description explains the tool returns a JSON with property details, implying a read-only operation. However, it does not mention side effects, permissions, or error behavior. Adequate given the simple nature of the 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?
Description is concise, well-structured with a summary paragraph, Args section, and Returns example. Every part is necessary and front-loaded with purpose.
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?
Given two simple parameters and an output schema in the description, the tool is well-documented. Could mention error scenarios, but the provided example and parameter details cover typical usage.
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%, but the description fully explains both parameters. It lists possible values for property_type with defaults and details for node_label. This adds significant meaning beyond the bare schema.
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?
Description clearly states 'List all properties on a node with their types, values, and constraints.', providing specific verb and resource. It distinguishes from siblings like daz_set_property and daz_get_property_metadata.
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 says to use this tool before daz_set_property and describes it as 'more reliable than guessing property names.' Provides clear context but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_interactive_poseA
Coordinate two characters for interactive poses.
Applies complementary poses to two characters for common interaction scenarios. Handles both positioning and pose application.
Args: char1_label: Display label of first character. char2_label: Display label of second character. interaction_type: Type of interaction. Options: - "face-each-other": Position and rotate to face each other (default) - "hug": Both characters hug with arms around each other - "shoulder-arm": Char1 puts arm around char2's shoulders - "handshake": Both extend right hands for handshake distance: Optional spacing between characters in cm (default varies by type: face=100, hug=40, shoulder-arm=30, handshake=60).
Returns:
success: true on success
char1: first character label
char2: second character label
interactionType: the interaction type used
applied: list of pose components that were applied
Example: # Position characters facing each other at conversation distance daz_interactive_pose("Alice", "Bob", "face-each-other", distance=120)
# Create tight hug
daz_interactive_pose("Alice", "Bob", "hug", distance=30)
# Bob puts arm around Alice's shoulders
daz_interactive_pose("Bob", "Alice", "shoulder-arm")Note: These are simplified interaction poses. For natural-looking results, you may need to fine-tune positions and rotations using daz_set_property or load artist-created pose presets.
| Name | Required | Description | Default |
|---|---|---|---|
| char1_label | Yes | ||
| char2_label | Yes | ||
| interaction_type | No | face-each-other | |
| distance | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of disclosing behavior. It states that the tool applies complementary poses and positioning, returns success, labels, and applied pose components. It also mentions that distances vary by interaction type. However, it does not explicitly state whether poses override existing ones, though the note implies they are simplified and may need adjustment.
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 well-structured with a clear purpose statement, parameter details, returns, examples, and a note. It is somewhat lengthy but every sentence adds value. Minor redundancy in the returns section could be trimmed, but overall it is effective.
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?
Given the presence of an output schema, the description goes beyond by including return values, examples, and caveats. It covers the tool's core functionality, parameters, and limitations, providing all necessary information for an AI agent to use it 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?
The input schema has 0% description coverage, but the tool description compensates completely by explaining each parameter: char1_label and char2_label as display labels, interaction_type with a list of options and defaults, and distance with type-specific default values. Examples further clarify usage.
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 clearly states the tool coordinates two characters for interactive poses, specifying that it handles both positioning and pose application. It distinguishes itself from siblings by focusing on paired interactions, with no other sibling tool having a similar function.
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 provides explicit guidance on when to use the tool and when alternatives are needed. It lists interaction types with defaults, includes detailed examples, and notes that for natural-looking results, fine-tuning with daz_set_property or artist-created pose presets may be required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_list_categoriesA
List content library category subdirectories under a parent path.
Searches across all configured DAZ content directories and deduplicates by name.
Args: parent_path: Relative path within content directories to list (e.g. "People/Genesis 9"). Leave empty to list top-level categories.
Returns: Dict with parent, categories (list of {name, path, duf_count}), and count.
Example: daz_list_categories() # top-level: People, Props, Environments... daz_list_categories("People/Genesis 9") # sub-folders: Characters, Clothing, Hair...
| Name | Required | Description | Default |
|---|---|---|---|
| parent_path | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses that the tool searches across all configured DAZ content directories and deduplicates by name, which is valuable behavioral context beyond the simple listing action.
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 concise and well-structured, with a brief intro, clear Args/Returns sections, and relevant examples. Every sentence adds value without 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?
Given the single parameter (well-documented), the presence of an output schema (so return format is handled), and the simple nature of the tool, the description is complete. It includes examples and edge cases.
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?
With 0% schema description coverage, the description adds essential meaning: it explains the 'parent_path' parameter as a relative path and includes the default behavior of listing top-level categories when empty. This fully compensates for the schema's lack of 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 clearly states the tool lists content library category subdirectories under a parent path, distinguishing it from siblings like 'daz_browse_category' by specifying it searches all configured directories and deduplicates by name. Examples further clarify the scope.
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 implies usage by showing examples of parent_path values and results, but does not explicitly mention when to avoid using it or suggest alternative tools like 'daz_browse_category'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_list_checkpointsA
List all saved scene state checkpoints in the current session.
Returns: Dict with checkpoints (list of {name, node_count, saved_at}) and count.
Notes: Checkpoints are in-process memory; they are cleared when the server restarts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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 that checkpoints are in-process memory and cleared on server restart, but does not explicitly state read-only behavior or other traits like performance impact.
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 three sentences, concise and front-loaded: purpose, return format, and a key behavioral note. Every sentence adds value without 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?
Given the tool's simplicity (no parameters, clear return), the description adequately covers purpose, output format, and volatility. It could mention the relationship to daz_save_scene_state but is largely complete.
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 input schema has no parameters, so schema coverage is 100%. The description adds no parameter information because none are needed, meeting the baseline of 3 for high coverage.
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 clearly states the verb 'List' and resource 'scene state checkpoints' with scope 'current session'. It distinguishes from sibling tools like daz_save_scene_state and daz_restore_scene_state.
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 implies usage for viewing checkpoints but lacks explicit guidance on when to use this tool versus alternatives (e.g., saving or restoring). No exclusions or contextual cues are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_list_childrenA
List direct children of a node.
Returns only the immediate children (not grandchildren). Useful for exploring hierarchy one level at a time or checking if a node has children.
Args: node_label: Display label or internal name of the parent node.
Returns:
node: Parent node label
children: List of child objects with:
label: Child display label
name: Child internal name
type: DazScript class name
count: Number of children
Example: # List children of Genesis 9 root result = daz_list_children("Genesis 9") # Returns: [{"label": "hip", "name": "hip", "type": "DzBone"}]
# Check if node has children
result = daz_list_children("Camera 1")
# result["count"] == 0 means no children
# List bones under hip
result = daz_list_children("hip")
# Returns: pelvis, lThighBend, rThighBend| Name | Required | Description | Default |
|---|---|---|---|
| node_label | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns only direct children and provides detailed return structure including count and example outputs. With no annotations, it carries the full burden well. However, it does not mention error behavior for invalid node labels.
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 concise and well-structured: purpose statement, usage hint, parameter definition, return structure, and three examples. Every sentence adds value, and it is front-loaded with the core action.
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?
Given the tool's simplicity (one parameter, clear output), the description covers all necessary information: what it does, when to use it, how to specify the parameter, what the output looks like, and practical examples. No annotations are needed for this context.
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 input schema has no description for the parameter, but the tool description explains 'node_label: Display label or internal name of the parent node.' This adds critical meaning beyond the schema's mere string type, fully compensating for the 0% schema coverage.
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 clearly states 'List direct children of a node' and specifies 'Returns only the immediate children (not grandchildren)'. This distinguishes it from sibling tools like daz_get_node_hierarchy which returns full hierarchy, making purpose specific and unambiguous.
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 provides context: 'Useful for exploring hierarchy one level at a time or checking if a node has children.' This implies when to use it. However, it does not explicitly mention when not to use it or name alternative tools, 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.
daz_list_morphsA
List all morphs (numeric properties) on a node.
Returns all numeric properties on a node, which includes morphs (body shapes, facial expressions), transforms, and other numeric dials. Useful for discovering what morphs are available on a figure.
Args: node_label: Display label or internal name of the node (e.g., "Genesis 9"). include_zero: If True, return all morphs including those set to 0. If False (default), only return morphs with non-zero values (currently active morphs).
Returns:
morphs: List of morph objects with:
label: Display label (e.g., "Head Size")
name: Internal name (e.g., "HeadSize")
value: Current numeric value
path: Property path for organization (e.g., "Morphs/Head")
count: Number of morphs returned
nodeLabel: Confirmed node label
Example: # List only active morphs on Genesis 9 result = daz_list_morphs("Genesis 9", include_zero=False) # result["morphs"] = [ # {"label": "Height", "name": "Height", "value": 1.05, "path": "Morphs/Body"}, # {"label": "Head Size", "name": "HeadSize", "value": 0.9, "path": "Morphs/Head"} # ]
# List all available morphs (including zero values)
result = daz_list_morphs("Genesis 9", include_zero=True)
# result["count"] might be 500+ morphs| Name | Required | Description | Default |
|---|---|---|---|
| node_label | Yes | ||
| include_zero | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It comprehensively discloses behavior: returns all numeric properties, includes morphs/transforms, details return structure with example, and explains the include_zero parameter's impact on returned morphs.
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?
Description is well-structured with Args, Returns, and Example sections. It is informative but slightly verbose; could be marginally more concise. However, every sentence adds value.
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?
Given the tool's simplicity (2 params, no nested objects), the description is complete. It includes parameter explanations, return structure, and a realistic example. The output schema exists but description's Returns section covers it adequately.
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 description provides full semantics. It explains node_label as display label or internal name with example, and include_zero with clear True/False behavior. This adds complete meaning beyond the raw schema.
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 clearly states the tool lists all numeric properties (morphs, transforms) on a node, with precise verb 'list' and resource 'numeric properties'. It distinguishes from sibling tool daz_search_morphs by indicating this is for discovery of all available morphs, not searching.
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 notes usefulness 'for discovering what morphs are available on a figure' and explains the include_zero parameter's effect. However, it does not explicitly state when not to use or provide alternative sibling tools for specific morph search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_list_requestsA
List all tracked async requests and their current statuses.
Args: status_filter: Optional filter — one of "queued", "running", "completed", "failed", "cancelled". Returns all if omitted.
Returns: { "requests": [ {"request_id": "...", "status": "...", "progress": 0.0, "submitted_at": "..."}, ... ], "total": 5, "queued": 2, "running": 1, "completed": 2, "failed": 0, "cancelled": 0 }
| Name | Required | Description | Default |
|---|---|---|---|
| status_filter | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: it is a read-only listing operation with no destructive side effects. The return structure with progress and counts is detailed, providing full transparency. No contradictions.
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 well-structured with a clear first sentence stating purpose, followed by parameter details and return format. It is concise and front-loaded, though the Python docstring format adds slight verbosity.
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?
Given the tool's simplicity (one optional parameter, no required inputs), the description is complete. It covers the operation, parameter semantics, and return data. The presence of an output schema in the description further aids understanding.
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?
Despite 0% schema coverage, the description clarifies the single parameter 'status_filter' as optional with specific string values ('queued', 'running', etc.) and default null meaning all. The return object is also documented. Schema does not list enums, so description is essential.
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 'List all tracked async requests and their current statuses' uses a specific verb ('list') and resource ('all tracked async requests'), clearly distinguishing from sibling tools like daz_get_request_status (single request) and daz_cancel_request (mutation). The optional filter is also described.
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 when to use the optional status_filter and the default behavior when omitted. However, it does not explicitly state when NOT to use this tool (e.g., for a single request status) or mention alternatives, though siblings imply them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_load_camera_presetA
Restore camera position and rotation from preset data.
Applies saved preset data (from daz_save_camera_preset()) to a camera, restoring its position, rotation, and scale.
Args: camera_label: Display label of the camera to modify. preset: Preset dictionary from daz_save_camera_preset(), containing: - transforms: Dictionary of property names to values
Returns:
success: true on success
camera: camera label
applied: list of property names that were applied
Example: # Load previously saved preset with open("my_camera_preset.json") as f: preset = json.load(f)
result = daz_load_camera_preset("Camera 1", preset["preset"])
print(f"Applied properties: {result['applied']}")
# Apply same preset to multiple cameras
cameras = ["Camera 1", "Camera 2", "Camera 3"]
for cam in cameras:
daz_load_camera_preset(cam, preset["preset"])Note: - Preset can be applied to any camera, not just the original - Only properties present in the preset are modified - Useful for saving/loading camera positions across sessions - Can be used to synchronize multiple cameras
| Name | Required | Description | Default |
|---|---|---|---|
| camera_label | Yes | ||
| preset | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description covers what the tool does (restore position, rotation, scale), what is modified (only properties present in preset), return values, and application to any camera. This is comprehensive.
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?
Well-structured with sections (Args, Returns, Example, Note). Every sentence adds value, though slightly lengthy for a simple function. Front-loaded with purpose.
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?
Given two parameters, no annotations, and presence of output schema, the description covers functionality, parameters, return, and examples. Lacks error handling details but is sufficient for this 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?
With 0% schema coverage, the description adds crucial meaning: 'camera_label' is the display label, 'preset' is a dictionary containing transforms. This fully compensates for the sparse schema.
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 clearly states 'Restore camera position and rotation from preset data' with a specific verb and resource. It distinguishes from siblings like daz_save_camera_preset by focusing on loading/applying presets.
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 clear context and examples, including applying to multiple cameras and reloading across sessions. However, it does not explicitly exclude scenarios or compare to daz_apply_camera_angle, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_load_fileA
Load a DAZ Studio file into the current scene.
Args: file_path: Absolute path to the file on the DAZ Studio machine (.duf, .daz, .obj, .fbx, etc.). merge: If True (default), merge the file into the existing scene. If False, replace the current scene entirely.
Returns:
success: true on success
file: the path that was loaded
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| merge | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses merge/replace behavior and return values, but omits details on errors, async behavior, or side effects beyond scene replacement.
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?
Description is concise, front-loaded, and uses clear docstring format with no redundant information.
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?
Covers both parameters and return value adequately; for a simple file-load tool, it is fairly complete, though it could mention error handling or file existence checks.
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 description clarifies file_path as absolute path with format examples, and explains merge default and behavior; adds significant meaning beyond the raw schema.
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?
Description uses specific verb 'Load' and resource 'DAZ Studio file'; clearly distinguishes from sibling tools like daz_execute_file or daz_apply_lighting_preset.
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?
Specifies file path and merge behavior, but lacks explicit guidance on when to use this tool versus alternatives (e.g., daz_execute_file). Usage is implied but not explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_look_at_characterA
Make one character look at another character's face.
Automatically finds the target character's head position and rotates the source character to look at it using cascading body rotations.
Args: source_label: Display label of the character who will look. target_label: Display label of the character to look at. mode: How much body to involve. Options: - "eyes": Only rotate eyes - "head": Eyes + head rotation (default) - "neck": Eyes + head + neck - "torso": Eyes + head + neck + chest - "full": Complete body rotation including hip
Returns:
success: true on success
source: source character label
target: target character label
mode: the mode used
targetPosition: {x, y, z} world coordinates of target's head
rotatedBones: list of bone labels that were rotated
Example: # Alice looks at Bob with head turn daz_look_at_character("Alice", "Bob", mode="head")
# Bob turns his whole body to face Alice
daz_look_at_character("Bob", "Alice", mode="full")| Name | Required | Description | Default |
|---|---|---|---|
| source_label | Yes | ||
| target_label | Yes | ||
| mode | No | head |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must convey behavioral details. It discloses that the tool automatically finds the target's head position and rotates the source using 'cascading body rotations' with five modes. It also lists the returned fields, including rotatedBones. However, it does not mention whether the rotation is animated or permanent, prerequisites like character naming, or error states if labels are missing.
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 concise and well-structured: a one-line summary, followed by parameter explanations, return values, and two clear examples. Every sentence adds value without redundancy. It follows a logical flow that is easy for an AI agent to parse.
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?
Given the tool's moderate complexity (three parameters, cascading rotations) and the presence of an output schema, the description covers the core aspects: purpose, parameters, returns, and examples. It is nearly complete but lacks details on prerequisites (e.g., characters must be in scene, labels must be unique) and potential errors. These are minor gaps given the output schema and examples.
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 input schema provides only names and types with no descriptions (0% coverage). The description compensates fully: it explains source_label and target_label as display labels, and mode with five explicit options and their defaults. This adds essential meaning beyond the raw schema, enabling correct parameter selection.
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 starts with a specific verb ('Make one character look at another character's face'), clearly indicating the action and the resource. It distinguishes from the sibling tool 'daz_look_at_point' by specifying 'character's face' rather than a point. This unambiguous purpose allows an AI agent to select the correct tool for character-to-character gaze.
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 implicitly tells when to use this tool: to make one character look at another's face. The examples show proper usage with different modes. However, it does not explicitly mention when not to use it (e.g., for looking at arbitrary 3D points) or compare with 'daz_look_at_point'. The sibling tool name gives a strong hint, but the description misses explicit guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_look_at_pointA
Make character look at a world-space point with configurable body involvement.
This helper uses cascading rotations from eyes through the body to create natural-looking character attention. Different modes control how much of the body participates in the look direction.
Args: character_label: Display label or internal name of the character figure. target_x: World X coordinate (cm) to look at. target_y: World Y coordinate (cm) to look at. target_z: World Z coordinate (cm) to look at. mode: How much body to involve in the look. Options: - "eyes": Only rotate eyes - "head": Eyes + head rotation (default) - "neck": Eyes + head + neck - "torso": Eyes + head + neck + chest - "full": Complete body rotation including hip
Returns:
success: true on success
character: character label
mode: the mode used
rotatedBones: list of bone labels that were rotated
Example: # Character looks at point in front of them at eye level daz_look_at_point("Genesis 9", 0, 160, 200, mode="head")
# Full body turn to look behind
daz_look_at_point("Genesis 9", 0, 140, -150, mode="full")| Name | Required | Description | Default |
|---|---|---|---|
| character_label | Yes | ||
| target_x | Yes | ||
| target_y | Yes | ||
| target_z | Yes | ||
| mode | No | head |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It explains cascading rotations and mode options, but it does not mention whether the look is additive or replaces existing poses, if it is animated, or if it requires a character to be selected. More detail on side effects would improve transparency.
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 well-structured: brief intro, args table, return values, and two examples. Every sentence adds value, and the most critical information (purpose, modes, example) is front-loaded. No redundant content.
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?
The description covers all necessary aspects: what the tool does, how it works (cascading rotations), all parameters with options, expected return values, and usage examples. Given the tool's moderate complexity (5 params, no nested objects), this is complete. An output schema exists, and the description complements it.
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 schema has 0% description coverage, so the description carries full burden. It provides thorough parameter explanations: labels and units (cm) for coordinates, and a detailed list of mode options with default. This goes well beyond the bare schema.
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 clearly states the tool's purpose: 'Make character look at a world-space point with configurable body involvement.' It specifies the verb ('look at'), resource ('world-space point'), and scope ('configurable body involvement'). It distinguishes from sibling 'daz_look_at_character' by focusing on a point, not another character.
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 provides examples but no explicit guidance on when to use this tool versus alternatives like 'daz_look_at_character' or 'daz_interactive_pose'. Usage is implied through examples, but no when-not or alternative comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_orbit_camera_aroundA
Position camera orbiting around a target node at specified angle and distance.
Uses spherical coordinates to position the camera at a specific angle around a target object. The camera is automatically aimed at the target after positioning.
Args: camera_label: Display label of the camera to position. target_label: Display label of the target node to orbit around. distance: Distance from target in centimeters (default: 200). angle_horizontal: Horizontal angle in degrees, 0=front/+Z, 90=right/+X (default: 45). angle_vertical: Vertical angle in degrees, positive=above, negative=below (default: 15).
Returns:
success: true on success
camera: camera label
target: target node label
position: camera world position {x, y, z}
targetPosition: target world position {x, y, z}
Example: # Position camera at 45° to the right, slightly above, 200cm away daz_orbit_camera_around("Camera 1", "Genesis 9", distance=200, angle_horizontal=45, angle_vertical=15)
# Side view from the left
daz_orbit_camera_around("Camera 1", "Genesis 9", distance=150,
angle_horizontal=-90, angle_vertical=0)
# Bird's eye view
daz_orbit_camera_around("Camera 1", "Genesis 9", distance=300,
angle_horizontal=0, angle_vertical=60)
# Dramatic low angle
daz_orbit_camera_around("Camera 1", "Genesis 9", distance=180,
angle_horizontal=25, angle_vertical=-20)Note: Angles use spherical coordinates: - Horizontal: 0°=front(+Z), 90°=right(+X), 180°=back(-Z), -90°=left(-X) - Vertical: positive=above horizon, negative=below
Camera is automatically aimed at the target's world position after positioning.| Name | Required | Description | Default |
|---|---|---|---|
| camera_label | Yes | ||
| target_label | Yes | ||
| distance | No | ||
| angle_horizontal | No | ||
| angle_vertical | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the camera is automatically aimed at the target after positioning, explains the spherical coordinate system, and provides defaults. It does not mention side effects like overwriting camera orientation or requiring camera label existence, but covers key behavioral aspects.
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 well-structured with a summary, args, returns, examples, and notes. It is front-loaded with purpose. However, the four examples are somewhat verbose; two would suffice, but they are still helpful.
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?
Given the tool's complexity (5 parameters, spherical coordinates, automatic aiming), the description is complete. It explains parameter behavior, coordinate system, return values, and provides usage examples. No output schema is needed as returns are fully documented.
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 provides detailed parameter semantics including defaults, coordinate definitions, and explanations for all five parameters. Examples illustrate usage and coordinate interpretation, adding significant meaning beyond the schema.
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 clearly states the tool's function: 'Position camera orbiting around a target node at specified angle and distance.' It uses specific verbs (position, orbiting) and identifies the resources (camera, target node). It distinguishes from sibling tools like daz_frame_camera_to_node and daz_look_at_character by focusing on spherical coordinate positioning.
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 implies usage for camera positioning around targets but does not explicitly state when to use this tool vs alternatives. No exclusions or when-not-to-use guidance is provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_reach_towardA
Position character's arm to reach toward a world-space point.
Uses pseudo-IK approximation to calculate shoulder and elbow rotations that position the hand near the target point. Automatically adjusts elbow bend based on target distance.
Args: character_label: Display label or internal name of the character. side: Which arm to use: "left" or "right". target_x: World X coordinate (cm) to reach toward. target_y: World Y coordinate (cm) to reach toward. target_z: World Z coordinate (cm) to reach toward.
Returns:
success: true on success
character: character label
side: which arm was posed
targetDistance: distance in cm from shoulder to target
bones: list of bone labels that were rotated
Example: # Reach right hand toward point in front at chest height daz_reach_toward("Genesis 9", "right", 50, 130, 80)
# Reach left hand toward object on left side
daz_reach_toward("Genesis 9", "left", -60, 100, 50)Note: This uses simplified IK approximation. For precise hand positioning or complex reaching, load an artist-created pose preset instead.
| Name | Required | Description | Default |
|---|---|---|---|
| character_label | Yes | ||
| side | Yes | ||
| target_x | Yes | ||
| target_y | Yes | ||
| target_z | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: uses pseudo-IK approximation, automatically adjusts elbow bend based on target distance, and notes limitations. No annotations provided, so description fully bears the responsibility and does so comprehensively, including return values and the note about precision.
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?
Well-structured with summary, Args, Returns, Example, and Note sections. Front-loaded with main action. Could be slightly more concise, but every sentence is informative and no fluff.
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?
Despite lack of schema coverage, the description fully covers behavior, parameters with units, return values, and limitations. Includes examples and a note about when to use alternatives. Output schema is described in Returns section.
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 description must document all 5 parameters. It does: character_label, side, target_x/y/z with units (cm), and provides examples showing parameter usage and ranges. Adds meaning beyond just listing 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?
The description clearly states the tool's purpose: 'Position character's arm to reach toward a world-space point.' It distinguishes the tool from sibling tools like daz_look_at_point (for eyes/head) and daz_interactive_pose by specifying arm positioning and pseudo-IK approximation.
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 usage context through examples and a note: 'This uses simplified IK approximation. For precise hand positioning or complex reaching, load an artist-created pose preset instead.' This tells when not to use, though it could be more explicit about when to use vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_remove_keyframeA
Remove a keyframe at specified frame.
Deletes a single keyframe from a property at the given frame number. Other keyframes on the property remain unchanged.
Args: node_label: Display label of the node. property_name: Property label or internal name. frame: Frame number of keyframe to remove.
Returns:
success: true
node: node label
property: property label
frame: frame number
removed: true if keyframe existed and was removed, false if no keyframe at that frame
Example: # Remove specific keyframe daz_remove_keyframe("Genesis 9", "XTranslate", frame=15)
# Remove all keyframes one by one
keyframes = daz_get_keyframes("Genesis 9", "XTranslate")
for kf in keyframes['keyframes']:
daz_remove_keyframe("Genesis 9", "XTranslate", kf['frame'])Note: - If no keyframe exists at the frame, removed=false (not an error) - Other keyframes remain unchanged - Use daz_clear_animation() to remove all keyframes at once
| Name | Required | Description | Default |
|---|---|---|---|
| node_label | Yes | ||
| property_name | Yes | ||
| frame | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It explains that other keyframes remain unchanged, and that if no keyframe exists at the frame, `removed=false` (not an error). The return value includes `removed` boolean. It does not explicitly state the destructive nature, but it is implied by 'remove'. Overall good transparency.
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 well-structured with Args, Returns, Example, and Note sections. It is appropriately sized with no redundant information. Every sentence adds value.
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?
Given the output schema existence and the detailed description covering return values, parameter semantics, and edge cases (non-existent keyframe), the description is complete for the agent to use the tool 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 coverage is 0%, so description must compensate. It does so by explaining each parameter in the Args section: `node_label` (display label), `property_name` (label or internal name), `frame` (frame number). This adds valuable meaning beyond the raw schema.
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 clearly states the tool removes a single keyframe from a property. It distinguishes from the sibling tool `daz_clear_animation` which removes all keyframes. The verb 'Remove' and resource 'keyframe' are specific.
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 provides explicit when-to-use (remove a single keyframe) and when-to-use-alternative (use `daz_clear_animation` for all keyframes). It includes an example suggesting using with `daz_get_keyframes`. It also notes that removing a non-existent keyframe returns `removed=false` and is not an error.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_renderA
Trigger a render in DAZ Studio using the current render settings.
Render dimensions, format, and other options are whatever is currently configured in DAZ Studio's Render Settings panel.
Args: output_path: Optional absolute path for the output image (e.g. "C:/renders/scene.png"). If omitted, DAZ Studio uses its currently configured output path.
Returns:
success: true when the render was launched without error
| Name | Required | Description | Default |
|---|---|---|---|
| output_path | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behaviors. It mentions that the return indicates launch success, but it is ambiguous whether the tool blocks until render completion (contrast with daz_render_async). No mention of prerequisites or side effects.
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 concise, using two short paragraphs plus structured args and returns. The first sentence front-loads the purpose. No superfluous content, though the Returns section could be integrated for brevity.
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?
Given the tool has an output schema, the description adequately covers purpose, parameter, and return. It could further detail synchronization behavior to fully differentiate from async siblings, but overall it provides sufficient information for a simple render trigger.
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 description must define the parameter. It explains output_path as an optional absolute path with a clear example and describes behavior when omitted. This adds meaningful context beyond the bare schema.
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?
Description clearly states 'Trigger a render in DAZ Studio using the current render settings.' The verb and resource are specific, and the scope (current settings) distinguishes from siblings like daz_render_async (async) and daz_render_animation (animation).
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?
Though no explicit when/when-not is provided, the description implies that users should configure render settings beforehand. It clarifies that dimensions, format, etc., come from the current Render Settings panel. This gives context but doesn't explicitly compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_render_animationA
Render animation frame range as image sequence.
Renders each frame of an animation to separate image files. Automatically advances through frames and generates zero-padded filenames for proper sorting. This is the recommended way to export animations.
Args: output_dir: Output directory for rendered frames. start_frame: First frame to render (default: animation range start). end_frame: Last frame to render (default: animation range end). filename_pattern: Filename pattern (default: "frame"). Frame number is appended. camera: Optional camera label to render from (default: current render camera).
Returns:
success: true on success
rendered: Array of {frame, outputPath} objects
total: Total number of frames rendered
frames: {start, end} frame range rendered
Example: # Render entire animation daz_render_animation(output_dir="/path/to/animation") # Generates: frame_0000.png, frame_0001.png, ..., frame_0119.png
# Render specific frame range
daz_render_animation(
output_dir="/path/to/animation",
start_frame=30,
end_frame=60,
filename_pattern="clip"
)
# Render animation from specific camera
daz_render_animation(
output_dir="/path/to/animation",
camera="Camera 1"
)
# Render preview (every 5th frame)
info = daz_get_animation_info()
for frame in range(info['startFrame'], info['endFrame'] + 1, 5):
daz_render_animation(
output_dir="/path/to/preview",
start_frame=frame,
end_frame=frame,
filename_pattern=f"preview_frame"
)Note: - Frame numbers are zero-padded to 4 digits (0000, 0001, etc.) - Current timeline frame is restored after render completes - If camera is specified, render camera is restored after completion - Use daz_get_animation_info() to get default frame range - Convert to video: ffmpeg -framerate 30 -i frame_%04d.png output.mp4
| Name | Required | Description | Default |
|---|---|---|---|
| output_dir | Yes | ||
| start_frame | No | ||
| end_frame | No | ||
| filename_pattern | No | frame | |
| camera | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes automatic frame advancement, zero-padded filenames, and restoration of timeline/camera. No annotations provided, so description carries full burden; covers key behaviors well, but could mention file format more explicitly.
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?
Well-structured with summary, args, returns, examples, and notes. Each section adds value without redundancy. Front-loaded with main purpose.
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?
Comprehensive: covers all parameters, return values, examples, and notes. Addresses sibling context by recommending this tool for animation export. Output schema is described.
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%, but description provides detailed explanations for all 5 parameters, including defaults and optionality, compensating fully.
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?
Clearly states 'Render animation frame range as image sequence.' Specific verb and resource, and distinguishes from siblings by being the recommended export method.
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 recommended for animation export, includes examples for various use cases. Could be more explicit about when to use alternatives like daz_render or daz_render_animation_async.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_render_animation_asyncA
Start an animation render asynchronously — returns immediately with a request_id.
Queues a full animation render (all frames as an image sequence). This can take hours; use daz_get_request_status() to monitor progress and daz_get_request_result() to confirm completion.
Args: output_dir: Directory where frame images are saved. start_frame: First frame (default: animation range start). end_frame: Last frame (default: animation range end). filename_pattern: Filename prefix (default: "frame"). Frame number appended. camera: Optional camera label (default: current render camera).
Returns: {"request_id": "script-XXXXXXXX", "status": "queued", "submitted_at": "..."}
| Name | Required | Description | Default |
|---|---|---|---|
| output_dir | Yes | ||
| start_frame | No | ||
| end_frame | No | ||
| filename_pattern | No | frame | |
| camera | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses key behaviors: async, immediate return, request_id, and image sequence. Lacks depth on error handling, cancellation, or scene state impact.
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?
Brief paragraph with bulleted Args and return example. Front-loaded main action. No wasted words.
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?
Covers async workflow, monitoring tools, and return format. Missing cancellation hint (daz_cancel_request). Adequate for the complexity level.
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%, but description explains all 5 parameters with defaults for start_frame, end_frame, filename_pattern, camera, and consistent info for output_dir. Adds value beyond schema.
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?
Description clearly states it starts an animation render asynchronously and returns a request_id. It distinguishes from siblings like daz_render_animation (sync) and daz_render_async (single frame) by specifying it queues all frames as an image sequence.
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 mentions the async nature, long duration, and use of daz_get_request_status and daz_get_request_result for monitoring. Does not compare directly to alternatives but context implies when to choose async over sync.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_render_asyncA
Start a render asynchronously — returns immediately with a request_id.
Use daz_get_request_status() to poll progress and daz_get_request_result() to retrieve the final result.
IMPORTANT: The scene is locked while the render runs. Do not modify the scene until the request status is "completed", "failed", or "cancelled".
Args: output_path: Optional file path for the rendered image.
Returns: {"request_id": "script-XXXXXXXX", "status": "queued", "submitted_at": "..."}
| Name | Required | Description | Default |
|---|---|---|---|
| output_path | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does a good job explaining the async nature, immediate return, scene locking, and the return value structure. Lacks details about resource usage or cancellation 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 description is concise, front-loaded with the main purpose, and uses a structured format with Args and Returns sections. Every sentence adds value.
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?
Covers the core functionality well given the simple async nature. Could mention default behavior when output_path is omitted or any prerequisites like scene load.
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 single parameter 'output_path' is explained as an optional file path for the rendered image, adding meaning beyond the schema's generic type definition.
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 clearly states the tool starts a render asynchronously and returns immediately with a request_id. It distinguishes from synchronous renders and other async variants like daz_render_animation_async.
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 specifies that the scene is locked during render and advises not to modify until completion. It also references sibling tools for polling and result retrieval. It could be more explicit about when not to use this tool (e.g., if synchronous behavior is desired).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_render_with_cameraA
Render from specific camera without changing active viewport camera.
Renders the scene from the specified camera's viewpoint. The viewport camera remains unchanged, making this ideal for multi-camera renders without disrupting the user's viewport.
Args: camera_label: Display label of the camera to render from. output_path: Optional output file path. If not specified, renders to viewport.
Returns:
success: true on success
camera: camera label used for render
outputPath: output file path (or null if rendered to viewport)
Example: # Render from specific camera daz_render_with_camera("Camera 1", output_path="/path/to/render.png")
# Render from multiple cameras without changing viewport
cameras = ["Front", "Side", "Top", "Perspective"]
for cam in cameras:
daz_render_with_camera(cam, output_path=f"renders/{cam}.png")
# Test render from camera (to viewport, no file)
daz_render_with_camera("Camera 1")Note: - Viewport camera remains unchanged after render - Previous render camera is restored automatically - Use for multi-camera batch renders - Combine with daz_orbit_camera_around() to set up camera first
| Name | Required | Description | Default |
|---|---|---|---|
| camera_label | Yes | ||
| output_path | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: viewport remains unchanged, previous render camera is restored automatically, and return values are documented. It also mentions rendering to viewport when no output path is given.
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 well-structured with sections for purpose, arguments, returns, example, and notes. Every sentence is informative and there is 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?
Given the tool's complexity and the presence of an output schema, the description covers all essential aspects: purpose, parameters, return values, example usage, and behavioral notes. It is complete for an agent to use 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?
With 0% schema coverage, the description compensates fully: 'camera_label: Display label of the camera to render from.' and 'output_path: Optional output file path. If not specified, renders to viewport.' This adds meaning beyond the bare schema.
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 clearly states the tool's purpose: 'Render from specific camera without changing active viewport camera.' It uses a specific verb and resource, distinguishing it from siblings like daz_render and daz_set_active_camera.
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?
Explicit guidance is given: 'ideal for multi-camera renders without disrupting the user's viewport.' The example shows batch rendering from multiple cameras, and the note suggests combining with daz_orbit_camera_around() for setup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_render_with_camera_asyncA
Start a camera-specific render asynchronously — returns immediately with a request_id.
Renders from the specified camera without changing the active viewport camera. Use daz_get_request_status() to poll and daz_get_request_result() for the result.
Args: camera_label: Display label of the camera to render from. output_path: Optional file path for the rendered image.
Returns: {"request_id": "script-XXXXXXXX", "status": "queued", "submitted_at": "..."}
| Name | Required | Description | Default |
|---|---|---|---|
| camera_label | Yes | ||
| output_path | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects. It states the tool does not change the active viewport camera, which is positive. However, it omits any mention of permissions, error behavior (e.g., invalid camera_label), or potential resource consumption, leaving gaps in understanding.
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 very concise with a clear structure: action sentence, key detail, bulleted Args, and return format. Every sentence adds value without 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 simple async render tool with two parameters and an output schema, the description covers the main points adequately. It could include error handling or invalid input behavior, but overall it is fairly complete given the modest complexity.
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 schema provides only type info (0% coverage). The description explains camera_label as 'Display label of the camera to render from' and output_path as 'Optional file path for the rendered image', adding meaningful context beyond the schema.
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 clearly states 'camera-specific render asynchronously' and 'returns immediately with a request_id', which conveys the core function. It differentiates from sibling tools by emphasizing camera specificity and async behavior, though it does not explicitly name alternatives.
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 implies usage for rendering from a camera without changing the active viewport, which gives some context. However, it lacks explicit guidance on when not to use this tool versus synchronous or other async render tools (e.g., daz_render_with_camera, daz_render_async).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_restore_scene_stateA
Restore scene state from a previously saved checkpoint.
Applies the transforms, morphs, and light properties captured by daz_save_scene_state back to the scene. Nodes that no longer exist are skipped and reported in the errors list.
Args: checkpoint_name: Name of the checkpoint to restore.
Returns: Dict with checkpoint_name, restored (list of node labels), and errors.
Raises: ToolError: If no checkpoint with the given name exists.
| Name | Required | Description | Default |
|---|---|---|---|
| checkpoint_name | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers important behaviors: skipped nodes are reported in errors, raises ToolError if checkpoint missing, and returns a structured dict. However, it does not disclose whether the restore overwrites current state (though implied) or any additional side effects.
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 concise, with a clear opening sentence and well-organized sections for args, returns, and raises. It is front-loaded with the core action and provides necessary details without 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?
Given the tool's low complexity (one parameter, no nested objects) and presence of an output schema, the description adequately explains what the tool does, its behavior for missing nodes, error conditions, and return structure. It is complete for the tool's scope.
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 schema has one parameter with no description, but the description's Args section provides clear meaning: 'Name of the checkpoint to restore.' This compensates for the 0% schema coverage and adds useful context.
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 clearly states the tool restores scene state from a previous checkpoint, specifying what is applied (transforms, morphs, light properties). It distinguishes itself from related tools like daz_save_scene_state and other scene manipulation tools.
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 implies usage after a checkpoint has been saved, but does not explicitly state when to use or when not to use this tool. No alternatives are mentioned, though the sibling list includes daz_save_scene_state which is the counterpart.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_save_camera_presetA
Save camera position and rotation as preset data.
Captures the current transform properties of a camera (position, rotation, scale) and returns them as preset data. This data can be saved by the client and later restored using daz_load_camera_preset().
Args: camera_label: Display label of the camera to save.
Returns:
preset: Dictionary containing:
label: camera label
transforms: Dictionary of property names to values (XTranslate, YTranslate, ZTranslate, XRotate, YRotate, ZRotate, XScale, YScale, ZScale)
Example: # Save camera position preset = daz_save_camera_preset("Camera 1")
# Client can store preset data (e.g., in a file or database)
import json
with open("my_camera_preset.json", "w") as f:
json.dump(preset, f)
# Later, restore the camera
with open("my_camera_preset.json") as f:
preset = json.load(f)
daz_load_camera_preset("Camera 1", preset["preset"])Note: - Preset data is a plain dictionary that can be serialized (JSON, etc.) - Includes all transform properties (position, rotation, scale) - Does not include camera-specific settings (focal length, DOF, etc.) - Preset data can be applied to any camera, not just the original
| Name | Required | Description | Default |
|---|---|---|---|
| camera_label | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description thoroughly discloses behavior: captures current transform properties (read operation), returns serializable dictionary, lists included/excluded properties, and notes applicability to any camera. No contradictions.
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?
Well-structured with summary, parameter, return, example, and notes. However, the example is somewhat verbose (including JSON file handling), which could be trimmed without losing clarity.
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?
Given the simplicity (1 parameter, output schema described), the description is fully complete: explains purpose, input, output format, usage pattern, limitations, and provides a practical example. No 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 has 0% coverage, but description adds semantic meaning: 'camera_label' is described as 'Display label of the camera to save', clarifying that it is a human-readable label, not an internal ID.
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?
Description clearly states the verb 'save' and resource 'camera preset data', and explicitly distinguishes from sibling tool 'daz_load_camera_preset' by mentioning its counterpart and usage pattern.
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 clear usage context: capturing and restoring camera transforms via serialization, with example. Notes what is excluded (camera-specific settings) but does not explicitly name alternative tools for those settings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_save_scene_stateA
Save current scene state as a named in-memory checkpoint.
Captures transforms (position, rotation, scale), active morphs, and light properties for all skeletons, cameras, and lights in the scene. Use this before experimental changes so you can restore with daz_restore_scene_state.
Args: checkpoint_name: Unique name for this checkpoint (e.g. "before_lighting_test"). Overwrites any existing checkpoint with the same name.
Returns: Dict with checkpoint_name, node_count, and saved_at (ISO timestamp).
Notes: Checkpoints are stored in the MCP server process memory and are lost if the server is restarted. They do not save materials, geometry, or HDR domes.
| Name | Required | Description | Default |
|---|---|---|---|
| checkpoint_name | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it captures specific node types and properties, overwrites existing checkpoints with the same name, returns a dict with checkpoint_name/node_count/saved_at, and notes that checkpoints are ephemeral and do not include materials/geometry/HDR domes. This is comprehensive for a mutation 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?
The description is well-structured with a clear first sentence stating the purpose, followed by details on what is captured, usage guidance, and a structured Args/Returns/Notes section. Every sentence is informative and earns its place without 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?
Given the tool's complexity and the presence of an output schema (described in Returns), the description is fully complete. It covers what the tool does, what is saved and not saved, when to use it, return values, and limitations. No critical information 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?
The input schema has 0% description coverage for the sole parameter 'checkpoint_name'. The description fully compensates by explaining its meaning ('Unique name for this checkpoint'), providing an example, and noting that it overwrites existing checkpoints with the same name. This adds significant value beyond the bare schema.
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 clearly states it saves the current scene state as a named in-memory checkpoint, listing exactly which elements are captured (transforms, morphs, light properties) and the intended use case (before experimental changes). It explicitly distinguishes from the sibling tool daz_restore_scene_state, which is the restoration counterpart.
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 provides explicit context for when to use ('before experimental changes') and mentions the corresponding restore tool. It also clarifies limitations (in-memory, lost on restart) and what is not saved (materials, geometry, HDR domes). However, it does not explicitly state when not to use it or suggest alternatives for saving non-captured elements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_scene_infoA
Return a snapshot of the current DAZ Studio scene.
Returns figures (characters + clothing), cameras, lights, and the primary selection. Does not enumerate every scene node — use daz_execute for finer-grained queries.
Returns a dict with:
sceneFile: path to the open .duf file, or empty string if unsaved
selectedNode: label of the primary selection, or null
figures: list of {name, label, type} for all DzSkeleton objects
cameras: list of {name, label} for all cameras
lights: list of {name, label, type} for all lights
totalNodes: total node count in the scene
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses it is a read-only snapshot, details return fields, and mentions limitations (not every node). No contradictions.
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?
Description is concise, well-structured with bullet points for return fields, and front-loads the core purpose.
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?
Given zero parameters, an output schema, and sibling context, the description is complete: it covers purpose, scope, limitations, and return format.
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?
No parameters, so baseline is 4. Description does not need to add parameter info.
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?
Description explicitly states it returns a snapshot of the DAZ Studio scene, listing specific elements (figures, cameras, lights, primary selection) and noting exclusions.
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?
Clearly tells when to use this tool vs daz_execute for finer-grained queries, providing explicit guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_script_helpA
Get DazScript documentation, examples, and best practices.
Use this tool BEFORE writing DazScript to learn correct patterns and avoid common mistakes. Topics cover critical gotchas, working examples, and detailed API references.
Available topics:
overview: DazScript environment basics
gotchas: Critical mistakes that cause timeouts or incorrect results
camera: Camera creation, positioning, and aiming
light: Light creation, types, and three-point lighting setup
environment: Iray environment settings and lighting modes
scene: Scene management (new, save, load, selection)
properties: Node properties, transforms, and morphs
content: Browsing and loading content from library
coordinates: Coordinate system and positioning reference
posing: Figure posing, bone hierarchy, morphs vs poses, rotation gotchas
morphs: Morph discovery, searching, value ranges, and management
hierarchy: Scene hierarchy, parent-child relationships, parenting operations
interaction: Multi-character interaction, look-at mechanics, world-space posing
batch: Batch operations for efficient multi-node/multi-property modifications
viewport: Viewport and camera control, positioning, framing, presets
animation: Animation system, keyframing, timeline control, rendering animations
rendering: Advanced rendering control, multi-camera, batch rendering, animation export
Args: topic: Documentation topic to retrieve (default: "overview")
Returns: Formatted documentation with examples for the requested topic.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | overview |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It explains it returns 'Formatted documentation with examples for the requested topic.' It does not mention side effects, but as a read-only help tool, that is acceptable. Could be slightly improved by explicitly stating it is non-destructive.
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 well-structured and concise. Key info (purpose, usage advice) is front-loaded. The list of topics is neatly organized with bullet points. Every sentence adds value without 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?
Given the tool's simplicity (one optional parameter, returns formatted docs), the description provides all necessary information: purpose, usage context, available topics, argument details, and return value. It is fully complete for the agent to use it 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?
Input schema has only one optional parameter 'topic' with 0% description coverage. The description compensates excellently by listing all possible topic values and their meanings (e.g., 'gotchas: Critical mistakes that cause timeouts or incorrect results'), adding significant semantic value beyond the schema.
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 clearly states the tool's purpose: 'Get DazScript documentation, examples, and best practices.' The verb 'Get' and resource 'DazScript documentation' are specific. It distinguishes itself from sibling tools which are action-oriented (e.g., daz_execute, daz_render) rather than informational.
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 says 'Use this tool BEFORE writing DazScript to learn correct patterns and avoid common mistakes.' This provides clear when-to-use guidance. The detailed list of topics further helps the agent select the right topic, effectively guiding usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_search_morphsA
Search for morphs matching a name pattern.
Search through all numeric properties (morphs) on a node for those matching a substring pattern. Useful for finding specific morphs like all facial expressions, body morphs, or morphs for a specific body part.
Args: node_label: Display label or internal name of the node (e.g., "Genesis 9"). pattern: Substring to search for in morph label or name (case-insensitive). Examples: "smile", "head", "muscle", "express" include_zero: If True, return all matching morphs including zero values. If False (default), only return matching morphs that are active.
Returns:
morphs: List of matching morph objects with:
label: Display label
name: Internal name
value: Current value
path: Property path
count: Number of matching morphs
pattern: The search pattern used
nodeLabel: Confirmed node label
Example: # Find all smile-related morphs result = daz_search_morphs("Genesis 9", "smile", include_zero=True) # result["morphs"] might include: "Smile", "Smile Open", "Smile Closed", etc.
# Find active head morphs
result = daz_search_morphs("Genesis 9", "head", include_zero=False)
# Only returns head morphs with non-zero values
# Find all facial expression morphs
result = daz_search_morphs("Genesis 9", "express", include_zero=True)| Name | Required | Description | Default |
|---|---|---|---|
| node_label | Yes | ||
| pattern | Yes | ||
| include_zero | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes that the tool searches all numeric properties, returns morph details (label, name, value, path), and explains the include_zero parameter behavior. It does not mention side effects, but 'Search' implies read-only. The return structure is well-documented.
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 well-structured with a clear summary, args, returns, and examples. It is front-loaded with the main purpose. While thorough, it is slightly verbose but earns its length due to complexity.
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?
Given the tool has 3 parameters, no annotations, and an output schema, the description covers all aspects: input params, return structure (morphs, count, pattern, nodeLabel), and usage examples. It is complete for a search 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?
With 0% schema description coverage, the description fully explains each parameter: node_label (display or internal name), pattern (substring, case-insensitive, examples), and include_zero (behavioral difference). Detailed examples demonstrate usage effectively.
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 clearly states 'Search for morphs matching a name pattern' and explains it searches through numeric properties on a node. Examples show finding specific morphs like facial expressions, body morphs, or morphs for a specific body part. This differentiates it from siblings like daz_list_morphs by adding pattern matching and substring search.
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 provides clear context on when to use this tool (finding specific morphs by pattern) with multiple examples. However, it does not explicitly mention when not to use it or compare with alternatives like daz_list_morphs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_set_active_cameraA
Set which camera is active in the DAZ Studio viewport.
Changes the active viewport camera to show the scene from the specified camera's perspective. The previous active camera is returned for reference.
Args: camera_label: Display label of the camera to activate.
Returns:
success: true on success
camera: label of the camera that was activated
previousCamera: label of the previously active camera (or null)
Example: # Switch to a specific camera daz_set_active_camera("Camera 1")
# Switch to a custom camera
daz_set_active_camera("Close Up Camera")
# Switch back to default camera
daz_set_active_camera("Perspective View")Note: The camera must exist in the scene. Use daz_scene_info() to list available cameras. The viewport updates immediately to show the camera's current view.
| Name | Required | Description | Default |
|---|---|---|---|
| camera_label | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the previous active camera is returned, the viewport updates immediately, and the camera must exist. It does not mention any destructive side effects, but none are expected. The behavioral information is sufficient for a safe operation.
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 well-structured with clear sections (Summary, Args, Returns, Example, Note). While slightly verbose, every sentence adds value, such as the note about listing cameras and the viewport update. It could be tightened slightly, but overall it is effective.
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?
Given the tool's simplicity (one parameter, output schema exists), the description covers all necessary aspects: input, output (including previousCamera), example usage, and precondition (camera must exist). The output schema existence reduces the need to explain return values, but the description still provides useful context.
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 schema has 0% description coverage, so the description must add meaning. It describes camera_label as 'Display label of the camera to activate' and provides multiple examples with different labels, clarifying the expected input beyond the bare schema.
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 clearly states the tool's purpose: 'Set which camera is active in the DAZ Studio viewport.' It uses a specific verb ('set') and resource ('active camera'), and the focus on activation differentiates it from sibling tools like daz_apply_camera_angle or daz_frame_camera_to_node.
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 provides clear guidance on when to use the tool, including prerequisites: 'The camera must exist in the scene. Use daz_scene_info() to list available cameras.' It also explains the effect ('viewport updates immediately') and mentions the return of the previous camera, helping the agent understand context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_set_emotionA
Apply an emotional expression to a character using morph candidates + body adjustment.
Args: character_label: Node label of the character to affect. emotion: One of: happy, sad, angry, surprised, fearful, disgusted, neutral, excited, bored, confident, shy, loving, contemptuous. intensity: Scale factor 0.0–1.0 applied to all morph and body values (default 0.7).
Returns: Dict with applied_morphs, body_adjustments, and not_found lists.
Notes: Morph candidates are tried in order; first match per slot wins. Not-found morphs are reported but do not raise errors — figures vary in available morphs.
| Name | Required | Description | Default |
|---|---|---|---|
| character_label | Yes | ||
| emotion | Yes | ||
| intensity | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses morph priority order, error handling (no raise on missing morphs), and return structure. With no annotations, this is good but could mention if changes are reversible or require specific scene context.
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?
Compact, front-loaded purpose, organized into Args/Returns/Notes. Every sentence adds value without 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?
Covers behavior and parameters well, but lacks prerequisites (e.g., character must exist) and doesn't note that output schema exists. Almost complete.
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 has 0% coverage, but description fully defines each parameter: character_label, emotion (with 13 enumerated values), and intensity (default 0.7, 0–1 range).
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 clearly states the tool applies an emotional expression via morphs and body adjustment, distinguishing it from generic property setters like daz_set_property or pose tools.
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 explicit guidance on when to use this tool versus alternatives (e.g., setting morphs individually). The behavior description is present but not comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_set_frameA
Set current animation frame.
Moves the timeline to the specified frame. This updates the scene to show the state at that frame, evaluating all animated properties.
Args: frame: Frame number to move to (integer).
Returns:
success: true
frame: new current frame
previousFrame: frame number before the change
Example: # Jump to specific frame daz_set_frame(30)
# Render each frame of animation
info = daz_get_animation_info()
for frame in range(info['startFrame'], info['endFrame'] + 1):
daz_set_frame(frame)
daz_render(output_path=f"frame_{frame:04d}.png")
# Preview keyframes
keyframes = daz_get_keyframes("Genesis 9", "XTranslate")
for kf in keyframes['keyframes']:
daz_set_frame(kf['frame'])
# ... preview or inspect ...Note: - Scene updates to show animated state at the frame - All animated properties evaluate at the new frame - Frame numbers are typically 0-based integers - Use with daz_render() to export animation frames
| Name | Required | Description | Default |
|---|---|---|---|
| frame | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the scene updates to show animated state, evaluates all animated properties, and returns success, frame, and previousFrame. Side effects are clearly documented.
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?
Well-structured with a one-line summary, detailed paragraph, Args/Returns/Example/Note sections. Every sentence adds value, and the front-loaded summary aids quick understanding.
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?
Given one parameter and an output schema, the description covers behavior, side effects, examples, and notes. It is fully complete for an agent to select and invoke 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 has only one parameter with 0% coverage, but description compensates by documenting 'frame' as integer, explaining it sets the frame number, and providing examples. No additional meaning needed.
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 clearly states the tool sets the current animation frame, moves the timeline, and updates the scene. It uses specific verbs and resources, distinguishing from siblings like daz_set_frame_range and daz_get_animation_info.
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 context for usage with examples (rendering animation, previewing keyframes) and notes about frame numbers. However, lacks explicit guidance on when not to use this tool or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_set_frame_rangeA
Set animation frame range (start and end).
Defines the playback range for the animation timeline. This determines which frames are included when playing or exporting animation.
Args: start_frame: First frame of animation (typically 0). end_frame: Last frame of animation.
Returns:
success: true
startFrame: new start frame
endFrame: new end frame
previousStart: previous start frame
previousEnd: previous end frame
Example: # Set 120-frame animation (4 seconds at 30fps) daz_set_frame_range(0, 119)
# Set 300-frame animation (10 seconds at 30fps)
daz_set_frame_range(0, 299)
# Set custom range starting from frame 10
daz_set_frame_range(10, 100)Note: - Frame range is inclusive (both start and end frames are included) - Default FPS in DAZ Studio is typically 30 - Duration in seconds = (end - start + 1) / fps - Example: frames 0-29 at 30fps = 1 second (30 frames)
| Name | Required | Description | Default |
|---|---|---|---|
| start_frame | Yes | ||
| end_frame | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses behavioral traits: sets start/end frames, inclusive, default FPS, duration calculation, and returns previous and new values. No contradictions.
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?
Well-organized with sections (Args, Returns, Example, Note). Front-loaded with purpose. Slight verbosity in the note but overall efficient. Deserves a 4 for good structure.
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?
Given no annotations and 0% schema coverage, the description is complete. It covers return values, inclusive range, FPS, and duration formula. No gaps for the agent to infer.
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 has no descriptions, but the description explains each parameter (start_frame as first frame, end_frame as last frame) and provides examples. Adds significant meaning beyond the schema.
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?
Clearly states 'Set animation frame range' with specific verb and resource. The description distinguishes this from sibling tools like 'daz_set_frame' (current frame) and 'daz_clear_animation'. The purpose is unambiguous.
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?
Implied usage is clear: for setting the playback range of animation. Provides context about inclusive range and FPS, but doesn't explicitly state when not to use or compare to alternatives. Still, the context is sufficient for an AI agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_set_keyframeA
Set a keyframe on a property at specified frame.
Creates or updates a keyframe for a numeric property at the given frame number. This is the fundamental operation for creating property animations.
Args: node_label: Display label of the node. property_name: Property label or internal name. frame: Frame number (integer, typically 0-based). value: Value to set at this frame.
Returns:
success: true on success
node: node label
property: property label
frame: frame number
value: value set at the keyframe
Example: # Animate character moving right (0 to 100cm over 30 frames) daz_set_keyframe("Genesis 9", "XTranslate", frame=0, value=0) daz_set_keyframe("Genesis 9", "XTranslate", frame=30, value=100)
# Animate rotation (0 to 90 degrees over 60 frames)
daz_set_keyframe("Genesis 9", "YRotate", frame=0, value=0)
daz_set_keyframe("Genesis 9", "YRotate", frame=60, value=90)
# Animate morph (fade in smile)
daz_set_keyframe("Genesis 9", "PHMSmile", frame=0, value=0)
daz_set_keyframe("Genesis 9", "PHMSmile", frame=15, value=0.8)Note: - DAZ Studio interpolates between keyframes automatically - Setting a keyframe at an existing frame updates the value - Frames are typically 0-based integers - Use daz_set_frame_range() to define the animation length first
| Name | Required | Description | Default |
|---|---|---|---|
| node_label | Yes | ||
| property_name | Yes | ||
| frame | Yes | ||
| value | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses behavior: creates or updates keyframes, interpolates automatically, updating existing frame updates value, frames 0-based. Also states return values. Does not mention permissions or potential side effects, but these are minimal for a keyframe 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?
Description is well-structured with sections: purpose, Args, Returns, Example, Note. It is concise yet comprehensive, with every sentence adding value. No redundant or 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?
Given 4 required parameters, no annotations, but output schema exists, the description covers all necessary aspects: purpose, parameters, return values, examples, and a note about frame range. References a sibling tool (daz_set_frame_range) for completeness.
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 description must provide parameter meanings. The Args section explains each parameter (node_label, property_name, frame, value) clearly, and examples demonstrate usage with realistic values. This fully compensates for missing schema descriptions.
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?
Description clearly states it sets a keyframe on a property at a specified frame, creates or updates keyframes for animation. Verb is specific ('set a keyframe on a property'), resource is clear, and it distinguishes from sibling tools like daz_set_property (no animation) and daz_remove_keyframe.
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?
Description provides usage context: 'fundamental operation for creating property animations' and advises to use daz_set_frame_range first. It implicitly tells when to use (animation) vs alternative (e.g., daz_set_property for non-animated changes). Explicit when-not-to-use is absent but inferred from examples and notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_set_parentA
Set parent of a node (parenting operation).
Changes the parent of a node, effectively moving it in the scene hierarchy. Commonly used to attach props to figures (e.g., weapon to hand) or reorganize scene structure.
Args: node_label: Display label or internal name of node to parent. parent_label: Display label or internal name of new parent. maintain_world_transform: If True (default), adjust local transform to maintain the same world-space position/rotation. If False, keep local transform (node will move in world space).
Returns:
success: true on success
node: Node label
newParent: New parent label
previousParent: Previous parent label (or null if was root)
Example: # Attach sword to right hand (maintain position) result = daz_set_parent("Sword", "rHand", maintain_world_transform=True) # Sword stays in place, now follows hand movements
# Parent camera to figure (follows figure)
result = daz_set_parent("Camera 1", "Genesis 9", maintain_world_transform=True)
# Unparent node (make it root) - parent to Scene root
result = daz_set_parent("Prop", "Scene", maintain_world_transform=True)Note: When maintain_world_transform=True, the node's world position is preserved, but its local transform values (X/Y/Z Translate, Rotate) will change to account for the new parent's transform.
| Name | Required | Description | Default |
|---|---|---|---|
| node_label | Yes | ||
| parent_label | Yes | ||
| maintain_world_transform | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses the behavioral traits of the tool: it changes parent, can unparent (set parent to 'Scene'), and explains the effect of maintain_world_transform on local transforms. With no annotations provided, the description carries the full burden and excels, noting that local transform values will change when maintaining world transform.
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 well-structured with a concise one-line summary, followed by a clear explanation, labeled args, returns, and examples. Every sentence provides value, no redundancy. The examples are illustrative without being 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?
The description covers the purpose, parameters, return values (including a Returns section detailing success, node, newParent, previousParent), and behavior. With an output schema present, the description complements it well. All essential information for correct agent usage is present.
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?
Despite the schema having 0% coverage (meaning schema properties have no descriptions), the description includes an 'Args' section that adds meaning to each parameter: node_label and parent_label are described, and maintain_world_transform is explained with its default and behavior. This adds significant value beyond the bare schema.
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 clearly states 'Set parent of a node (parenting operation)' and explains it changes the parent, moving it in the scene hierarchy. Examples show distinct use cases (attaching sword to hand, unparenting to Scene) that differentiate it from sibling tools like daz_get_parent (query) or daz_batch_transform (repositioning).
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 provides clear context for when to use the tool, including examples of attaching props to figures and reorganizing scene structure. It explains the maintain_world_transform parameter's effect, but doesn't explicitly state when not to use it or compare with alternatives. Still, the examples give practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_set_propertyA
Set a numeric property on a scene node.
Works for transforms (e.g. "X Translate", "Y Rotate"), morphs (e.g. "Head Size"), and any other numeric dial. Use daz_get_node first to discover available property names.
DAZ Studio units: centimetres for translation, degrees for rotation, 0–1 (or percentage) for most morphs.
Args: node_label: Display label or internal name of the target node. property_name: Display label or internal name of the property to set. value: New numeric value.
Returns:
node: node label as confirmed by DAZ Studio
property: property label as confirmed by DAZ Studio
value: the value read back after setting
| Name | Required | Description | Default |
|---|---|---|---|
| node_label | Yes | ||
| property_name | Yes | ||
| value | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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 that it works for transforms, morphs, and other numeric dials, specifies units (cm, degrees, 0-1), and describes the return structure. However, it lacks details on side effects (e.g., whether it creates animation keys) or error conditions, and does not state that it mutates state.
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 compact and well-structured, with a brief summary, a clarifying paragraph on units, and clearly labeled Args/Returns sections. Every sentence adds value without 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?
Given the low complexity (3 simple parameters, no nested objects), the description adequately covers purpose, parameters, units, and return values. It could be improved by mentioning how to handle errors or case sensitivity of property names, but it is largely complete.
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%, but the description includes a detailed docstring for each parameter: node_label (display or internal name), property_name (display or internal name), and value (new numeric value). This adds complete semantic meaning beyond the minimal schema types.
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 clearly states it sets a numeric property on a scene node, listing examples (transforms, morphs) and distinguishes from sibling 'daz_batch_set_properties' by focusing on single property setting. The main verb 'Set' is specific and the resource 'numeric property on a scene node' is precise.
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 provides when to use it (setting numeric properties) and explicitly recommends using daz_get_node first to discover property names. However, it does not explicitly mention when not to use it or alternative tools like daz_batch_set_properties for multiple properties, though the sibling list implies that distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_set_render_qualityA
Set the Iray render quality preset.
Adjusts Max Samples and Render Quality on the active renderer, trading speed for quality. Use "draft" for quick composition checks and "final" for production renders.
Presets: draft - Very fast (seconds–2 min). Low quality. For quick checks. preview - Fast (2–5 min). Moderate quality. For composition review. good - Slow (10–20 min). Good quality. For client review. final - Very slow (30 min–2 hr). Maximum quality. For final output.
Args: preset: One of "draft", "preview", "good", "final".
Returns: { "preset": "draft", "propertiesSet": [ {"property": "Max Samples", "value": 100}, {"property": "Render Quality", "value": 0.5} ], "note": "..." # present only if some properties were not found }
Example: # Quick test render daz_set_render_quality("draft") daz_render("/test.png")
# Final quality async render
daz_set_render_quality("final")
req = await daz_render_async("/final.png")
result = await daz_get_request_result(req["request_id"], wait=True)| Name | Required | Description | Default |
|---|---|---|---|
| preset | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains that the tool modifies render quality and max samples, returns properties set, and provides a note if some properties are missing. It also implies speed trade-offs via preset descriptions. However, it does not mention prerequisites like an open scene or active renderer, nor effects on ongoing renders.
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 well-organized into sections: a one-line purpose, a preset table, args, returns, and an example. Every sentence is informative, with no fluff or repetition. The structure makes it easy to scan.
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?
Given the low complexity (single parameter, presets) and the presence of an output schema, the description fully covers behavior, input options, return format, and practical usage via examples. Nothing essential 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?
The schema only defines 'preset' as a required string with 0% description coverage. The tool description compensates thoroughly by listing each preset value with typical time ranges and quality levels, adding significant meaning beyond the schema's minimal definition.
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 clearly states 'Set the Iray render quality preset' and explains it adjusts Max Samples and Render Quality. It unambiguously identifies the tool's function and distinguishes it from siblings like render tools or property setters.
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 provides explicit guidance on when to use each preset ('Use "draft" for quick composition checks and "final" for production renders') and includes an example with two contexts. It does not explicitly state when not to use the tool or mention alternatives, but the context is clear enough for typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_statusA
Check DAZ Studio connectivity. Returns server status and version.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description covers the basic behavior (read-only check) but lacks detail on what 'server status' includes (e.g., online/offline, error codes) or any potential side effects.
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, clear sentence with no redundant information. Every word serves a purpose.
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?
Given zero parameters and an output schema (not shown), the description adequately covers the tool's purpose. It could mention that the output contains status and version details, but it's largely complete.
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?
No parameters exist, so the baseline is 4. The description adds no parameter information, which is acceptable since none are needed.
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 clearly states it checks DAZ Studio connectivity and returns server status and version, using a specific verb and resource. It distinguishes itself from sibling tools that perform actions like rendering or setting properties.
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 explicit guidance on when to use this tool versus alternatives. While the purpose implies it could be used for connectivity checks, there is no mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_validate_sceneA
Validate the current scene for common issues before rendering.
Checks:
Character/figure bounding box collisions (interpenetration)
Lighting presence and quality
Camera presence
Empty scene (no figures)
Returns a score (0-100) and breakdown by category, plus actionable suggestions for any issues found.
Returns: { "valid": true, "issues": [ { "type": "collision", "severity": "high", "nodes": ["Alice", "Bob"], "description": "Alice and Bob bounding boxes overlap by ~15 cm", "suggestion": "Move one character away to resolve interpenetration" } ], "warnings": [...], "score": 75, "score_breakdown": { "lighting": 100, "collision": 30, "camera": 100, "figures": 100 }, "summary": { "figures": 2, "cameras": 1, "lights": 3, "environment_lighting": false } }
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It comprehensively explains the tool's behavior: what it checks (collisions, lighting, camera, empty scene), that it returns a score and breakdown, and provides the exact output schema with example. This fully informs the agent.
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 moderately concise, using bullet points and an example output to convey structure. It could be slightly shorter, but the layout is clear and front-loaded with key info.
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?
Given zero parameters and the detailed output description (including return schema in the description), the tool definition is fully complete. The agent has all necessary context to use the tool 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?
The input schema has zero parameters, so no parameter documentation is needed. Schema description coverage is 100%. The description naturally does not add parameter semantics because there are none 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?
The description clearly states the tool validates the current scene for common issues before rendering, listing specific checks (collisions, lighting, camera, empty scene). This distinguishes it from sibling tools like daz_check_overlap, which focuses only on overlap.
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 implies use before rendering by stating 'before rendering' and lists what it checks. However, it does not explicitly exclude conditions or mention alternatives, though siblings like daz_check_overlap provide more specific checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daz_validate_scriptA
Check a DazScript string for known anti-patterns before execution.
Performs static analysis only — no script is sent to DAZ Studio. Returns errors for known crash/timeout patterns and warnings for deprecated or error-prone usage.
Args: script: DazScript (JavaScript) source code to validate
Returns: { "valid": false, "errors": [ { "line": 3, "pattern": "DzNewCameraAction", "message": "Action classes pop modal dialogs and cause timeouts", "suggestion": "Use: var cam = new DzBasicCamera(); Scene.addNode(cam);" } ], "warnings": [...], "suggestions": [...] }
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states static analysis only, no script sent to DAZ Studio, and describes the return structure with errors, warnings, and suggestions. This fully discloses behavior and safety.
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 concise and well-structured: purpose first, then static analysis detail, then a clear example of return values. Every sentence adds value.
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 simple validation tool with one parameter and an output schema, the description fully covers behavior, input details, and return structure. No 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 description coverage is 0%, but the description adds meaning by specifying 'DazScript (JavaScript) source code to validate' for the script parameter, clarifying its type beyond the schema's 'string'.
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 clearly states 'Check a DazScript string for known anti-patterns before execution.' It specifies the verb (check), resource (DazScript), and scope (anti-patterns), distinguishing it from sibling tools like daz_execute that run scripts.
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 it performs static analysis only and returns errors/warnings, implying it should be used before execution. However, it does not explicitly mention when not to use or suggest alternatives like daz_execute for running scripts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
70 tool updates
v0.2.0- First observed
daz_apply_camera_angle - First observed
daz_apply_composition_rule - First observed
daz_apply_lighting_preset - First observed
daz_batch_render_cameras - First observed
daz_batch_render_cameras_async - First observed
daz_batch_select - First observed
daz_batch_set_properties - First observed
daz_batch_transform - First observed
daz_batch_visibility - First observed
daz_browse_category - First observed
daz_calculate_distance - First observed
daz_cancel_request - First observed
daz_check_overlap - First observed
daz_clear_animation - First observed
daz_execute - First observed
daz_execute_file - First observed
daz_find_nearby_nodes - First observed
daz_frame_camera_to_node - First observed
daz_frame_shot - First observed
daz_get_animation_info - First observed
daz_get_bounding_box - First observed
daz_get_content_info - First observed
daz_get_keyframes - First observed
daz_get_node - First observed
daz_get_node_hierarchy - First observed
daz_get_parent - First observed
daz_get_property_metadata - First observed
daz_get_render_settings - First observed
daz_get_request_result - First observed
daz_get_request_status - First observed
daz_get_scene_layout - First observed
daz_get_spatial_relationship - First observed
daz_get_world_position - First observed
daz_inspect_properties - First observed
daz_interactive_pose - First observed
daz_list_categories - First observed
daz_list_checkpoints - First observed
daz_list_children - First observed
daz_list_morphs - First observed
daz_list_requests - First observed
daz_load_camera_preset - First observed
daz_load_file - First observed
daz_look_at_character - First observed
daz_look_at_point - First observed
daz_orbit_camera_around - First observed
daz_reach_toward - First observed
daz_remove_keyframe - First observed
daz_render - First observed
daz_render_animation - First observed
daz_render_animation_async - First observed
daz_render_async - First observed
daz_render_with_camera - First observed
daz_render_with_camera_async - First observed
daz_restore_scene_state - First observed
daz_save_camera_preset - First observed
daz_save_scene_state - First observed
daz_scene_info - First observed
daz_script_help - First observed
daz_search_morphs - First observed
daz_set_active_camera - First observed
daz_set_emotion - First observed
daz_set_frame - First observed
daz_set_frame_range - First observed
daz_set_keyframe - First observed
daz_set_parent - First observed
daz_set_property - First observed
daz_set_render_quality - First observed
daz_status - First observed
daz_validate_scene - First observed
daz_validate_script
TDQS
Most tools have distinct purposes, but some camera and framing tools (e.g., daz_frame_camera_to_node vs daz_frame_shot) overlap slightly. Descriptions are detailed enough to differentiate, though agents might occasionally misselect.
All tools follow the 'daz_verb_noun' pattern consistently, including async variants (e.g., daz_render_async, daz_batch_render_cameras_async). Even utility tools like daz_status fit the pattern. No mixing of conventions.
70 tools is on the higher end for a single server, covering a broad domain. While each tool serves a specific need, some could be consolidated (e.g., multiple framing tools). Still, the count is reasonable given DAZ Studio's complexity.
Covers scene management, cameras, lighting, rendering, animation, morphs, posing, and content browsing. Minor gaps exist (e.g., no dedicated material or geometry creation tool), but the daz_execute tool allows arbitrary scripting to fill missing functionality.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Cloud Blender for AI agents: scenes, assets, renders, MP4, STL, GLB — over hosted remote MCP.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
MCP server for Google Veo AI video generation
MCP server for Grok Imagine AI video generation
Related MCP Servers
- AlicenseCqualityAmaintenanceEnables AI-powered control of Blender through natural language, allowing users to create, manipulate, and automate 3D scenes, objects, materials, animations, and more via Claude or other MCP clients.7141MIT
- AlicenseNot gradedqualityDmaintenanceA Model Control Protocol (MCP) server that allows Claude to communicate with locally running LLM models via LM Studio.MIT
- AlicenseNot gradedqualityBmaintenanceMCP server for AI-driven DAZ Studio scene editing. Runs as a native DAZ Studio plugin (DLL) and exposes all scene control, rendering, dForce, asset, and animation commands through the Model Context Protocol.8MIT
- AlicenseAqualityAmaintenanceMCP server that lets Claude drive a real, running OrcaSlicer: load models, arrange the plate, tune settings, slice, and read results back.24140AGPL 3.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bluemoonfoundry/daz-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server