vangard-daz-mcp

by bluemoonfoundry

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation4/5
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.
Naming Consistency5/5
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.
Tool Count3/5
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.
Completeness4/5
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.
Average 4.5/5 across 70 of 70 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 42 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![daz-mcp-server MCP server](https://glama.ai/mcp/servers/bluemoonfoundry/daz-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/bluemoonfoundry/daz-mcp-server)

Score Badge

Copy to your README.md:

[![daz-mcp-server MCP server](https://glama.ai/mcp/servers/bluemoonfoundry/daz-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/bluemoonfoundry/daz-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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