Skip to main content
Glama
Sign In
Daz3D-MCP

Daz3D-MCP

by MictlanLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

daz_dialog

Destructive

Answers Daz Studio pop-up dialogs that block automated calls by listing open prompts, pressing a chosen button, toggling checkboxes, and returning the waiting call result.

Instructions

Sees and answers the pop-up dialogs Daz Studio opens (overwrite?, replace or add?, limits...). A tool that stops on one fails with dialog_open and lists its text and buttons; press one here and the stopped call's result comes back as call_result. Without button: lists open dialogs and, if a call was left waiting, waits for it. Ask the user before an answer that would overwrite or discard their work. Needs the bridge plugin 0.2+.

Tool call template

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

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

Input Schema

NameRequiredDescriptionDefault
waitNoSeconds to wait for the stopped call to finish after answering.
checkNoCheck boxes or radio buttons to turn on before pressing.
buttonNoButton to press, as listed (e.g. "Yes", "Replace"); "escape" cancels. Omit to only look.
uncheckNoCheck boxes to turn off before pressing.
dialog_idNoWhich dialog, when several are open (id from the list).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true, and the description corroborates this by warning about answers that overwrite or discard work, plus adds real context the annotations cannot carry: the dialog_open failure mode, how call_result comes back, and a bridge plugin version requirement (0.2+). It stops short of describing timeout behavior when the user's wait expires, which would have completed the picture.

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

Conciseness5/5

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

Roughly five short sentences, front-loaded with the purpose, then the failure mode, the usage modes, the safety instruction, and the prerequisite. Every sentence carries new information; nothing is redundant.

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

Completeness4/5

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

There is no output schema, and the description compensates by explaining that a list of dialogs with text and buttons is returned and that a stopped call's result arrives as call_result. Combined with the plugin requirement and safety guidance, an agent has what it needs, though timeout/expiry behavior after the wait period remains unstated.

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 100%, so button, check, uncheck, dialog_id and wait are already documented in the schema itself. The description only reinforces the 'omit button to only look' behavior and the wait semantics, adding little beyond the structured fields. Baseline 3 is appropriate.

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

Purpose5/5

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

States a specific verb and resource: it 'sees and answers the pop-up dialogs Daz Studio opens', with concrete examples of dialog kinds (overwrite?, replace or add?, limits...). No sibling tool in the catalog deals with dialogs, and the description makes that specialization obvious without reference to them.

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

Usage Guidelines5/5

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

Explains the trigger situation clearly (a call that stops fails with dialog_open and lists its text/buttons), what to do (press a button here and the stopped call's result returns as call_result), and what happens if you omit the button (list dialogs and wait for a pending call). It also gives an explicit caution: ask the user before answering in a way that would overwrite or discard work.

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

Deploy Server

Other Tools