Skip to main content
Glama
Sign In
Daz3D-MCP

Daz3D-MCP

by MictlanLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

node_set

Move, rotate, scale, show or hide, rename, select, and attach (parent) Daz Studio figures, props, cameras, or lights to position and organize scene objects.

Instructions

Moves, rotates, scales, shows/hides, renames, selects or attaches (parents) a figure, prop, camera or light.

Tool call template

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

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "node": "<node>"
    },
    "name": "node_set"
  }
}

Input Schema

NameRequiredDescriptionDefault
nodeYesNode label.
labelNoNew label.
scaleNo1 = 100 %.
parentNoAttach it to this node (it keeps its place in the world); "" detaches it.
selectNoSelect it in Daz.
visibleNo
positionNo[x, y, z] cm (relative to its parent).
relativeNoAdd position/rotation to the current values.
rotationNo[x, y, z] degrees.
parent_boneNoWith parent = a figure: the bone to attach to, e.g. 'r_hand' for a sword, 'head' for a hat.
drop_to_floorNoMove it so its lowest point touches Y = 0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

B3.2/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is carried by structured data. Beyond that, the description adds little: it does not say whether changes are undoable, what happens when node is invalid, whether multiple operations in one call are applied atomically, or whether unset/null fields are left untouched. For an 11-parameter mutation tool, that is a meaningful gap.

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

Conciseness4/5

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

A single front-loaded sentence that enumerates capabilities without filler. It is well sized for the tool, though the verb list is dense and none of the operations are grouped or prioritized for the reader.

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

Completeness3/5

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

With 11 parameters, no output schema and annotations covering only safety, the description is complete enough to identify the tool but not to call it confidently in combination cases. It never explains how parent and parent_bone interact, how relative modifies position/rotation, or how drop_to_floor combines with an explicit position.

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

Parameters3/5

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

Schema description coverage is 91% and the schema itself documents units (cm, degrees), the relative flag, parent_bone examples, and the empty-string detach convention. The description only echoes the operations at a high level (move/rotate/scale/hide/rename/select/attach) and adds no syntax or interaction detail beyond the schema, so the baseline 3 is appropriate.

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

Purpose4/5

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

The description uses specific verbs (moves, rotates, scales, shows/hides, renames, selects, attaches) against a clearly named resource (a node: figure, prop, camera or light), so an agent can map intent to tool immediately. It loses a point because the object scope overlaps visibly with siblings like camera_set and light_set, and the description never acknowledges that boundary.

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

Usage Guidelines3/5

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

The list of supported operations implicitly tells the agent when this tool applies (any per-node transform, visibility, naming, selection or parenting change), but there is no explicit when-not guidance. Nothing warns that camera_set or light_set may be the preferred path for those node types, and no prerequisites or preconditions (e.g. node must exist, must be selected) are stated.

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

Deploy Server

Other Tools