HoudiniMCP

by JTCHE

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.1.0
Disambiguation3/5
There are several overlapping clusters, such as set_material/assign_material/assign_material_workflow and render_single_view/render_quad_views/render_specific_camera, which could confuse an agent. However, most tools have clear, distinct purposes targeting specific resources.
Naming Consistency4/5
Most tool names follow a consistent verb_noun snake_case pattern, such as list_materials, get_parameter, and create_node. Some domain-prefixed groups like pdg_*, lop_*, and hda_* deviate from the verb-first order, but the overall convention is still predictable.
Tool Count1/5
With 168 tools, the server is massively oversized for any practical purpose. This is an extreme mismatch, as even a comprehensive Houdini server could be organized into fewer, more focused tools.
Completeness5/5
The tool surface is exceptionally broad, covering node operations, parameters, keyframes, geometry, materials, rendering, PDG, LOP, COP, CHOP, DOP, HDA, viewport control, documentation, and more. No obvious gaps exist that would hinder typical workflows.
Average 3.1/5 across 168 of 168 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior1/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 says nothing about side effects, required context (e.g., parent path existence), or what happens on creation, offering zero transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified, not genuinely concise. It fails to include necessary information about parameters or usage, and it does not front-load any useful details beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple create tool, but with no output schema and no annotation, the description should explain the parameters and any prerequisites. It provides only the bare action, which is insufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameter. It does not mention that parent_path and node_type are required, nor does it clarify the meaning of the optional name parameter. The description adds no value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Create' and the resource 'CHOP node', which does distinguish it from other create tools like create_cop_node and create_lop_node. However, it is essentially a restatement of the tool name and lacks any additional scope or detail, making it only marginally clear.
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?
There is no guidance on when to use this tool versus alternatives such as generic create_node or other type-specific create tools. The description provides no contextual cues for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Get intrinsic values' with no information about return format, possible errors, side effects, or how prim_index affects the result. This is insufficient for a tool with zero structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is efficient, but it is under-specified rather than concise. It omits essential context, so the brevity is a negative trait here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotation coverage, and minimal description, the tool lacks complete context. There is no explanation of return values, error behavior, or parameter interactions, making it inadequate even for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either parameter (node_path, prim_index). It adds no meaning beyond the parameter names, failing to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('intrinsic values of a primitive'), which clearly identifies the tool's core function. It distinguishes from siblings like get_prims or get_attrib_values by focusing on intrinsics, a distinct concept in Houdini.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. The description does not mention sibling tools, prerequisites, or any use case context, leaving the agent to infer that it is for retrieving intrinsic values without any differentiation from related getter tools.
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, the description carries full responsibility for behavioral disclosure. It only says 'Get relationships', offering no information about side effects, required permissions, or the nature of the returned data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it lacks the substance needed to be effective. It is not poorly structured, yet it under-specifies rather than being appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description does not cover what relationships are returned or how they are formatted. The context is minimal and leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain 'path' or 'object_name'. The agent must guess their meaning and format, which is a significant gap for a tool with two required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' and names the resource 'DOP object', but 'relationships' is ambiguous—it could mean constraints, connectivity, or child links. It does not distinguish from sibling tools like get_dop_object or get_dop_field.
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. There is no mention of intended scenarios or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It provides no information about side effects, required render nodes, or valid renderer values. The one-line sentence adds no behavioral context beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence, but it is under-specified. It is not overly verbose, but it lacks the contextual detail expected for a useful tool description, making it more trivial than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and an unelaborated parameter, the description is severely incomplete. It does not explain renderer options, the effect of setting the viewport renderer, or any related configuration, leaving the agent without essential information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines a single required string parameter 'renderer' with no description or enums. The description does not compensate, offering no examples, values, or meaning for the parameter. Schema description coverage is 0%, and the description fails to bridge that gap.
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 action (set) and the resource (viewport renderer), distinguishing it from sibling tools like set_viewport_camera and set_viewport_display. It is specific and unambiguous, though it does not elaborate on the renderer concept or variations.
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 usage guidance is provided. The description does not indicate when to use this tool versus related tools such as set_render_settings or list_render_nodes, nor any prerequisites or expected context.
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, the description carries full burden. It only states the action 'create' with no details on side effects, required permissions, reversibility, or return structure. This is similar to the update_drive example where mutation is implied but behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it is under-specified to the point of being minimally informative. It lacks structure regarding usage or parameters, making it more an under-specification than a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has multiple parameters, no output schema, and no annotations, yet the description provides none of the needed context. It does not explain what a LOP node is, what parameters are required, or what the result of creation is. The description is severely incomplete for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter-level meaning. It does not mention parent_path, node_type, or name, nor does it explain their roles or relationships. The description fails to compensate for the absent schema descriptions.
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 states a clear verb+resource: 'Create a LOP node.' It is specific to LOP nodes, distinguishing it from generic node creation tools like create_node or create_wrangle. However, it does not elaborate on what constitutes a LOP node or differentiate it from other LOP-specific tools, so it misses full sibling differentiation.
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 such as create_node or create_material_network. There is no mention of prerequisites, exclusions, or typical use cases, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only says 'Set render settings,' which implies mutation but does not mention side effects (e.g., triggering a recook), whether existing settings are overwritten, required permissions, or what happens on invalid settings. This is almost no behavioral transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. However, it is under-specified for a tool with an opaque settings object and no annotations. Conciseness is good, but it sacrifices necessary detail, so a middle score is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an object-typed 'settings' parameter, no annotations, no output schema, and no return-value documentation, the description is far too minimal. It lacks information about the settings structure, error behavior, and expected side effects, leaving an agent to guess at critical execution details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the 2 parameters. The description mentions 'render settings' and 'ROP node' but does not explain the structure of the settings object, what valid keys exist, or the expected path format. It adds essentially no semantic meaning beyond the parameter names in 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 states a specific verb+resource: 'Set render settings on a ROP node.' It clearly distinguishes from sibling tools like get_render_settings (get vs set) and create_render_node (existing node vs create). However, it does not explicitly call out these alternatives, so it stops short of a 5.
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 vs alternatives such as set_parameter or get_render_settings. There is no mention of prerequisites (e.g., the ROP node must already exist) or context for typical usage. This is effectively no usage guidance, meriting a score of 2.
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, the description bears full responsibility for behavioral disclosure. It implies a mutation (creation) but provides no details about side effects, required permissions, node placement, or return behavior. This is minimally transparent, similar to 'Update' without elaboration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single short sentence. However, this brevity borders on under-specification rather than efficient economy, as it provides no additional value beyond the tool name. It is not verbose, but it also does not contain enough substance to earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% parameter coverage, the description is incomplete. It fails to explain the required parameters, valid node types, or the effect of creating a COP node in a scene. Sibling tools offer some context but the description itself is inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the three parameters (name, node_type, parent_path). The description adds no meaning to the parameters, leaving users without any hint about what values are expected (e.g., valid node types, path format). The description completely fails to compensate for the schema's lack of descriptions.
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 'Create a COP node' uses a specific verb and resource, clearly indicating the tool creates a compositing (COP) node. It distinguishes from sibling tools like create_chop_node and create_lop_node by explicitly naming 'COP'. However, it is a brief restatement of the tool name, lacking any additional context about what a COP node is or its role.
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?
There is no guidance on when to use this tool versus alternatives such as create_node or create_render_node. The description only states the action without context, prerequisites, or exclusions. Users are left to infer that this is for creating COP nodes specifically.
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?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It only says 'create' without explaining side effects, whether the parent_path must exist, what happens on conflict, or what the return value is—leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, which is concise. However, the extreme brevity results in under-specification rather than efficient structure, providing only the bare minimum of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, and no parameter descriptions, the tool is not adequately described for correct invocation. It lacks critical context such as valid material_type values, the meaning of 'material context', and how it relates to sibling tools like list_material_types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for name, parent_path, or material_type, and the description mentions none of them. With 0% schema description coverage, an agent receives no explanation of parameter meaning, valid values, or defaults beyond the raw property names and defaults, which is insufficient.
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 action (create) and resource (material node), which is more specific than a tautology. However, it does not distinguish itself from the sibling tool create_material_network, and 'in a material context' is somewhat vague.
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 like create_material_network or assign_material_workflow. The description lacks any context about prerequisites, typical use cases, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'create a new node,' which is little more than the name implies. It does not mention side effects, required permissions, or what happens to existing nodes, leaving the agent without critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence, which is concise. However, it is under-specified to the point of being minimally informative. It is not overly verbose, but it sacrifices necessary detail for brevity, making it only moderately effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 no output schema or annotations, the description is incomplete. It does not explain the required node_type, the default parent_path, or what happens after creation. The lack of parameter descriptions and usage guidance makes it insufficient for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters (node_type, name, parent_path). The agent cannot infer any parameter meaning, and the description totally fails to compensate for the lack of schema descriptions.
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 verb 'Create' and the resource 'node' in Houdini, making the primary purpose obvious. However, it does not distinguish this generic tool from specialized create tools like create_wrangle or create_material_network, so it lacks explicit sibling differentiation.
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, nor any exclusions or prerequisites. The description merely states the action without contextual advice.
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, the description carries the full burden of behavioral disclosure. It reveals that the export happens 'via expression' and implies a link from CHOP data to a parameter, but it doesn't describe what happens to existing parameter expressions, whether the export is dynamic or static, any required permissions, or side effects on the CHOP network. This is a minimal disclosure of behavior.
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 a single, focused sentence that front-loads the core action and resource. There is no redundant language or filler. While it lacks detail, that deficiency is captured in other dimensions; for what it does include, the structure is clear and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a four-parameter tool with no annotations, no output schema, and no additional context. The description only states the high-level purpose. It fails to explain the meaning of the parameters, the required setup, how the expression is generated, or what the agent should expect as a result. Given the tool's complexity and the lack of structured metadata, the description is grossly insufficient for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the four parameters (chop_path, channel_name, target_path, parm_name). It doesn't even mention parameter names or how they relate to the export process. An agent would be completely dependent on the bare schema titles without any added semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Export' and clearly identifies the resource ('CHOP channel') and the destination ('a parameter via expression'). It stands out from sibling tools like set_expression and get_chop_data because it specifically targets CHOP-to-parameter export. However, it doesn't explicitly contrast with set_expression, which also deals with parameter expressions, so it doesn't fully distinguish itself.
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 about when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., an existing CHOP network or parameter) or scenarios where another tool like set_expression or list_chop_channels would be more appropriate. The description simply states the action without contextual usage advice.
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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'Get the content' which essentially restates the tool name, adding no details about failure modes, permissions, output format, or side effects. For a read operation, some context about expected behavior is still needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, which is structurally concise. However, it is under-specified and provides almost no additional value beyond the tool name, so it falls short of being appropriately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, no output schema, and no annotations, the description is far too minimal to be complete. It does not explain what an 'HDA section' is, how the parameters interact, or what the return value represents. The presence of sibling tools implies some context, but this description leaves too many gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameters. The input schema lists node_type, section_name, and category without any descriptions, so the agent has no semantic understanding of what these parameters mean or how they affect the operation.
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 action ('Get') and resource ('content of a specific HDA section'), which is a specific verb+resource. It does not explicitly distinguish this from sibling tools like get_hda_sections or set_hda_section_content, but the intent 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., the node must be an HDA), nor does it contrast with get_hda_sections or set_hda_section_content. There is no context about typical scenarios or exclusions.
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 but fails to disclose behavioral traits such as whether it cooks the node, returns a specific structure, or requires network access. It only implies a read operation via the verb 'get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but its brevity sacrifices necessary detail; it's more under-specification than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too thin, lacking parameter semantics and any contextual detail about what 'detailed info' includes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The required 'path' parameter has no description in the schema, and the description doesn't mention it, leaving the format and semantics unclear. With 0% schema coverage, the description fails to compensate.
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 gets detailed info about a material node. It distinguishes from general node info tools by specifying material nodes, though 'detailed info' is vague.
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 given on when to use this versus alternatives like get_node_info or explain_node, nor any context about prerequisites.
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, the description carries full responsibility for behavioral disclosure. It mentions pagination but does not explain how node_path is used, what data is returned, whether there are side effects, or what the response format looks like. This is a significant gap for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it is under-specified rather than appropriately concise. It lacks substance needed for a 4-parameter tool, making it too sparse to count as effective front-loading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema, no annotations), the description is grossly incomplete. It fails to define the key terms (primitive data, node_path, attribs) and does not explain pagination mechanics or return values, making it impossible to invoke correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. 'Pagination' weakly hints at start and count, but the required parameter node_path and the attribs parameter are completely unexplained. The description adds minimal value beyond the schema names.
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 states a clear verb ('Get') and resource ('primitive data'), with 'pagination' indicating a list-style retrieval. This reasonably distinguishes it from siblings like get_geo_summary or get_prim_intrinsics, though it could specify exactly what aspect of primitives is returned.
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 such as get_points or get_prim_intrinsics. The pagination hint is the only contextual clue, but there is no explicit context, prerequisites, or exclusions.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state what the tool returns, whether it blocks, what happens if no render is in progress, or any side effects. This is a significant gap for a query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence and is front-loaded, but it is terse to the point of under-specification. It conveys the basic purpose but lacks detail, so it is not optimally concise in terms of information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a low-parameter tool, the description should explain return values, error conditions, and the tool's role in the render pipeline. It does none of this. The description is not complete enough for an agent to use the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'path' with no description, and schema description coverage is 0%. The description mentions 'ROP node' but does not explicitly explain that 'path' is the ROP node path, nor does it provide format, examples, or constraints. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('get') and resource ('render progress') and identifies the target ('a ROP node'). It clearly states what the tool does, but it does not explicitly differentiate it from the sibling tool 'monitor_render', which could also be related to render progress.
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. The description does not mention prerequisites (e.g., an active render), exclusions, or relationships to siblings like 'monitor_render' or 'start_render'. The usage context is entirely implicit.
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, the description carries full responsibility for disclosing behavior. It only says 'get memory usage,' omitting details about the 'path' parameter, return format, side effects, or error behavior. This is a significant gap for a tool that should clarify what the agent can expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a single sentence that gets to the point. However, it is under-specified, lacking essential details. While it is front-loaded and free of verbosity, its brevity comes at the cost of utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description should provide context about what 'path' means and what the returned memory usage looks like. It provides no such context, making the tool incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides no information about the 'path' parameter. It does not explain whether 'path' refers to a node path, file path, or something else. The description fails entirely to compensate for the absent schema descriptions.
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's action ('Get memory usage') and target resource ('a simulation'). It is specific enough to distinguish from general simulation tools like get_simulation_info, though it does not explicitly contrast with siblings.
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. The description does not mention context, prerequisites, or exclusions. It simply states what the tool does without situating it among sibling tools.
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. 'Get' implies a read-only operation, but the description does not disclose whether the tool triggers a cook, what data it returns, how errors are handled, or any side effects. The minimal detail does not add meaningful behavioral context beyond the tool name.
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 a single sentence with no wasted words and is front-loaded with the verb. It is concise, but it sacrifices necessary detail; however, the dimension rewards brevity and structure, and the sentence earns its place even though it is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is far from complete. With no output schema, no annotations, and only vague purpose, it leaves the agent without essential context about what 'simulation info' includes, what the output looks like, and how the path parameter should be used. Given the many sibling DOP tools, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description mentions 'DOP network', giving a partial hint that the 'path' parameter likely points to a DOP network, but it does not explain the expected format, required syntax, or further semantics. This adds only marginal value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('simulation info from a DOP network'), but 'simulation info' is vague and does not distinguish this from sibling tools like get_dop_object, get_dop_field, or get_sim_memory_usage, which could all be considered simulation info. The purpose is recognizable but lacks specificity.
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. The description only says what it does, not when it should be used or when other DOP-related tools would be more appropriate. There is no mention of exclusions, prerequisites, or alternatives.
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 does not mention side effects (e.g., references that may break), required permissions, or whether the rename is reversible. For a mutating operation, this is a significant gap, leaving the agent to infer safety and impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is concise and front-loaded. However, it is under-specified: while it communicates the basic action, it omits essential context about parameters and behavior, making it less effective than a slightly longer description that would benefit the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 2 parameters and no output schema, but the description provides almost no information to guide correct invocation. It lacks details on what 'path' means, what the new name should look like, or any constraints. For a rename operation in a complex 3D environment, this is insufficiently complete to ensure correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either parameter ('path' or 'new_name'). The agent cannot infer what values to supply or how they relate to the operation, making this a serious deficiency. The description adds no meaning beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Rename') and a clear resource ('a node'), which states the tool's function unambiguously. However, it does not differentiate from sibling tools like 'move_node' or 'copy_node' by mentioning scope or context, so it lacks the distinguishing detail that would merit a 5.
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?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It simply states the action without contextualizing its use case relative to other node operations.
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?
No annotations exist, so the description bears full responsibility for behavioral disclosure. It mentions 'create or apply' implying mutation, but doesn't explain whether it overwrites existing materials, creates new nodes, requires specific permissions, or what the side effects are. This is insufficient 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. However, it is so underspecified that it sacrifices necessary detail for brevity. It earns a middle score because while it is efficient, it omits critical context that could be added without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, 0% schema description coverage, no output schema, and no annotations, the description is far from complete. It doesn't explain material types, parameter object structure, or the distinction between creating vs applying. It covers only the most basic action, leaving the agent unable to correctly set up arguments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero parameter information beyond the schema's bare names. With schema description coverage at 0%, the description was the only chance to explain what 'parameters', 'material_type', or 'name' mean, but it fails to do so. Users are left completely in the dark.
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?
Description uses specific action verbs ('create or apply') and targets a specific resource ('material to an OBJ node'). While the double verb is slightly ambiguous, it does convey the core function and distinguishes from siblings like assign_material or create_material_network by specifying the OBJ node context.
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. There are many related sibling tools (assign_material, create_material_network, create_material_workflow) but no comparison or exclusion criteria provided. The description only states what it does, not when to choose it.
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, the description must fully disclose behavioral traits, but it only states the action. It does not mention whether it overwrites existing attributes, validates value types, or has any side effects, leaving a critical gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff, which is structurally clean. But it is also under-specified, providing only the bare minimum of context, so it earns a mid-range score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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, and no output schema, this one-line description is incomplete. It does not address input formats, interactions with USD prims, or what happens after setting the attribute, making it insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters. 'path' and 'prim_path' are ambiguous, and 'value' lacks type specifications. The agent gets little help in understanding what each parameter really represents.
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 action ('Set') and the resource ('USD attribute value'), making the primary purpose understandable. However, it does not differentiate from siblings like set_detail_attrib or set_parameter, which might also involve setting attribute-like values.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention context such as USD stage vs. other node types, nor does it provide any exclusions or prerequisites.
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, the description carries the full burden. It states what the tool does but fails to disclose any behavioral nuances such as whether it creates additional nodes, changes the scene graph, or requires special permissions. The 'workflow' aspect is entirely unexplained.
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 a single sentence that is concise and front-loaded with the core action. However, it is under-specified, which undermines the value of its brevity, but it does not contain wasteful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's name includes 'workflow' and there is a sibling simply named 'assign_material', the description should explain what the workflow entails. There is no output schema and no annotations, so the description is the only source of context, and it is insufficient to understand the tool's behavior or expected inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters, and the tool description provides no additional meaning for 'geo_path' or 'material_path'. Neither the schema properties nor the description explain what these paths refer to (e.g., object paths, asset paths, or node paths).
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 'Assign a material to a geometry node' uses a specific verb and resource, making the basic action clear. However, it does not distinguish this tool from the sibling 'assign_material' or explain the 'workflow' suffix, so it's not fully differentiated.
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?
There is no guidance on when to use this tool versus alternatives like 'assign_material', 'set_material', or 'create_material_workflow'. No context, prerequisites, or exclusions are provided.
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, the description carries the full burden of behavioral disclosure. It does not explain how parent_path is used, whether nodes are created under this path, what happens if nodes already exist, or any side effects such as overwriting existing chains. The structure of each node is partially described but without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is under-specified. It packs some structure info but omits critical details about parameters and behavior, so it is too terse to be considered well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too brief to be complete. It does not cover how the chain is built, error handling, or what the result of the operation is. The complexity of building a chain of nodes with connections and parameters requires more explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'nodes' parameter by specifying the structure of each entry as {type, name?, parameters?}, but it does not explain the 'parent_path' parameter at all. With 0% schema description coverage, the description fails to compensate for the undocumented parent_path.
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 it builds a chain of SOP nodes connected in sequence, distinguishing it from single-node creation (create_node) and generic connection tools (connect_nodes). The verb 'build' and resource 'chain of SOP nodes' are specific, but it doesn't mention what the tool returns or how the chain is used.
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 about when to use this tool versus alternatives like connect_nodes or create_node. There is no mention of prerequisites, context, or conditions where this tool is preferred.
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 indicates a mutation (connecting nodes) but does not disclose side effects like whether existing connections on the destination input are overwritten, whether scene changes are persisted, or any required node existence. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and free of filler. However, it is under-specifying: while concise, it omits essential parameter details, so the brevity comes at the expense of usefulness, making it merely adequate in structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description is far too thin. It does not explain the indexing parameters, the expected format of paths, or any return behavior. For a relatively simple but multi-parameter tool, this description is incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameter meanings. It references 'src' and 'dst' and 'output/input' but does not clarify that src_path and dst_path are node paths, nor does it explain the optional integer indices (dst_input_index, src_output_index). Parameters remain effectively undocumented.
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 ('Connect') and clearly states the resource and direction ('src output -> dst input'). This distinguishes it from sibling tools like connect_nodes_batch (batch operation) and disconnect_node_input (disconnection), making the 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as connect_nodes_batch or disconnect_node_input. It implies individual connection but does not state exclusions or prerequisites, leaving the agent to infer usage context from the name alone.
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?
No annotations are provided, so the description carries the full burden. It only says 'Create' without disclosing side effects, whether it modifies the scene, requires a specific parent context, or is reversible. For a mutation tool, this is a significant 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 a single, concise sentence with no redundant words, and it is front-loaded with the core action. However, given the need for more information (parameters, usage), it is arguably under-specified, reducing the score from 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and only 2 parameters, but the description barely explains what the node is or where it is created. It does not mention parent_path behavior, defaults, or any post-creation effects. The description is not sufficient for an agent to safely and correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either parameter (name or parent_path). It provides no hints about defaults, allowed values, or how these parameters affect the created node. The description fails to compensate for the lack of schema-level detail.
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 action (create) and the specific resource (a material network/matnet node), making it distinct from the generic create_node. However, it does not explicitly differentiate from other material-related tools like create_material_workflow, and lacks additional context about the node's role.
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?
The description provides no guidance on when to use this tool versus alternatives such as create_node or create_material_workflow. There is no mention of prerequisites, common scenarios, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without mentioning creation side effects, prerequisites, defaults, or expected behavior. There is no information about what happens upon success, failure, or how the node is created within the Houdini scene.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, but it is under-specified. While appropriately sized for a simple tool, the lack of any detail beyond the basic action makes it too brief to be fully useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 3 parameters, no output schema, and no annotations, this description is severely incomplete. It fails to explain key aspects such as what ROP stands for, the meaning of render_type options, the role of parent_path, or any side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not explain any of the three parameters (name, parent_path, render_type). Since the description adds no meaning beyond the schema, the agent has no insight into allowed values, defaults, or semantics.
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 'Create a ROP (render) node' uses a specific verb and resource, clearly indicating the tool's function. It distinguishes itself from generic create_node by specifying ROP (render) node, though it doesn't explicitly differentiate from create_node or other create_* 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 guidance is provided on when to use this tool versus alternatives like create_node, list_render_nodes, or setup_render. The description only states what it does, leaving the agent to infer usage context.
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 only states that it evaluates an expression and returns a result, but does not mention potential side effects, safety concerns, supported languages, or error behavior. For an expression evaluation tool, this is a notable 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 a single concise sentence with no wasted words, making it easy to parse. However, it is under-specified, so while it is structurally efficient, it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, no annotations, and no output schema, the one-sentence description is insufficient. It does not explain the language default, the meaning of the expression parameter, or what kind of result to expect. The description is not complete enough for an agent to invoke this tool reliably without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'expression' or 'language' parameters at all. It fails to explain what values are expected or how the language parameter affects behavior, leaving the agent without essential information to construct valid calls.
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 verb ('Evaluate') and resource ('Houdini expression') and mentions the outcome (return the result). It is specific enough to distinguish from many siblings, though it doesn't explicitly differentiate from similar tools like execute_hscript or execute_houdini_code.
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?
The description provides no guidance on when to use this tool versus alternatives like set_expression, get_expression, or execute_hscript. There is no mention of use cases, prerequisites, or exclusions, leaving the agent to infer context from the name alone.
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, the description carries the full burden of behavioral disclosure. It implies a read-only scan, but does not specify whether cooking is triggered, what side effects may occur, or how errors/warnings are reported. This lacks transparency for an operation that could potentially be expensive or have 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient, but it is under-specified for a tool that should explain its scope and output. It earns a middle score because it is not verbose but sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should explain what the tool returns (e.g., a list of nodes with errors/warnings). It does not, and it also fails to place the tool within the broader context of node hierarchy inspection. The description is adequate for a trivial tool but incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description adds no meaning to the root_path parameter beyond its name and default. Although a single obvious parameter might seem self-explanatory, the description does not clarify the expected format, semantics, or impact of the root_path, leaving a gap that the description should fill.
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's purpose: scanning the node hierarchy for cook errors and warnings. It uses a specific verb ('scan') and identifies the resource, distinguishing it from tools like find_nodes or get_cook_chain, though it doesn't explicitly name any sibling alternatives.
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 such as find_nodes or get_network_overview. The description only states what it does, leaving the agent to infer appropriate usage context.
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, but it only restates the operation. It does not explain what 'members' refers to, how group_type affects the result, or what happens on invalid input, leaving the agent without essential behavioral context.
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 extremely concise and front-loaded, using a single sentence with no filler. However, it borders on under-specification, providing only the bare minimum and requiring the agent to infer everything else.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no annotations, and no output schema, this description is insufficient. It fails to explain group_type options, return value format, or error behavior, leaving significant gaps for the agent to navigate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its three parameters, and the description adds nothing about node_path, group_name, or group_type. The meaning of group_type (e.g., point/prim/vertex) is entirely implicit, so the agent cannot determine valid values or their impact.
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 action ('Get') and resource ('members of a geometry group'), making the tool's primary purpose unambiguous. However, it does not explicitly distinguish itself from sibling tools like get_groups or get_points, so it misses the top score.
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 usage guidance is provided. The description does not mention when to use this tool versus alternatives such as get_groups or get_points, nor does it state any prerequisites or caveats.
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?
No annotations are provided, so the description carries the full burden of disclosing behavior. It merely says 'Get detailed info' without specifying output format, potential errors, or any side effects. The description adds little beyond the tool's name.
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 a single sentence of eight words, direct and free of unnecessary content. It is appropriately sized for a simple getter, though its brevity sacrifices informative detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters and no annotations or output schema, a one-sentence description is insufficient. It doesn't explain what 'detailed info' includes, what node_type values are valid, or how to handle missing category.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0% for two parameters (node_type, category), and the tool description does not mention either parameter. It fails to clarify what node_type should be or how category affects the lookup, leaving the agent without adequate guidance.
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 action (get) and resource (HDA definition), but it does not differentiate from sibling tools like get_hda_sections or get_hda_section_content, which also target HDAs. The scope of 'detailed info' is vague and could overlap with other getters.
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?
The description provides no guidance on when to use this tool over alternatives. It lacks context on use cases, prerequisites, or exclusions, leaving the agent to infer when it should be invoked.
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, the description alone must convey behavioral traits. It only states that nodes are listed, without disclosing whether the search is recursive, what 'cache data' means, or what the output format is. This leaves significant ambiguity.
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 a single, front-loaded sentence with no wasted words. It is concise and easy to parse, though it sacrifices detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple parameter set and absence of annotations/output schema, the description is too sparse. It fails to explain root_path semantics, output shape, or how this listing relates to other cache operations, leaving the agent with incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter root_path is not mentioned in the description, and schema description coverage is 0%. The description adds no meaning beyond the schema, leaving the parameter's purpose and default scope unclear.
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 lists nodes with cache data, which is a specific verb and resource. It is distinguishable from cache-related siblings like clear_cache and write_cache, though it does not explicitly contrast with get_cache_status.
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 like get_cache_status or clear_cache. The description gives no context for appropriate use cases or exclusions.
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?
No annotations are provided, so the description carries full responsibility. It only says 'Get details' without specifying what details are included, whether include_attrs affects output, or any other behavioral context.
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 a single concise sentence with no fluff. It is appropriately sized but lacks additional useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no output schema, and no annotations, the description is too sparse. It doesn't clarify what 'details' are returned or how the tool relates to similar get/list prim tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no information about the parameters (path, prim_path, include_attrs). The description fails to compensate for the lack of schema-level documentation.
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 retrieves details of a specific USD prim, using a specific verb and resource. However, it doesn't distinguish itself from similar siblings like get_usd_prim_stats or list_usd_prims.
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?
There is no guidance on when to use this tool versus the many overlapping get/list tools. No alternatives or exclusions are mentioned.
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, the description carries the full burden of behavioral disclosure. It states that the tool sets content but does not disclose whether it overwrites existing content, requires special permissions, or what happens if the section does not exist. For a mutation tool, this is a significant 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 a concise, single sentence with no wasted words. It is front-loaded with the verb and resource. However, it is perhaps too terse given the tool's complexity, though this dimension rewards efficiency, so 4 is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters, no output schema, and no annotations. The description provides minimal context: it does not explain return values, side effects, or parameter relationships. For a complex mutation tool, the description is incomplete and should provide more context to be useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (content, category, node_type, section_name). The parameter names hint at their roles, but the description adds no semantic value beyond what the schema already shows, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (set) and identifies the resource (content of an HDA section), clearly distinguishing it from the getter sibling get_hda_section_content. However, it does not elaborate on what constitutes an HDA section or content, which may be ambiguous for non-HDA users.
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 like get_hda_section_content or update_hda. The description gives no context about prerequisites, typical scenarios, or scenarios to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is extremely terse and does not disclose what setting up an RBD simulation entails—whether it creates DOP nodes, modifies the scene, or has other side effects. With no annotations, the description carries full responsibility for behavioral transparency and fails to provide any such details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and free of fluff, but is perhaps too brief. It is a single sentence that, while easy to read, sacrifices necessary detail for brevity, making it less useful than a more balanced description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's likely complexity as a simulation setup and the absence of annotations and an output schema, the description is far from complete. It fails to cover prerequisites, configuration options, expected outcomes, or how the simulation is initialized, making it inadequate for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter description coverage, and the description only vaguely references 'source geometry', which maps to the required source_path. It does not explain the 'name' or 'parent_path' parameters, leaving essential parameter semantics undescribed.
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 'Set up' with resource 'RBD simulation', clearly identifying the tool's function. It distinguishes the tool from sibling setup tools like setup_pyro_sim, setup_flip_sim, and setup_vellum_sim by explicitly naming the physics type.
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 about when to use this tool versus alternatives. The description does not mention contexts, prerequisites, or why an RBD simulation would be chosen over other simulation types.
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 disclosure. It only states that it adds a spare parameter and lists allowed types, but does not explain side effects, persistence, error conditions, or return behavior.
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 at two sentences and is easy to skim. It front-loads the primary action, though it could be slightly more structured to cover parameter roles.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations, yet the description provides only a basic action and type list. It fails to explain parameter formats, defaults, or expected outcomes, making it insufficient for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'Types: float, int, string, toggle' which adds meaning to parm_type, but the other params (node_path, name, label, default) are not explained. With 0% schema coverage, this leaves most parameters under-specified.
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 verb (Add) and resource (spare parameter) with a target node, and it lists allowed types. However, it does not explicitly differentiate from the sibling tool create_spare_parameters (plural), which likely handles batch creation.
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 like set_parameter or create_spare_parameters. There is no mention of prerequisites, scenarios, or exclusions.
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, the description must disclose side effects and behavior, but it only says 'Create a wrangle.' It does not clarify whether a new SOP node is created, whether parent_path must exist, whether existing attributes are overwritten, or how errors are handled. The absence of such details leaves significant behavioral ambiguity.
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 a single, front-loaded sentence with no wasted words. It immediately states the action and purpose, making it easy to parse. While brevity means missing details, the structure itself is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and four parameters, the description is too sparse for reliable use. It does not explain return values, node creation behavior, run_over semantics, or how this relates to sibling wrangle tools. The information provided is a starting point but insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 must compensate by explaining parameters. It mentions 'VEX expression' and 'attribute,' which map to expression and attrib_name, but parent_path and run_over are left unexplained. Parameter names are somewhat self-explanatory, but the description adds minimal semantic value for the required context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Create a wrangle that evaluates a VEX expression into an attribute.' It clearly states the tool's core function and distinguishes it from more generic wrangle creation by emphasizing the expression-to-attribute behavior. However, it does not explicitly contrast with the closely related 'create_wrangle' sibling, so it falls short of full differentiation.
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?
There is no explicit guidance on when to use this tool versus alternatives like create_wrangle, set_wrangle_code, or evaluate_expression. The description implies a use case (creating a wrangle for expression evaluation), but it does not state exclusions, prerequisites, or when another tool would be more appropriate.
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 disclosing behavior. It mentions what the output includes (type, non-default parms, connections), which gives some idea of the return content, but it does not mention error conditions, side effects, or performance implications. This is minimal 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 a single, well-structured sentence that is front-loaded with the action ('Get') and the resource ('a node'). Every word contributes meaning, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description should clarify the meaning of 'path' and ideally give examples of what the explanation looks like. It only lists the included fields but not their structure or format. The lack of parameter semantics makes the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'path' parameter with no description, and the schema description coverage is 0%. The description does not mention 'path' at all, leaving the user to guess how to specify the node. The description fails to compensate for the missing schema information.
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's function: 'Get a human-readable explanation of a node' and specifies the key output contents (type, non-default parms, connections). This distinguishes it from many sibling tools, though it could more explicitly differentiate from similar tools like get_node_doc or get_changed_parms.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention situations where other tools would be better, and no exclusions or prerequisites are stated.
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, the description carries the full burden of behavioral disclosure. It only says 'Get', which implies a read operation, but it does not disclose return format, error behavior, whether the field is returned as a scalar or object, or any side effects. This is insufficient for a tool with no structured annotations.
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 a single concise sentence with no filler or redundant wording. It is front-loaded with the core action, but it could still include more helpful context (e.g., parameter clarification) without becoming verbose. However, as a purely efficient statement, it scores well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and annotations, and the description does not fill this gap. It does not state what the function returns (e.g., the field value, a dictionary, an error), how errors are handled, or when this should be used in a Houdini workflow. For a tool with three required parameters and no structured documentation, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining any of the three parameters (path, object_name, field_name). While the names are somewhat self-explanatory, 'path' is ambiguous and there is no context about what these mean in relation to a DOP object. The description adds no semantic value beyond the parameter names.
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 verb 'Get' and the resource 'a specific field from a DOP object', which accurately defines the tool's purpose. It distinguishes from sibling tools like get_dop_object by emphasizing 'specific field', 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_dop_object or list_dop_objects. The description simply states what it does without any contextual usage advice, so the agent must infer appropriate scenarios.
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?
No annotations are provided, so the description must carry the burden of disclosing side effects and safety. The word 'get' implies a read-only operation, but the description does not explicitly state that it is non-destructive, whether it can fail, requires special permissions, or what side effects (if any) it has. This is similar to the update_drive example where transparency scored 2.
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 extremely concise with no fluff, and the key action is front-loaded. However, it is under-specified, but that is a completeness issue, not a conciseness one. For a simple tool, a one-sentence description can be acceptable, but the sentence is almost too minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and only a 2-parameter schema, the description is still too sparse. It does not explain what the tool returns, how to interpret the section names, or how the parameters affect the result. The context is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the parameters. It does not explain what 'node_type' or 'category' mean, nor how they relate to the HDA being queried. The description only hints that the tool works on an HDA, but leaves the two parameters poorly understood.
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 states the tool gets the section names of an HDA, which is a specific verb and resource. It clearly distinguishes from sibling tools like get_hda_section_content (which gets content) and hda_get (which likely gets HDA data). However, it doesn't explicitly mention alternatives or provide further context on what 'sections' means, so it's not a 5.
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 vs alternatives. There is no mention of prerequisites, when to choose get_hda_sections over other HDA-related tools, or any exclusions. The description simply states what it does without context.
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, the description must fully disclose behavioral traits. It only says 'inspect' without specifying return value, side effects, or error behavior for invalid indices. This leaves significant uncertainty about what the tool actually does beyond the tagline.
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 a single, compact sentence that front-loads the core action. It contains no fluff or repetition, though its brevity leads to omission of useful details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description leaves major gaps: what does inspection return, what is the layer stack, and what does 'path' refer to? The tool is part of a large family of USD tools, and this description does not provide enough context for an agent to confidently select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, and the tool description only partially explains the 'layer_index' parameter via 'by index'. The 'path' parameter is left implicit and not described as a file path or stage identifier. The description does not adequately compensate for the complete lack of parameter documentation.
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 action ('Inspect') and the target resource ('specific USD layer') with a specific qualifier ('by index in the stack'). This distinguishes it from other layer inspection tools like lop_layer_info by focusing on index-based access. However, 'the stack' is not explicitly defined, which introduces slight ambiguity.
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 such as lop_layer_info or get_usd_composition. The description lacks any exclusions, prerequisites, or contextual hints about the layer stack.
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?
There are no annotations, so the description carries the full burden of disclosing behavior. It only says 'list all materials,' implying a read operation, but it does not reveal the return format, whether sub-networks are included, or what happens if the path is invalid. This is minimal disclosure.
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 a single sentence with no fluff, making it concise and front-loaded. However, it is overly terse, sacrificing necessary detail about parameters and outputs for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (1 optional param, no output schema, no annotations), the description is still incomplete. It fails to explain what a 'material' is, what the return value looks like, or what the mat_path parameter expects. The absence of an output schema makes this a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has mat_path with a default of '/mat' and no descriptions. The tool description does not explain mat_path beyond the generic 'material network' context. With schema description coverage at 0%, the description fails to compensate for the missing parameter meaning.
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 'List all materials in a material network' clearly identifies the verb (list) and resource (materials in a material network). It is specific enough to distinguish from get_material_info, which targets a single material, though it does not explicitly mention this distinction.
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 about when to use this tool versus alternatives like list_material_types or get_material_info. The description only states what it does, leaving the agent without clear selection criteria.
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 only states 'Lock or unlock a parameter' without explaining what locking entails, side effects, reversibility, or required permissions. This is a significant gap for a mutating 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 a single concise sentence that conveys the core action without wasted words. It is appropriately sized for a simple tool, though it lacks context that would make it more helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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, the description should offer more context. It fails to explain the meaning of locking/unlocking or the parameter roles, leaving gaps in how an agent should correctly invoke the tool. For a simple mutating tool, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It does not mention node_path, parm_name, or locked, nor does it explain how they relate to the lock/unlock action. The parameter names are self-explanatory to some extent, but the description adds no value 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 uses specific verbs 'Lock or unlock' and identifies the resource as 'a parameter', clearly distinguishing this tool from siblings like set_parameter or link_parameters. However, it does not explicitly differentiate itself from these alternatives beyond the action, so it lacks a 5.
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. The description simply states the action without any context on use cases, prerequisites, or exclusions, which leaves the agent without direction for selection.
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 provided, the description must disclose behavior on its own. It does disclose a serious crash risk (WinError 10054) and the required allow_dangerous=True flag, which is valuable. However, it doesn't describe other potential side effects, prerequisites, or the exact nature of the crash beyond the error code.
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 two sentences long, with the purpose front-loaded and the warning as a separate sentence. It is efficient and gets to the point, though additional parameter information would be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters with no schema descriptions, no annotations, and no output schema, placing a heavy burden on the description. The description only covers the basic purpose and the danger flag, leaving the user without essential context about parameters, return value format, and appropriate usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain the six parameters. It only mentions allow_dangerous and implies render_path is the output (though it's an input). The other parameters (rotation, karma_engine, orthographic, render_engine) are entirely unexplained.
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 renders a single view in Houdini and returns the rendered image path, using a specific verb and resource. It distinguishes itself from multi-view or camera-specific render tools by the phrase 'single view', though it doesn't 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like render_quad_views or render_specific_camera. The only conditional information is the danger warning, which is not a usage guideline.
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, the description must disclose safety and side-effect details, but it only states the high-level action. It does not explain whether the reset is destructive, if it triggers a cook, clears memory, or what 'initial state' entails for different simulation types.
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 a single sentence that is front-loaded and efficient. However, it may be too terse given the lack of annotations and parameter explanation, but it earns a 4 for being concise without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and no annotations, the description should explain what resetting entails, what the path parameter is, and any side effects. It lacks these details, making it incomplete for an agent to invoke correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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, but it does not explain what 'path' refers to (node path, file path, simulation object?) or provide format examples. The description implies the simulation to reset but leaves the parameter meaning ambiguous.
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 'Reset a simulation to its initial state' uses a specific verb (reset) and resource (simulation), clearly indicating the core action. It differentiates from sibling tools like step_simulation or setup_*_sim, though it doesn't explicitly contrast with them.
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 vs alternatives like step_simulation or get_simulation_info. The description does not mention prerequisites, side effects, or contexts where resetting is appropriate.
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?
Annotations are absent, so the description bears the full burden. It discloses the mutation ('Set') but does not explain side effects, whether the change is scoped, or how it affects subsequent operations. This is minimal transparency for a state-changing tool.
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 a single, well-structured sentence with no filler. It is front-loaded with the action verb. However, it is so brief that it sacrifices valuable guidance, which reduces its score slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no annotations or output schema, the description is too sparse. It does not explain the role of the 'current network path' in the broader tool ecosystem, when to use it, or what the user can expect after invocation. This leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must define the 'path' parameter. It hints that the value is a network path within the editor, but does not provide format, syntax, or examples. This adds marginal meaning beyond the raw schema but is insufficient for correct invocation.
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 action ('Set') and the resource ('current network path') plus the context ('in the network editor'). It distinguishes from sibling setters like set_parameter or set_selection by targeting a specific Houdini concept. However, it could be more precise about what constitutes a 'network path'.
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 about when to use this tool versus alternatives. There is no mention of prerequisites, context, or common workflows. The description only states what it does, leaving the agent without cues for selection among many related tools.
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 disclosing side effects. It only states the action and supported languages, with no mention of whether existing expressions are overwritten, whether parameter permissions matter, how cooking is affected, or what the return value is. This is a significant transparency gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two short sentences with no fluff. The first sentence states the core action, and the second adds a useful detail about language values. It is efficiently structured, even though it lacks depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation with no annotations and no output schema, the description is overly minimal. It fails to explain expected results, prerequisites (e.g., parameter existence), side effects on the scene, or error conditions. Context is significantly incomplete for an agent to invoke it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning only for the 'language' parameter by specifying allowed values ('hscript' or 'python'), which the schema does not provide. However, it provides no semantic guidance for node_path, parm_name, or expression, leaving most parameters under-documented.
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's action ('Set an expression') and resource ('node parameter'), which differentiates it from value-setting tools like set_parameter. However, it does not explicitly distinguish from sibling tools such as get_expression or lock_parameter, so it lacks the explicit sibling differentiation that would merit a 5.
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?
The description offers no guidance on when to use this tool versus alternatives like set_parameter or evaluate_expression. It does not mention use cases, prerequisites, or when to prefer one language over the other. The language note is a parameter hint, not usage guidance.
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, the description carries the full burden of disclosing behavior. It states the action but does not reveal whether existing keyframes are overwritten, what happens if the parameter is not keyframable, or whether the operation returns anything. The phrase 'set' implies mutation, but important side effects and prerequisites are omitted.
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 a single, front-loaded sentence with no unnecessary words. It is appropriately concise for a straightforward tool, though it is arguably under-specified; however, conciseness is not the issue here. It scores slightly below 5 because it could have included a brief clause about parameters without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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, no output schema, and zero schema descriptions, this description is severely incomplete. It does not explain the meaning of the required parameters, expected value types, or any return behavior. An agent would struggle to invoke this tool correctly without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameter meanings. It does not. The description only mentions 'parameter' and 'frame' generically, without clarifying how node_path, parm_name, frame, and value should be provided or what formats/ranges are expected. No additional semantics beyond the schema titles are given.
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 specifies the action: 'Set a keyframe on a parameter at a specific frame.' It uses a specific verb ('set') and resource ('keyframe on a parameter'), and explicitly mentions 'a specific frame,' which distinguishes it from the sibling set_keyframes (plural). The singular 'a keyframe' helps differentiate from batch operations.
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 like set_keyframes, delete_keyframe, or set_parameter. The description only implies the basic scenario of setting a single keyframe but does not mention exclusions or conditions (e.g., parameter must be animatable, or when to prefer set_keyframes).
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, the description carries full burden for behavioral disclosure. It only states what the tool does, but does not mention side effects (e.g., overwriting existing values), error conditions, required permissions, or return behavior. This leaves significant gaps about what happens when the tool is invoked.
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 a single sentence with no filler or redundant text. Every word contributes to the core meaning, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool, the description is minimal but misses key contextual details such as how 'value' is interpreted (int, string, expression), whether setting a parameter may trigger a cook, and how node_path is specified. Given there is no output schema or additional documentation, the description is insufficient for an agent to use it correctly in edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters (value, node_path, parm_name). Even though the parameter names are somewhat self-explanatory, the description adds no semantic meaning about value types, formats, or relationships between parameters.
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 ('Set') and resource ('parameter value on a node'), and the word 'single' distinguishes it from sibling tool 'set_parameters' which handles multiple parameters at once. This clearly states what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 like set_parameters, set_expression, or set_keyframe. The description gives no context for tool selection, prerequisites, or situations where this should be preferred.
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, the description carries full burden but only states the action. It does not disclose side effects, required permissions, whether nodes are created, or any reversibility. This is minimal disclosure 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence and front-loaded, but it is under-specified. While concise, it lacks critical detail and does not effectively use its length to communicate important information beyond the basic action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter mutation tool with no output schema and no annotations, the description is incomplete. It does not explain the return behavior, what 'set up' entails, or any necessary context about the simulation setup process, leaving major gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the three parameters. 'source geometry' hints at source_path, but name and parent_path are completely unexplained, leaving the agent without necessary parameter semantics.
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 action ('Set up') and specific resource ('Pyro simulation') with an input source ('source geometry'). It distinguishes from sibling setup tools like setup_rbd_sim, setup_flip_sim, and setup_vellum_sim by naming Pyro explicitly.
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 does not mention exclusions, prerequisites, or compare to related setup tools, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only that it sets up a Vellum simulation, with no details about node creation, side effects, required context, or return behavior. This is insufficient for a setup tool.
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 a single sentence, which is concise and front-loaded. However, it sacrifices essential information; despite being short, it doesn't fully exploit the space to add value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description is severely incomplete. It does not describe the setup process, parameter semantics, or expected outcomes, making it hard 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on any parameters. The schema defines name, sim_type, parent_path, and source_path, but the description adds no meaning to these, leaving the agent to infer parameter purposes from names alone.
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: setting up a Vellum simulation for cloth, hair, or grain. It uses a specific verb ('set up') and resource ('Vellum simulation'), and distinguishes it from sibling simulation setup tools like setup_pyro_sim, setup_rbd_sim, and setup_flip_sim.
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 use for Vellum simulations but does not explicitly state when to use this tool over alternatives or provide exclusions. There is no mention of prerequisites, conditions, or alternative tools, so usage context is only inferred.
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 mentions the side effect of setting 'shop_materialpath' but does not clarify prerequisites, whether existing material assignments are overwritten, or any potential failure modes. This is thin 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 a single, compact sentence that conveys the operation and the underlying mechanism with no verbosity. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It does not mention when to use it, what happens to the node, or the return value, which is critical for an agent to invoke it correctly in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameter semantics. It implies 'node_path' is the target node and 'material_path' is the value for 'shop_materialpath', but it does not explicitly map these or elaborate on path formats, leaving significant ambiguity.
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 states a specific action ('Assign a material to a node') and the mechanism ('by setting shop_materialpath'), making the tool's purpose clear. However, it does not distinguish this tool from the sibling 'set_material' or 'assign_material_workflow', so it misses the differentiation needed for a 5.
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 given on when to use this tool versus alternatives like 'set_material' or 'assign_material_workflow'. The description only states what it does, not the context or exclusions, leaving the agent to infer usage from the name.
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 explaining behavior. It only states that stdout/stderr are returned, but fails to disclose that executing arbitrary HScript commands can modify the scene, have side effects, or require specific permissions. This is a significant transparency gap for a command-execution 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 a single, clear sentence that directly communicates the tool's purpose with no redundant words. It is appropriately concise and front-loaded, fully earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and the tool's potential for arbitrary code execution, the description is incomplete. It does not explain return format (beyond mentioning stdout/stderr), error behavior, side effects, or when to use this tool relative to the numerous sibling tools. The description is minimally viable but leaves out critical context for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'command' with 0% description coverage, so the description must compensate. It does not elaborate on what constitutes a valid HScript command, how formatting should be handled, or any constraints. The parameter name is self-explanatory, but the description adds no semantic value 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 'Execute an HScript command and return stdout/stderr' clearly identifies the action (execute) and resource (HScript command) with a specific outcome. However, it does not differentiate itself from the sibling tool 'execute_houdini_code', which likely has similar semantics, so it misses the full 5 for sibling distinction.
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?
The description provides no guidance on when to use this tool versus alternatives like execute_houdini_code or evaluate_expression. There is no context on prerequisites, intended scenarios, or scenarios where another tool should be preferred.
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, the description carries full responsibility for behavioral disclosure. It adds the useful context that coordinates are in world space, but omits critical behaviors such as return value format, behavior on empty geometry, error handling, or whether the point index or position is returned. This leaves the agent guessing about side effects and output.
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 a single sentence with no redundant words. It is front-loaded with the main action and resource. For a tool with such a simple signature, this economy is appropriate, even though content depth is lacking.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two required parameters, no output schema, and no annotations, so the description must provide comprehensive context. It only states the basic purpose and world-space coordinate system. It fails to explain return values, error conditions, node_path interpretation, or any prerequisite state (e.g., cooked geometry). This is severely incomplete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and no descriptive text, the parameter semantics are almost entirely undefined. The description mentions 'position' but does not clarify the array order (e.g., x,y,z) or units. 'node_path' is completely unexplained, and the description adds no meaningful information about either parameter beyond their 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 uses a specific verb ('Find') and resource ('nearest point to a given position in world space'), clearly distinguishing it from siblings like get_points which returns all points. The scope is unambiguous and immediately conveys the tool's core function.
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. There is no mention of prerequisites, such as requiring a cooked geometry, nor exclusions for cases where get_points or other query tools might be more appropriate. The single sentence only states what it does, not when to choose it.
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 does not state that the operation is read-only, what happens if the attribute does not exist, whether the result is a list or dictionary, or if any side effects (e.g., cooking) occur. The description only repeats the core purpose and provides a parameter hint.
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 extremely concise: two sentences with no redundant wording. It front-loads the action and uses the second sentence to clarify a key parameter. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, this description is not complete enough for an agent to fully understand the tool's behavior. It lacks information about return format, edge cases, and side effects. The complexity is low, but the description still leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially does for attrib_class by listing valid values ('point, prim, detail'), which adds meaning beyond the schema. However, node_path and attrib_name are not described beyond their names, leaving a semantic gap for those parameters.
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 states a clear action and resource: 'Get all values of a geometry attribute.' This establishes what the tool does. However, it does not distinguish this tool from closely related siblings like get_geo_summary or get_prim_intrinsics, which also read geometry data.
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?
The description gives no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or typical scenarios. The only extra information is a list of valid attri_class values, which is parameter guidance rather than usage context.
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, the description must disclose side effects and behavior. It only states that it retrieves geometry, but doesn't explain whether the COP node is cooked, what data format is returned, or if there are performance implications. This is insufficient for a data-fetching 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 a single, clear sentence of six words, making it maximally concise. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's dependence on a specific path and the existence of multiple COP-related siblings, the description is too sparse. It lacks information about return value structure, error scenarios, and when to choose this over get_cop_info or get_cop_vdb.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required 'path' parameter with zero description coverage. The tool description does not mention the parameter or its expected format (e.g., Houdini path syntax). The agent must infer its meaning solely from the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and names the resource 'geometry data' from a 'COP node', clearly distinguishing it from generic geometry tools like get_geo_summary or get_cop_info. However, it doesn't specify the exact nature of the geometry data (e.g., points, volumes).
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?
There is no guidance on when to use this tool versus sibling tools such as get_cop_info or get_cop_layer. The description provides no context about prerequisites, alternatives, or typical use cases.
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?
No annotations are provided, so the description must carry the full burden. It only says 'Get', implying a read operation, but gives no detail about what 'VDB info' entails, whether it requires a specific node type, or any side effects/error behavior. Minimal disclosure.
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 a single, efficient sentence that clearly identifies the tool's purpose with no wasted words. It is well-front-loaded, though it could arguably be too terse to be fully useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is too thin. It does not explain what VDB info is returned, what format, or how to specify the path. Given the large set of sibling COP tools, more context is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required 'path' parameter with no description, and schema description coverage is 0%. The description does not mention the parameter at all, so the agent gets no help understanding what path should refer to (COP node path vs VDB file path).
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 states a specific verb ('Get') and resource ('VDB info from a COP node'). It is clear and distinguishable from sibling COP tools like get_cop_info or get_cop_geometry, though it doesn't explicitly differentiate itself.
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?
Usage is implied: use when you need VDB information from a COP node. However, there is no guidance on when not to use it, prerequisites, or alternatives among the many sibling get_cop tools.
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?
No annotations are provided, so the description must carry the full burden. It only states 'Get info' without disclosing what information is returned, whether the operation is read-only, or how errors are handled (e.g., if the object does not 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 a single, front-loaded sentence with no wasted words. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description is incomplete. The generic 'info' does not specify what data will be returned, and the lack of parameter guidance makes it insufficient for an agent to confidently invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the 'path' or 'object_name' parameters. While the parameter names give some hint, the lack of any additional detail leaves ambiguity about formats or expected values.
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 'Get info about a specific DOP object' clearly identifies the action (get info) and the resource (a specific DOP object). It distinguishes itself from list_dop_objects by emphasizing specificity, though 'info' remains vague about what details are included.
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?
The description provides no guidance on when to use this tool versus alternatives like get_dop_field or get_dop_relationships. No context, prerequisites, or exclusions are mentioned.
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?
No annotations are provided, so the description carries full responsibility for behavioral transparency. It only states the high-level purpose and does not disclose the return format, whether it includes node types or connection details, potential performance implications, or any side effects. For a read-only tool this is a moderate gap but leaves much to inference.
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 a single sentence with no redundant words, front-loading the main action. It earns its place by stating the tool's core function, though it is slightly under-specified. The brevity is appropriate for a simple tool, but it sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter and no output schema, the description is not sufficiently complete. It fails to explain the 'path' parameter, the structure of the returned overview, or any limitations (e.g., scope of 'all nodes'). While the tool seems simple, the lack of parameter and output details leaves the agent uncertain about the invocation and expected response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional 'path' parameter with default '/obj', but has 0% description coverage. The tool description does not mention 'path' at all, leaving the agent to guess its meaning (likely the network path to query). This is a critical gap since the parameter's effect on the result is entirely unexplained.
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 resource ('overview of all nodes in a network with their connections'). This is specific and distinguishes it from siblings like get_scene_summary (scene-wide) and get_node_info (single node), as it focuses on the network-level overview with nodes and connections.
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. There is no mention of suitable scenarios, exclusions, or how it differs from similar tools like get_scene_summary or get_selection. The usage context is only implied by the description's mention of 'network' and 'overview'.
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, the description carries the full burden. It only states that it returns a JSON string, but does not disclose the nature of the info, whether it has side effects, or any performance implications. The read-only aspect is implied but not made explicit.
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 very concise with two short sentences. It is front-loaded and contains no filler, but it is slightly under-specified in a way that affects clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no parameters, so the description is the only source of information. It fails to define what 'scene info' includes, making it incomplete for an agent to reason about the tool's capabilities.
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 the schema is empty. The description adds nothing about parameters, but none are needed, so the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action (ask Houdini for scene info) and notes the return format (JSON string), but 'scene info' is vague and does not specify what data is included. It does not distinguish itself from sibling tools like get_scene_summary or get_geo_summary.
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. There is no mention of prerequisites, typical scenarios, or exclusions, leaving the agent without context for selection.
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 full responsibility for disclosing behavioral traits. It does not explicitly state that this is a read-only operation, nor does it mention any side effects, return format, or limitations. The term 'List' implies a benign query, but the description lacks explicit transparency.
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 a single, brief sentence with no fluff, making it highly concise. However, it is perhaps too terse, omitting necessary details like parameter semantics. Still, for what it covers, it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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, the description should compensate by explaining the required parameter and return behavior. It provides only a high-level statement of functionality, leaving the tool incomplete for an agent to use correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has one required parameter 'path' with no schema description (coverage 0%). The description does not mention the parameter at all, leaving its meaning and format entirely undocumented. This is a critical gap since the parameter is required.
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 ('list') and resource ('DOP objects') with a clear scope ('in a simulation'), which clearly differentiates it from sibling tools like list_materials or get_dop_object. The purpose is unambiguous and immediately understandable.
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?
There is no guidance on when to use this tool versus alternatives. The description only states what it does, without providing context on when listing DOP objects would be appropriate or how it differs from similar list tools.
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 must disclose behavioral traits. It implies a read-only operation ('Get info') but does not explain what 'layer stack info' includes, what node types are valid, how errors are handled, or what the return structure looks like. The absence of any safety or side-effect disclosure beyond 'Get' is insufficient.
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 a single, front-loaded sentence that directly communicates the core action and target. Every word earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, no output schema, and no annotations, so the description must be self-sufficient. However, it fails to define 'layer stack info,' clarify the path parameter, or differentiate from closely related tools. For an agent to invoke this correctly, it would need to guess at return values and parameter semantics, making the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'path' parameter with 0% documentation coverage. The description mentions 'from a LOP node,' which hints that 'path' likely refers to a LOP node path, but it does not specify path format, whether it is a scene path vs. file path, or any constraints. This is only minimal compensation for the missing schema documentation.
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 'Get USD layer stack info from a LOP node,' combining a specific verb ('Get') with a resource ('USD layer stack info') and target ('LOP node'). It distinguishes from siblings like lop_stage_info or get_usd_composition in topic, but does not explicitly reference alternatives or edge cases.
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?
The description provides no guidance on when to use this tool versus alternatives such as inspect_usd_layer or get_usd_composition. It only restates the purpose, leaving the agent to infer usage context from the tool name and one-line description.
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, the description fully bears responsibility for disclosing behavioral traits. It fails to mention whether the operation is read-only, whether it triggers cooking, or what happens if the path is invalid or the network is mid-cook. Minimal behavioral context beyond the literal 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 a single clear sentence with no wasted words. It front-loads the action and object, making it easy to parse quickly. Perfectly concise for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 an output schema, the description leaves significant gaps. It does not explain the return structure, possible statuses, or edge cases (e.g., network not cooked, errors). While the tool is simple, the lack of behavioral output details makes it incomplete for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'for a TOP network,' implying the 'path' parameter refers to a TOP network node, but it does not specify path format, required context, or expectations. Adds minimal value beyond the raw 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 the tool retrieves cook status and work item counts for a TOP network, using an explicit verb ('Get') and resource. It distinguishes from siblings like pdg_cook (which likely triggers cooking) and pdg_workitems (which may list actual work items), 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 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, prerequisites, or exclusions. The description simply states what it does without contextual direction, leaving the agent to infer usage based on the tool name and siblings.
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 to cover safety or side effects, the description carries full burden. It only states the operation without disclosing what happens to existing expressions, keyframes, or overrides on the parameter. This lack of behavioral detail is significant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple tool, though it lacks any supplementary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 params) but no annotations or output schema, the description should at least mention return behavior or side effects. It does not, leaving the tool under-specified for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (node_path, parm_name) but the description provides no additional meaning. Schema description coverage is 0%, and the description does not compensate by explaining the format or expected values for either parameter.
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 ('Revert') and a clear resource ('a parameter to its default value'), which distinctly distinguishes it from sibling tools like set_parameter or get_parameter. There is no ambiguity about what the tool does.
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?
The description provides no guidance on when to use this tool versus alternatives such as set_parameter or lock_parameter. It does not mention context like resetting overrides or clearing expressions, leaving the agent to infer use cases.
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?
No annotations are provided, so the description must disclose behavioral traits. It hints at mutation ('Update') but does not reveal whether this overwrites existing definitions, requires specific permissions, affects the current HDA, or has side effects. The risk of modifying an HDA definition is not addressed.
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 a single, focused sentence with no filler. It conveys the core action and source clearly in 9 words, making it easy to parse and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a one-parameter mutation tool with no annotations or output schema, yet the description provides minimal context. It lacks information about when to use it, side effects, required context, or expected outcome, leaving the agent underinformed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter, node_path, but the description does not mention it directly. The phrase 'from its current node contents' implies that the node_path refers to a Houdini node, offering some context, but it does not explicitly explain the parameter's role or format. Since schema coverage is 0%, the description fails to fully compensate.
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 identifies the action ('Update') and the target ('an HDA definition'), and specifies the source ('its current node contents'). It distinguishes itself from sibling tools that create, install, or delete HDAs, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like hda_create or hda_install, nor any context about prerequisites or consequences. The description only states what it does, with no situational use cases or exclusions.
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?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states 'Write cache', which implies a write operation but does not disclose potential side effects such as overwriting existing cache, whether the operation is destructive, or if it requires specific permissions. This is a significant gap for a file-writing 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 a single concise sentence of eight words, with no redundant or filler content. It is appropriately sized for a simple tool and front-loaded with the core action. It earns its place without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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, no output schema), the description is too thin. It lacks essential context about parameter semantics, return behavior, or interaction with the file cache node. With no annotations to supplement safety or behavioral details, the description is insufficient for correct invocation, especially since sibling cache tools exist that might be confused.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions), and the description does not compensate. Although 'path' and 'frame_range' are somewhat self-explanatory from their names, the description does not clarify that 'path' refers to the file cache node path or explain how 'frame_range' affects caching. The meaning of these parameters remains ambiguous without additional context.
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 'Write cache for a file cache node' uses a specific verb ('write') and identifies the target resource ('cache for a file cache node'). It distinguishes from sibling cache tools like 'clear_cache' and 'list_caches' by indicating a distinct write action. However, it could be more explicit about what 'write cache' entails (e.g., generate a cache file, update existing cache).
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?
The description offers no guidance on when to use this tool versus alternatives, nor does it mention prerequisites like whether a file cache node must exist or if a frame range is required. It doesn't state exclusions or typical scenarios, leaving the agent without context for appropriate invocation.
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 merely says 'clear cache' without revealing whether this is destructive, permanent, or reversible, what happens to the node's cached data, or any side effects. For a mutating operation, this is a significant 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 a single, front-loaded sentence with no unnecessary words. It efficiently conveys the core action. While it is sparse, it earns its place and is appropriately sized for a simple tool, though additional details could be added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple but mutating operation, the description is incomplete. It does not mention prerequisites (e.g., node must exist), failure modes, return values, or whether the cache is cleared from disk or memory. The tool's behavior is underspecified for an agent to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'path' parameter with no description, and schema description coverage is 0%. The description only implies that the path refers to a file cache node but does not explain what the path should represent (e.g., node path format, required node type). This does not compensate for the lack of schema documentation.
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 action: clearing cache on a file cache node. It uses a specific verb (clear) and resource (file cache node), and it is distinct from sibling tools like list_caches, get_cache_status, and write_cache, which focus on listing, checking, or writing cache. 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 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. The description only states what it does, with no mention of contexts (e.g., after modifying cache parameters) or exclusions (e.g., when you need to preserve cached data). It does not distinguish when to prefer clear_cache over other cache-related tools.
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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. Beyond stating that it adds multiple parameters 'at once', it does not mention side effects, whether existing parameters are overwritten, any permission requirements, or failure behavior. This is minimal disclosure 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 a single, front-loaded sentence with no wasted words. Every word contributes to the core meaning, making it highly concise and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters (one an array of objects), no annotations, and no output schema, the description is insufficient. It leaves users guessing about the structure of the parameters array, any return value, and how the operation behaves in edge cases. A more detailed description is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate for this. It does not explain what 'parameters' should contain, the structure of each object in the array, or how 'node_path' is used beyond being a node path. This is a critical gap for a tool expecting an array of objects.
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 'Add', the resource 'spare parameters', and the target 'node', with the qualifier 'multiple... at once' distinguishing it from the singular sibling tool 'create_spare_parameter'. This is a specific and unambiguous purpose statement.
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?
The description provides no guidance on when to use this tool versus alternatives like create_spare_parameter or set_parameters. The only hint is 'multiple', which implies batch usage, but there is no explicit mention of alternatives or exclusion criteria.
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, the description carries the full burden of behavioral disclosure, but it only states the action without revealing side effects, error handling, or requirements (e.g., whether the keyframe must exist, whether the operation is reversible). This is insufficient 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 a single concise sentence that immediately conveys the core purpose. It is well-structured and contains no filler, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with three required parameters, no annotations, and no output schema, this description is severely under-specified. It lacks any information about return values, error conditions, or prerequisites, making it inadequate for an AI agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 compensate. It mentions 'frame' but does not explain node_path or parm_name, nor how they identify the keyframe. The meaning of the parameters is largely implicit.
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 ('delete') and resource ('keyframe'), and clarifies the scope ('at a specific frame'). This clearly distinguishes the tool from siblings like set_keyframe, set_keyframes, and get_keyframes.
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 about when to use this tool versus alternatives, nor any prerequisites or exclusions. The only hint is the description itself, which implies use when deleting a keyframe, but it does not discuss conditions or alternatives.
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, the description must shoulder the burden of behavioral disclosure. It states the action but does not reveal potential side effects (e.g., breaking connectivity), whether the operation is reversible, or any permission prerequisites. This is insufficient for a mutating 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 a single, front-loaded sentence with no redundancy. It is concise and to the point, though it sacrifices detail in favor of brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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, the description is incomplete. It does not explain the return value, failure modes, or the effect of disconnecting an input (e.g., does it delete wires, leave placeholders?). For a mutation tool, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to node_path or input_index. It does not clarify that input_index is a zero-based index or how 'specific input' relates to the parameters. The agent gets no help beyond raw schema 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 'Disconnect a specific input on a node' uses a specific verb and resource, clearly identifying the action and target. It distinguishes itself from sibling tools like connect_nodes and reorder_inputs.
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 does not mention connect_nodes, reorder_inputs, or any conditions that would make this tool preferable, leaving the agent to infer usage context.
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 carry the full burden of behavioral disclosure. 'Get' strongly implies a read-only operation, and 'file cache node' provides scoping. However, it doesn't mention what the status contains, whether the operation can fail, or any prerequisites, leaving gaps beyond the name.
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 a single, front-loaded sentence with no redundant words. It is concise and to the point, though it could be slightly more informative without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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, the description is too thin. It doesn't clarify the return format or possible error conditions, and while the tool is simple, the agent has almost no context beyond what the name provides. This is inadequate for smooth tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explicitly explain the 'path' parameter. It implies that the path should point to a file cache node, but that's all. The added value is minimal, and the description fails to compensate for the lack of schema metadata.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies a clear resource ('cache status for a file cache node'). It distinguishes itself from related tools like 'list_caches' and 'clear_cache' by specifying the target node type, though it doesn't 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 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 like 'list_caches' or 'clear_cache'. The description gives no context on typical use cases or exclusions, so the agent must infer based on the name alone.
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, the description carries the full burden. The verb 'Get' implies a read-only operation, but the description does not disclose behavior for missing attributes, composed vs. authored values, error handling, or the relationship between 'path' and 'prim_path'. This is a significant gap for a USD tool.
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 a single sentence with no filler or redundant content, so it is highly concise and front-loaded. However, conciseness should not come at the expense of necessary details; while the sentence is efficient, the structure is under-specified for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three required parameters with zero schema descriptions, a USD attribute getter, and no output schema, a one-sentence description is insufficient. The description fails to clarify parameter semantics, path vs. prim_path, return behavior, or when to choose this tool over related getters like 'get_attrib_values'. The tool is effectively unusable from the provided description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter-level details. Critically, it does not explain the distinction between 'path' and 'prim_path', which is non-obvious and could lead to incorrect invocation. The description only reuses the generic term 'attribute value' without mapping to the three required parameters.
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 action ('Get') and the resource ('a specific USD attribute value'), and the qualifier 'specific' indicates a single attribute rather than a bulk listing. This distinguishes it from siblings like 'set_usd_attribute' (write operation), 'get_attrib_values' (likely geometry attributes), and 'get_usd_prim_stats' (prim-level stats).
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: use it when you need to retrieve one USD attribute value. However, it provides no explicit guidance on when not to use it, no alternative tool names, and no discussion of prerequisites such as a valid prim path or stage. Context is minimal but not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, so the description carries the full burden. It discloses no behavioral traits such as side effects, failure behavior, whether it overwrites existing HDAs, or any required conditions. The single sentence adds no transparency beyond the action itself.
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 a single sentence with no unnecessary words. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description lacks essential context about installation behavior, return values, prerequisites, or what happens after installation. It is minimally complete for selecting the tool but insufficient for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the file_path parameter beyond its name. With 0% schema coverage, it does not compensate by explaining path format, required file extension, or validation. The parameter name is self-explanatory, but no additional context is provided.
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 action (Install), the resource (HDA file), and the target (current Houdini session). It distinguishes this tool from siblings like reload_hda, uninstall_hda, and update_hda, which have different specific verbs.
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, nor any exclusions or context. The description only restates the basic action without explaining scenarios or prerequisites.
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, the description carries the full burden of behavioral disclosure. It only states the scope ('all light prims') but does not explain whether traversal is recursive, how the 'path' parameter constrains the search, or what happens with invalid paths. Key behavioral aspects are left unspecified.
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 a single, well-formed sentence that states the tool's purpose without unnecessary words. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is still incomplete. It fails to explain the 'path' parameter, the return format, or any constraints (e.g., whether it operates on the current stage or a specified stage). With no output schema and no param details, the description leaves critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions no parameters. The only parameter, 'path', remains completely unexplained, leaving ambiguity about whether it refers to a stage path, prim path, or container path. The description adds no 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 uses a specific verb 'List' and clearly identifies the resource 'all light prims in a USD stage'. This distinguishes it from sibling tools like list_materials and list_usd_prims, which focus on different entity types.
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 vs alternatives. It does not mention exclusions, alternatives, or typical scenarios. The user is left to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention side effects such as replacing the current scene, clearing existing data, or requiring an absolute path. Loading is a potentially destructive action, and this description is silent on consequences.
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 a single, focused sentence with no wasted words. It front-loads the action and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers only the basic purpose. It lacks usage guidelines and behavioral transparency, making it incomplete for an agent to safely invoke without additional context. The absence of annotations and output schema increases the need for richer description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must elaborate on the file_path parameter. It only implies the parameter is the path to a .hip file, but does not clarify whether an empty default is acceptable, what path formats are supported, or how errors like missing files are handled.
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 action ('Load'), the resource type ('.hip file'), and the destination ('into Houdini'). This distinguishes it from sibling tools like save_scene or reload_hda, which involve different operations or file types.
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 does not mention scenarios where loading a .hip file is appropriate, nor does it exclude cases like reloading HDAs or saving scenes.
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, the description carries the full burden of behavioral disclosure. It only lists actions without explaining side effects (e.g., whether 'play' starts playback, whether 'stop' resets to frame 0, if it returns anything). This is minimal disclosure, leaving key behavioral traits unspecified.
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 a single concise sentence that front-loads the resource ('Control playbar') and then lists actions. It has no filler and is appropriately sized for a simple tool. It could be slightly more precise, but it earns a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema and no annotations, the description is thin. It does not state whether the action values are exact strings, what the return value is, or any side effects on the playbar state. This leaves significant gaps for an agent trying to use the tool correctly.
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 schema provides only a generic 'action' string with no enum or description. The description compensates by enumerating the allowed values (play, stop, reverse, step_forward, step_backward), giving the agent some idea of valid inputs. However, it does not elaborate on the meaning or effect of each action, so the compensation is partial.
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 states the tool controls the playbar and lists specific actions (play, stop, reverse, step_forward, step_backward). This clearly identifies the resource and the operations, distinguishing it from sibling tools like set_frame or set_playback_range. However, the verb 'control' is a bit generic; a more precise verb like 'change playback state' would strengthen it.
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. For example, it does not clarify whether to use this for play/pause actions versus set_frame for scrubbing. There are no exclusions or mention of related tools, leaving the agent without context for tool selection.
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, the description carries full responsibility for behavioral disclosure. It states the action (set) but does not reveal whether the attribute is created if missing, whether it modifies the node's underlying geometry or just the current cook, or any side effects like re-cooking. This is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and readable, though it could have expanded to include parameter details without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations and no output schema, a single sentence is insufficient. It lacks context about return values, error conditions, how the node path is interpreted, and whether the attribute must exist beforehand. The description is minimally viable but clearly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It gives some implicit context (e.g., 'attribute value' hints at 'value' parameter, 'on geometry' hints at 'node_path'), but it does not explicitly explain each parameter's meaning or format. The schema titles are minimal, and the description adds little beyond what they already show.
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 ('Set') and identifies a clear resource ('detail (global) attribute value on geometry'). This clearly distinguishes it from sibling tools like set_parameter or get_attrib_values, as it targets geometry detail attributes specifically.
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. The description does not mention exclusions, prerequisites, or related tools, leaving the agent to infer usage from the name and context.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool sets a range, but does not mention side effects, required permissions, how invalid inputs are handled, or what happens to the current frame. This is minimal disclosure 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 a single concise sentence with no filler. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the low complexity (two parameters, no output schema), the mutation tool has no annotations and the description is very brief. It lacks details about behavior, error handling, or relationship to other range-related tools, leaving the agent without enough context for full understanding.
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 schema has 0% description coverage, so the description must compensate. 'Frame range' clarifies that start and end are frame numbers, adding meaning beyond the bare schema names. However, it does not specify units, ordering constraints, or data types beyond what the schema already provides, making it minimally acceptable.
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 'Set the global animation frame range' uses a specific verb ('set') and resource ('global animation frame range'), making the action clear. It includes the qualifier 'global,' which helps distinguish it from related tools like set_playback_range, though it doesn't explicitly name siblings.
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?
The description provides no guidance on when to use this tool versus alternatives such as set_playback_range or set_frame. It implies a use case by saying 'global,' but there is no explicit context or exclusion criteria.
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 only states the basic setup action and destination, but does not reveal whether it creates a new node or modifies an existing one, whether it affects the current scene, or what side effects occur. This is a significant transparency gap 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 a single sentence with no wasted words. Information is front-loaded: verb, resource, location, and key parameters all appear immediately. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no output schema, and no annotations, the description is minimal. It explains the basic purpose but lacks context about prerequisites, the setup process, side effects, or how it relates to other render-related tools. For an agent needing to select and invoke this tool correctly, the description is under-specified.
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 schema has 0% description coverage, so the description must compensate. It explicitly mentions camera_path and output_path, providing context for two of the three parameters. However, render_engine (which has a default of 'karma') is not mentioned, leaving its role unclear. The description partially bridges the schema gap but is not fully sufficient.
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 action ('Set up a render node'), the location ('in /out'), and the key parameters ('camera and output path'). It is specific and uses an imperative verb, but it does not explicitly differentiate from sibling tools like create_render_node or render_single_view, so it misses the top score.
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?
There is no explicit guidance on when to use this tool versus alternatives. It implies usage for render node setup, but does not mention prerequisites, exclusions, or that start_render or set_render_settings may be needed afterward. This leaves the agent without clear selection criteria.
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 write/mutation operation but fails to mention side effects such as automatic cooking, whether the node must exist, or how the change might affect the scene. This is a gap 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 a single, concise sentence with no redundant information. Every word serves a purpose, and it is front-loaded with the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two self-explanatory parameters and no output schema, the description could be acceptable if it mentioned key context. However, it lacks any note about node path conventions, code validation, automatic cooking behavior, or how this relates to sibling tools. This leaves important context undisclosed for a tool that modifies scene content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the parameters beyond the schema. Schema description coverage is 0%, and the tool description does not explain what 'node_path' should look like (full vs. relative) or any encoding/formatting of 'code'. The burden is entirely on the schema, which is insufficient.
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 action ('Set'), the object ('VEX code'), and the target ('wrangle node'). It distinguishes this tool from siblings like get_wrangle_code (reading) and create_wrangle (creating a node), making the 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 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 such as create_vex_expression or validate_vex. The description does not mention prerequisites like an existing wrangle node or the need for valid VEX syntax.
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?
The description only states a read operation ('Get') but reveals nothing about what happens, the return format, error behavior, or any side effects. With no annotations provided, the description carries the full burden of behavioral disclosure, which it fails to meet beyond the basic verb.
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 extremely concise (5 words) and gets straight to the point. It is not padded with irrelevant information, and every word earns its place. However, it could be slightly more descriptive without losing conciseness, so it does not achieve a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must explain the return value and usage context. It does not mention what the returned take looks like, what 'current' means in this environment, or any potential failure conditions. This makes the description incomplete for an agent to fully understand the tool's behavior.
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, and the schema provides no parameter details (100% coverage trivially). The description adds meaning by specifying 'current', clarifying that it accesses a global state (the active take) rather than taking an input. This is sufficient for a parameterless getter.
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 verb 'Get' and the resource 'current take', distinguishing it from sibling tools like list_takes (listing all takes) and set_current_take (setting the active take). It is straightforward and unambiguous, though it could be more explicit about what 'current' refers to (e.g., active take).
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 such as list_takes or set_current_take. There is no mention of prerequisites, context, or exclusions, leaving the agent without direction for selecting it appropriately.
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 states only that it searches for matching prims, but does not disclose whether the search is case-sensitive, what pattern syntax is expected (e.g., glob, regex), whether it searches recursively, or what the return format is. This lack of detail is a significant gap for a read/search 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 a single concise sentence that is front-loaded with the verb 'Search'. It is direct and free of fluff, making it easy to parse. However, its extreme brevity leaves out crucial details, but the structure itself is well-formed for the limited information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, no annotations, and no parameter explanations, the description is insufficient for an agent to correctly invoke the tool. The agent would not know the expected pattern syntax, the meaning of 'path', or how 'type_name' affects the search. For a search tool, this is a critical omission, making the description incomplete for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 3 parameters (path, pattern, type_name) with 0% description coverage, yet the tool description does not explain any of these parameters. It does not clarify what 'path' refers to, what constitutes a 'pattern', or how 'type_name' filters results. The description adds no meaning beyond the parameter names themselves, failing entirely to compensate for the lack of 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?
The description uses a specific verb 'Search' with a clear resource 'USD prims' and the qualifier 'matching a pattern', which distinguishes it from sibling tools like list_usd_prims (which lists all prims) and get_usd_prim_stats (which retrieves stats). It clearly communicates the tool's core function.
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 a usage context: when you need to find prims by matching a pattern. However, it does not explicitly state when to use this tool versus alternatives like list_usd_prims or find_nodes, nor does it provide any exclusions or alternative recommendations. The implied usage is present but not elaborated.
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 states the basic action (advancing simulation) but does not disclose side effects, whether the operation is reversible, the meaning of 'path', or how it interacts with simulation state—leaving significant ambiguity.
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 a single, front-loaded sentence with no redundant words. It efficiently communicates the core action without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and parameter details, the description is insufficiently complete. It does not explain what 'path' refers to, what num_steps does precisely, or how this tool fits with simulation workflows, leaving the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not name or explain either parameter. The phrase 'number of frames' hints at num_steps, but 'path' is entirely unexplained, and the schema itself only provides minimal titles without descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('step') and identifies the resource ('simulation forward by a number of frames'), making the action clear. It distinguishes implicitly from sibling tools like reset_simulation and get_simulation_info, but does not explicitly name alternatives or contrast with them.
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?
Usage is implied by the description: you use this to advance a simulation forward. However, it provides no explicit guidance on when to choose this over reset_simulation or other simulation tools, and no mention of prerequisites or context.
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, the description carries the full burden of behavioral disclosure. It states the core action but does not explain output behavior (e.g., file format, default save location, whether it returns anything) or side effects. This is thin for a tool that likely writes to disk.
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 a single, front-loaded sentence with no wasted words. It is appropriately concise for the tool's apparent simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is insufficiently complete given the undocumented parameter and absence of an output schema. It leaves critical unknowns about file output behavior, parameter semantics, and return values, making it barely usable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema shows one optional parameter (output_path) with no description, and schema description coverage is 0%. The description does not mention this parameter at all, failing to compensate for the lack of schema documentation.
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 ('Capture') and clearly identifies the resource ('a screenshot of the current viewport'). It distinguishes from sibling rendering tools (e.g., render_single_view) by focusing on the current viewport screenshot.
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 like render_single_view or render_flipbook. There is no mention of appropriate contexts, prerequisites, or exclusions, leaving the agent to infer usage.
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?
The description discloses that the tool deletes a node, but with no annotations, it fails to mention important behavioral traits such as whether deletion is permanent, recursive (deleting children), or what happens to connected nodes. This is a significant gap for a destructive operation.
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 a single concise sentence that front-loads the action and resource. There is no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, no output schema, and low parameter coverage, the description lacks essential context: it does not mention permanence, side effects on node hierarchy, or any prerequisites. The simple nature of the tool does not compensate for the missing safety and behavioral information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'path' with 0% description coverage. The description only says 'by path', which adds minimal meaning beyond the schema's property name and title. It does not clarify the expected path format (e.g., /obj/geo1) or any 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 uses a specific verb ('Delete') and a resource ('a node from the Houdini scene') and distinguishes it from sibling tools like create_node, copy_node, rename_node, etc. The phrase 'by path' clearly indicates the identifying mechanism.
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, nor any prerequisites or exclusions. It simply states what it does, leaving the agent to infer usage context.
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 does not mention side effects like file overwriting, return values, required permissions, or behavior when output is null. Listing formats is helpful but does not address these 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: two sentences with no filler. Every word adds value, making it an efficient and well-structured summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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, no annotations, and no output schema, the description is missing critical information about node_path semantics, output file behavior (e.g., default path, overwrite rules), and expected return values. It is not complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only lists the format options, but does not explain the meaning of node_path or output. This is insufficient for an agent to correctly populate all three parameters, especially the required node_path.
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 ('Export') and resource ('geometry to a file') and lists supported formats, clearly distinguishing it from sibling tools like write_cache or export_chop_to_parm. The scope is explicit, making the tool's function immediately understandable.
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?
There is no guidance on when to use this tool versus alternatives such as write_cache or export_chop_to_parm. The description provides no context for selection or exclusion, leaving the agent to infer usage from the tool name alone.
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?
No annotations are provided, and the description only gives a high-level action. It doesn't disclose what 'recently modified' means, whether the operation is read-only, or if there are any side effects, leaving behavioral details opaque.
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 a single sentence with no redundant information, making it very concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential context such as the meaning of 'edit target layer,' the behavior of the count parameter, and what the returned prims contain. For a tool with no annotations and no output schema, this is insufficient for an agent to predict behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines 'path' and 'count' with no descriptions, and the tool description does not explain their purpose or format. With 0% schema description coverage, this is a complete gap.
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 'Get' with a focused resource 'recently modified prims' and scoping to 'the edit target layer,' clearly distinguishing it from generic prim access tools like get_prims.
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 states what it does but provides no guidance on when to use it over other tools (e.g., get_prims) or any exclusions. The use case is implied but not explicit.
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, the description carries full responsibility for behavioral disclosure. It states the operation is a getter, but does not disclose whether it has side effects, what it returns (beyond 'settings'), error behavior, or if any state is changed. The term 'Get' implies non-destructive intent but is not explicit.
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 a single sentence with no filler. It is appropriately sized for a simple getter operation and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should explain return values or behavior beyond the operation itself. It does not mention what the render settings consist of, the format, or any side effects, making it incomplete even for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the only parameter 'path' is minimally described as 'Path'. The description's reference to 'ROP node' provides context that path likely points to a ROP node, but does not explicitly state it, leaving the parameter semantics ambiguous.
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 'Get' with a resource 'render settings' and a source 'ROP node', making the tool's function clear and distinct from siblings like set_render_settings and start_render. No ambiguity about what it operates on.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for reading settings, while set_render_settings is for modifying them, nor any exclusions or prerequisites. Usage is only implied by the verb.
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, the description must carry the full burden of behavioral disclosure. It states the tool retrieves composition arcs but does not mention side effects, error handling, or what happens when a prim does not exist. The verb 'Get' suggests a read-only operation, but no explicit safety guarantees or behavioral traits are disclosed.
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 a single, efficient sentence that directly states the tool's purpose with no filler. It front-loads the action and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two undocumented parameters and no output schema, this one-sentence description is insufficient. It does not explain the expected return structure, the relationship between the two arguments, or edge cases, so the agent may not be able to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not clarify the meaning of the 'path' parameter or how 'path' and 'prim_path' relate. While 'prim' is mentioned, the description fails to explain the role of either parameter, leaving the agent without enough information to construct valid arguments.
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 identifies the tool's function: retrieving composition arcs (references, payloads, inherits, specializes) for a prim. This specific verb-resource combination distinguishes it from sibling tools like get_usd_prim_stats or get_usd_attribute.
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 the tool is used when composition arcs are needed, but it does not provide explicit guidance on when to use this tool versus alternatives such as get_usd_prim_stats or inspect_usd_layer. No exclusions or alternative references are given, so usage context is only implied.
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, the description carries the full burden of behavioral disclosure, but it only states the basic operation. It does not mention that layout will likely modify node positions (a side effect) or whether the operation is reversible, which is important for an agent to assess 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 a single, front-loaded sentence that gets straight to the point without wasted words. It is appropriately concise for the tool's core purpose, though additional detail could be added elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is too minimal. It fails to explain the meaning of node_path or any behavioral side effects, leaving the agent without sufficient guidance for correct invocation. The overall context is incomplete despite the tool's apparent simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'node_path' with no description (schema coverage 0%), and the tool description does not mention this parameter at all. The agent is left to infer what path means, its scope (e.g., parent node path), and how it affects layout, which is a significant gap.
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 'Auto-layout child nodes in the network editor' is specific with a clear verb (auto-layout) and resource (child nodes) plus context (network editor). It clearly distinguishes from siblings like list_children or move_node, making the tool's intent unambiguous.
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 is provided about when to use this tool versus alternatives. Usage is implied by the verb 'auto-layout', but there are no exclusions, prerequisites, or discussion of alternative approaches (e.g., manual arrangement or layout via other commands).
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 disclosing behavioral traits. It only says 'create a channel reference' without explaining side effects, whether existing references are overwritten, if the parameters must already exist, or any required permissions. This is minimal for a mutation tool and leaves significant gaps in understanding the operation's 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 a single, concise sentence that immediately states the purpose. It contains no filler or redundant content, making it efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, no output schema, and no parameter descriptions, the one-sentence description is inadequate to fully understand how to invoke it correctly. The agent is missing crucial information about what paths refer to, what a channel reference is, and any side effects, leaving the description incomplete for a competent use of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description names only dst_parm and src_parm, clarifying their directional relationship. However, it does not explain src_path and dst_path at all, and gives no details about the expected format or meaning of these paths. The description adds some meaning about direction but fails to compensate for the lack of schema descriptions for all parameters.
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 action (create a channel reference) and the resources involved (dst_parm to src_parm). This is a specific verb+resource construction that distinguishes it from siblings like set_parameter or set_expression, which focus on value assignment or expressions rather than linking.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when a channel reference is appropriate, or compare with other parameter-related tools such as set_expression. The description simply states the action without providing usage context or exclusions.
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?
No annotations exist, and the description only repeats the action 'list' without disclosing return format, side effects, or constraints. It does not explain that it is a read-only operation or how it handles the root_prim and max_depth parameters beyond what the schema already shows.
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 a single sentence with no filler, making it highly concise and front-loaded. Every word adds value, though it is under-specified in content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a USD listing tool with three parameters and no output schema, the description lacks essential context such as what 'path' refers to, whether traversal is recursive, and what the response looks like. It is minimally viable but insufficient for an agent to invoke correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning by mentioning 'depth' which maps to max_depth, but it does not explain the semantics of 'path' or 'root_prim', despite 0% schema description coverage. This fails to compensate for the schema's lack of parameter documentation.
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 USD prims up to a specified depth, using a specific verb and resource. It differentiates from Houdini geometry prim tools by specifying 'USD prims'.
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 given on when to use this tool versus alternatives like get_prim_intrinsics or get_prims. The description only states what it does, not when it should be chosen.
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?
No annotations are provided, so the description carries full burden of behavioral disclosure. It mentions import methods but does not describe side effects, whether it modifies the current LOP network, error behavior, or return values. For a file import operation, this lacks transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but given the tool has 4 parameters and no schema descriptions, it is under-specified. It is too short to be appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and does not cover parameter semantics, behavioral context, or return values. With no annotations or output schema, it is insufficient for an AI 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only hints at the method parameter via 'reference or sublayer.' The required 'path' and 'file' parameters and optional 'prim_path' are not explained. Thus the description adds minimal 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 imports a USD file and specifies the two methods (reference or sublayer). The verb 'import' and resource 'USD file' are specific, distinguishing it from sibling tools like load_scene.
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 is provided. Usage is implied as importing USD files into the LOP context, but there are no exclusions or alternative tool suggestions.
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 only states that the tool modifies a node, which inherently implies a write operation, but it does not reveal side effects, permissions required, reversibility, or any consequences of the modification. This is a significant gap 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 a single, front-loaded sentence that efficiently conveys the tool's purpose and supported actions. There is no redundant information or unnecessary embellishment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, no annotations, and several overlapping sibling tools. The description only covers the basic action and parameter mapping, but lacks usage guidance, behavioral context, and details about parameter object structures. This is insufficient for an AI agent to fully understand when and how to use this tool reliably.
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 0% description coverage, but the description compensates by mapping operations to parameters: 'rename' corresponds to 'name', 'reposition' to 'position', and 'change parameters' to 'parameters'. This adds meaning beyond the raw schema types and titles, although it does not clarify the structure of the 'parameters' object or the format of the 'position' array beyond the schema's own definitions.
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's function ('Modify an existing node') and lists the specific supported operations: rename, reposition, or change parameters. This provides a specific verb, resource, and scope. However, it does not explicitly distinguish itself from sibling tools like rename_node, move_node, or set_parameters, which perform similar individual operations.
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?
The description provides no guidance on when to use this tool versus the dedicated sibling tools (rename_node, move_node, set_parameter). It does not offer any context, exclusions, or alternative recommendations, leaving the agent without clear decision-making information for tool selection.
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?
There are no annotations provided, so the description must disclose behavioral traits. It only says 'Cancel a running PDG cook,' but does not explain side effects, whether it is destructive, if it requires specific permissions, or what happens to the cook (e.g., partial results, node state). This is a significant gap 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 a single, concise sentence with no unnecessary words. It is appropriately sized for the tool's simple operation and avoids redundancy, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no annotations, no output schema, and a parameter with zero schema description, the description alone is not complete enough. It lacks context about what a PDG cook is, what the path parameter should be, and what the result of cancellation is. An agent would likely need to consult other tools or documentation to use this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'path' with no description and 0% schema description coverage. The description does not clarify what 'path' refers to (e.g., a PDG node path, a cook ID, or a file path). It only implies the target is a running PDG cook, but this is insufficient for an agent to know exactly what value to pass.
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 action ('cancel') and the resource ('a running PDG cook'), which is specific and distinguishes it from sibling tools like pdg_cook (which starts a cook) and pdg_status (which shows status). Even though it is brief, the purpose is unambiguous and directly tied to the tool name.
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?
The description provides no guidance on when to use this tool versus alternatives, such as pdg_cook, pdg_status, or pdg_dirty. There are no preconditions, exclusions, or mention of related tools, leaving the agent to infer usage context solely from the name and description.
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?
There are no annotations, and the description fails to disclose any behavioral side effects. The term 'reload' suggests overwriting or replacing existing HDA definitions, but this is not stated explicitly. It also does not mention permissions, reversibility, or potential failure modes.
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 a single concise sentence that efficiently states the core action and target. There is no redundancy or extraneous content, making it appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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, the description is incomplete. It does not explain the effect of the reload operation on existing definitions, any preconditions, or what the result of the action is. This is a mutating tool that requires more contextual disclosure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description needed to compensate for the file_path parameter. It only says 'from a file,' which adds little beyond the parameter name and type. It does not specify the expected file format, path conventions, or any other relevant interpretation.
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 specifies the action ('Reload') and the resource ('all HDA definitions from a file'). It distinguishes itself from related HDA tools like hda_install or update_hda by emphasizing a full reload from a file, making the 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives such as hda_install or update_hda. The usage context is only implied by the word 'reload' and the mention of 'from a file,' but no scenarios or exclusions are provided.
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, the description carries the full burden of behavioral disclosure. It only says the tool 'sets up' a simulation, but does not explain what this entails—whether it creates a DOP network, modifies the source geometry, overwrites existing setups, or has any side effects. The lack of detail leaves the agent guessing about the operation's scope and mutability.
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 a single, tightly worded sentence that immediately conveys the tool's purpose. Every word contributes meaning, and there is no redundancy or filler. This is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no annotations, and no output schema, so the description must provide sufficient context. It fails to explain what the setup process does, what inputs are required beyond a vague 'source geometry', what the expected output is, or how it interacts with existing scene content. This is inadequate for an agent to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it only mentions 'source geometry' which roughly maps to source_path, but adds no meaning beyond the schema's 'Source Path' property. It does not explain the 'name' or 'parent_path' parameters, nor does it clarify what form 'source geometry' should take (e.g., a SOP path, an object path).
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 explicitly states the tool 'Set up a FLIP fluid simulation from a source geometry.' It uses a specific verb ('setup') and names the resource type (FLIP fluid simulation), clearly distinguishing it from sibling tools like setup_pyro_sim, setup_rbd_sim, and setup_vellum_sim.
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 usage guidance is provided. The description does not say when to use this tool vs alternatives, nor does it mention any prerequisites or exclusions. It simply states what it does without context.
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, the description carries the full burden of behavioral disclosure. It does not mention what happens if validation fails, whether it returns a boolean/errors, or whether there are side effects. The action 'validate' implies a check, but outcome and safety are unspecified.
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 a single, front-loaded sentence with no wasted words. It directly conveys the tool's purpose without filler, making it appropriately concise for its simple scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple with one parameter, there is no output schema or annotation, so the description should explain expected return behavior. It only states the action and target, leaving the agent without knowledge of the result format or error indications, making it incomplete for invocation confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 identifies the parameter as 'VEX code' but does not clarify expected format, scope, or any constraints beyond the schema's type/string and required flag. Meaningful semantic detail is minimal.
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 ('validate') and resource ('VEX code syntax'), clearly distinguishing this from sibling tools like evaluate_expression or create_vex_expression. It unambiguously states the tool's function.
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. The description states only the action and target, without mentioning context, exclusions, or preferred scenarios.
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 carries the full burden. It discloses that the tool returns geometry bounds and includes min, max, size, center, which is useful behavioral information. However, it does not state whether it triggers a cook, what happens for invalid node_path, or whether it works for all node types. It is minimally transparent but not rich.
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 a single, direct sentence that front-loads the action. It includes no filler and every word adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description lists return fields (min, max, size, center) which is good. However, it lacks critical context like node_path semantics, error behavior, and whether the geometry is cooked. It is adequate for a basic getter but leaves gaps for an agent to use it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/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 only parameter, node_path, and the description does not explain what node_path means (e.g., path format, relative vs absolute, node types). The description merely implies it identifies a node, adding no value over the parameter's name.
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 ('Get') and resource ('bounding box of a node's geometry'), and explicitly lists what is returned (min, max, size, center). This clearly differentiates it from other geometry-related tools like get_geo_summary or get_points.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or context such as 'use when you need axis-aligned bounds' or 'for mesh bounds, use get_geo_summary'. There is no proactive differentiation from sibling tools.
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?
No annotations are provided, so the description must disclose behavioral traits on its own. It only states what information is returned, but does not mention whether the tool is read-only, whether it attempts a connection, whether it has side effects, or any required permissions. This is a significant transparency gap for a tool that interacts with an external application.
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 a single, tightly worded sentence that front-loads the core action and resource, then lists the specific return contents. Every word earns its place, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, no output schema), and the description does partially compensate by enumerating the return fields (connected, port, command count, timing info). However, it does not specify the exact data types, possible values (e.g., what 'port' is when disconnected), or error behavior. Given the lack of annotations and output schema, the description could be more thorough to fully prepare an agent for invoking the 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?
The tool has zero parameters, so the baseline score is 4 per the rubric. The empty schema already communicates that no arguments are needed, and the description adds no parameter-specific information, but none is required. The description's list of return fields indirectly clarifies what the (nonexistent) parameters might influence, but it is not necessary for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Returns' and clearly identifies the resource as 'connection status to Houdini', then enumerates concrete output details (connected, port, command count, timing info). This makes the tool's purpose obvious. It does not explicitly differentiate from the sibling tool 'ping', which could also be used for connectivity checks, so it falls short of a 5.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any preferred context, prerequisites, or exclusion criteria. The intended use is only implied by the name and description, not stated explicitly.
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, the description must disclose behavioral traits. It hints at an optional result with 'if any,' but it does not explain return types, error behavior, or any side effects. This is minimal 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 a single, concise sentence that gets straight to the point. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple getter with two parameters and no output schema. The description gives the core purpose but omits details about the return value format or error conditions. It is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no explanation of the node_path and parm_name parameters beyond their self-evident names. Schema coverage is 0%, so the description should compensate, but it only indirectly refers to a 'parameter' without defining the arguments.
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 identifies the action (get) and the resource (expression set on a parameter). It distinguishes from related tools like set_expression and evaluate_expression, 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 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 instead of alternatives such as get_parameter or evaluate_expression. The description only states what it does, not why you would choose it.
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, the description carries the full burden of behavioral disclosure. It only lists output content (prims, layers, time codes) without mentioning whether the node is cooked, how errors are handled, or any side effects. This is minimal and insufficient given zero annotation support.
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 a single concise sentence that front-loads the primary action and resource, then lists three specific information types. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description provides essential return content, but it lacks usage guidance and parameter semantics. The tool is low complexity, so this is a minimum viable description with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explicitly explain the 'path' parameter. It indirectly references 'a LOP node' but doesn't clarify the path format, required type, or provide examples, leaving the agent to infer the parameter's meaning.
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 with a specific verb ('Get') and resource ('USD stage info from a LOP node'), and specifies the information types (prims, layers, time codes). This makes it distinct from sibling tools like lop_layer_info or get_usd_prim_stats.
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?
The description offers no explicit guidance on when to use this tool versus alternatives such as lop_layer_info or get_usd_prim_stats. It implies use for LOP nodes but doesn't state exclusions or provide alternative recommendations.
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 full responsibility for behavioral disclosure. It only states the action, with no mention of side effects such as whether existing keyframes are overwritten, whether a cook is triggered, or error conditions. This is a significant gap.
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 extremely concise: two short sentences that immediately convey the main action and the keyframe format. No redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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, the description should provide more behavioral and contextual detail. It omits return values, handling of existing keyframes, and differences from sibling tools, making it insufficient for an agent to fully understand the tool's implications.
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 description adds meaning for the 'keyframes' parameter by clarifying its structure ('Each: {frame, value}'), which the schema leaves vague (additionalProperties as number). However, it does not explain 'node_path' or 'parm_name,' despite 0% schema description coverage, so it only partially compensates.
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 action and resource: 'Set multiple keyframes.' It also specifies the structure of each keyframe ('Each: {frame, value}'), which distinguishes it from the singular sibling tool 'set_keyframe' and other keyframe operations.
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?
There is no guidance on when to use this tool versus alternatives like 'set_keyframe' or 'set_parameter.' The description does not mention exclusions, prerequisites, or scenarios where this tool is preferred, leaving usage to inference from the name.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without revealing any side effects, prerequisites, or error behavior (e.g., what happens if the camera path is invalid, whether the change persists across sessions, or if it affects all viewports). This is a significant gap for a mutation-like operation.
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 a single, front-loaded sentence with no wasted words. It is appropriately concise for a tool with one parameter and a simple action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required parameter, no output schema), and the description captures the core purpose. However, it lacks parameter format details and any usage context relative to sibling viewport tools, making it minimally viable but with clear gaps that could hinder correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description needs to compensate by explaining the parameter. It only says 'specific camera node', which adds minimal meaning beyond the parameter name 'camera_path'. It does not specify the expected format (e.g., absolute vs relative path) or provide examples.
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 a specific action ('Set the viewport camera') and resource ('specific camera node'), which distinguishes it from sibling tools like set_viewport_display or set_viewport_direction. The verb+resource structure is precise 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as set_viewport_direction or render_specific_camera. It neither states explicit context nor excludes other tools, leaving the agent to infer usage from the name alone.
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?
No annotations are provided, so the description must disclose behavioral traits. It says 'Set viewport display options' but gives no detail on side effects, scope (e.g., which viewport is affected), persistence, or whether it toggles or overrides settings. This leaves significant uncertainty about the tool's runtime 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 a single, front-loaded sentence with no wasted words. It directly states the tool's purpose and enumerates its scope, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too minimal for an unannotated tool with no output schema. It does not explain possible values for shading_mode, the effect of the guide parameter, or any usage context. An agent would likely need external knowledge to invoke it correctly.
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 description names both parameters ('shading mode, guides'), adding meaning beyond the bare schema. However, it does not describe allowed values for shading_mode or how guide behaves (boolean toggle vs. explicit setting). With 0% schema coverage, this is only partial compensation.
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 viewport display options and enumerates the specific aspects (shading mode, guides). This provides a specific verb+resource+scope that distinguishes it from sibling viewport tools like set_viewport_camera or set_viewport_renderer.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention scenarios, prerequisites, or exclusions. It simply states what the tool does without any contextual usage directives.
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?
No annotations are provided, and the description only says 'copy' without explaining side effects such as whether the original remains, how children or connections are handled, or what happens on failure. This lack of detail for a mutation tool is a significant gap.
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 a single, front-loaded sentence with no fluff, efficiently stating the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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, the tool description should provide more context about copy behavior and parameter formats. It does not, leaving the agent to infer critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'path' and 'destination_path' parameters beyond implying that one is a node and the other a parent network. This is insufficient 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 uses a specific verb 'copy' and identifies the resource 'node' and destination 'new parent network', clearly distinguishing it from related tools like move_node or create_node.
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 the use case (duplicating a node to another parent) but provides no explicit guidance on when to choose this over alternatives like move_node, nor any prerequisites or limitations.
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 only restates the action ('create') without explaining side effects, network placement, error conditions, or any requirements beyond the parent path. There is no contradiction, but transparency is minimal.
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 a single sentence that is front-loaded with the verb and object, and contains no filler or redundant information. Every word earns its place, making it an effective concise structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with 4 parameters, no output schema, and no annotations, the description is under-specified. It omits important context such as how the parent_path is used, what wrangle_type values are valid, and what the tool returns. This leaves significant gaps for the agent to navigate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the parameters. It only mentions 'optional initial code,' which clarifies the 'code' parameter, but leaves parent_path (required), name, and wrangle_type unexplained. This is inadequate compensation for the missing schema-level 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?
The description states a specific verb ('create') and resource ('VEX wrangle node') with an optional initial code qualifier. This clearly distinguishes it from generic node creation (create_node) and wrangle code editing tools (set_wrangle_code, get_wrangle_code).
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 creating a wrangle node but provides no explicit when-to-use or alternative guidance. It does not mention when to prefer this over create_vex_expression or how it relates to set_wrangle_code, leaving the agent to infer the appropriate context.
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, the description carries the full burden of behavioral disclosure. It only states the basic operation, omitting details about search semantics (e.g., glob vs. regex), whether the search is recursive, or what the return format looks like. This is a significant gap for an agent relying on the description alone.
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 a single sentence that is direct and front-loaded, with no redundant wording. It efficiently communicates the core purpose without unrelated details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is too sparse to be complete. It fails to explain parameter semantics (especially root_path), return values, or search behavior, leaving an agent with insufficient information to reliably invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 compensate. It explains 'pattern' and 'type' but completely ignores 'root_path'. It also does not specify the expected pattern syntax, leaving one parameter undocumented and the others only partially clarified.
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 function: find nodes by name pattern, with an optional type filter. It uses a specific verb ('Find') and resource ('nodes'), distinguishing it from sibling tools like find_error_nodes or list_children.
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 when to use the tool (when searching for nodes by pattern) but provides no explicit guidance on alternatives or when not to use it. There is no mention of other tools or exclusions, so the context is clear but not fully elaborated.
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?
No annotations are provided, so the description carries the full burden. It only states the basic operation and optional filters, but does not disclose behavior such as whether the operation is read-only, what happens when channel/start/end are omitted, whether sample ranges are inclusive, or any potential side effects. Being a getter, it probably is safe, but that is not stated or annotated.
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 a single concise sentence that front-loads the core action, then adds optional qualifiers. Every word earns its place, no filler or redundancy. It is appropriately sized for the tool's apparent simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain what is returned (data format, structure) and the exact meaning of the 'sample range'. It also lacks any note about path syntax or default behavior. While it covers the basic purpose, it leaves significant gaps for a tool with 4 parameters, making it incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'specific channel and sample range', hinting at channel, start, and end parameters, but does not define what start/end represent (e.g., indices, time units, inclusivity) or what the path parameter should point to. The parameter semantics are only superficially clarified and not sufficient for an agent to correctly construct arguments.
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 ('Get') and resource ('CHOP channel data'), and scopes it with optional channel and sample range filters. It clearly distinguishes from siblings like list_chop_channels (which lists channel names, not data) and export_chop_to_parm (which writes to parameters).
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: if you need CHOP channel data, possibly filtered by channel or sample range, use this tool. However, it does not explicitly state when to prefer this over related tools like list_chop_channels or export_chop_to_parm, nor does it mention exclusions or prerequisites. The absence of explicit alternatives places it at 'implied usage'.
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, the description carries the full burden. It only states the action but does not disclose output format, whether this is a read-only operation, or any side effects. No additional behavioral context is provided.
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?
One sentence, uses vivid verb 'Get', and front-loads the action. No filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too sparse. It does not explain what the returned dependency chain contains, how to interpret it, or any error conditions. Users may need more context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'path' parameter with no description, and the description mentions 'a node' but does not specify the expected path format (absolute path, node name, pattern) or any constraints. This leaves ambiguity.
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 retrieves the cook dependency chain for a given node, specifying the scope 'inputs all the way up'. This distinguishes it from sibling tools like get_node_info or explain_node.
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 the tool is for inspecting a node's upstream dependencies but provides no explicit guidance on when to use it versus alternatives like build_sop_chain or get_network_overview. There are no exclusions or alternative suggestions.
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?
The verb 'Get' implies a safe read operation, but with no annotations and no output schema, the description does not disclose return format, error conditions, or whether the prim must exist. It offers only the minimal literal 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 a single, efficient sentence that states the action and target, with no unnecessary words and the verb front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a tool with unannotated parameters and no output schema. It does not explain what the response looks like, the relationship between the two path parameters, or any edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), and the description does not explain the 'path' and 'prim_path' parameters. While 'prim_path' is somewhat self-explanatory, 'path' is ambiguous, and the description adds no semantic clarity.
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 the verb 'Get' with a specific resource 'USD prim' and identifies the retrieved data ('variant sets and selections'), clearly distinguishing it from sibling tools like get_usd_attribute or get_usd_prim_stats.
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 other USD inspection tools. There is no mention of prerequisites, alternatives, or context, leaving the agent to infer usage solely from the tool name.
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?
No annotations are present, so the description must disclose behavioral traits. It only states the core action without mentioning file system side effects (e.g., whether it writes a file, overwrites existing HDAs) or any required permissions. Minimal behavioral disclosure beyond the basic operation.
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 a single, clean sentence with no wasted words. It front-loads the action and source effectively, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 required parameters, no annotations, and no output schema, the description is far too minimal. It doesn't explain the relationship between parameters, file path behavior, or the creation process (e.g., immediate save, format). Inadequate for a creation tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should compensate. It only hints at node_path's role via 'from an existing node', while name, label, and file_path are left unexplained. The description adds little meaning beyond the parameter names themselves.
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 'Create' with a clear resource 'HDA' and source 'existing node'. This distinguishes it from sibling tools like hda_install, hda_list, and update_hda, making the 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have an existing node and want to create an HDA, but provides no explicit when-to-use vs alternatives or exclusions. Sibling tools like hda_install or update_hda exist but no guidance is given on choosing between them.
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 does not explicitly state that this is a read-only operation, nor does it describe the return format or behavior with an invalid category. The description is too minimal to convey any meaningful behavioral traits beyond the basic 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 a single, concise sentence that front-loads the primary action and optional filter. Every word earns its place, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description is minimally viable. It conveys the core purpose, but lacks details about the return value (e.g., what fields are included) and the range of valid categories. Given the presence of sibling HDA tools, a bit more context would help, but it is not severely incomplete.
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 only parameter, 'category', has a default of null and no schema description, so schema coverage is 0%. The description adds the meaning that it filters by category, but does not explain what categories are valid, where to find them, or the expected format. This is partial compensation, but not full guidance.
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: 'List available HDA definitions, optionally filtered by category.' It uses a specific verb (List) and resource (HDA definitions), and the optional category filter adds scope. This distinguishes it from sibling HDA tools like hda_get, hda_install, and hda_create.
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 does not mention hda_get for retrieving a specific HDA or hda_install for installing one. The description only states what it does, not the context in which it should be chosen.
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?
The description discloses a key behavioral trait (non-blocking), which is valuable given no annotations are present. Yet it does not describe other important aspects like side effects, return value, or handling of already-cooking networks, leaving the full behavior partially undisclosed.
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 a single, concise sentence that front-loads the main action and key qualifier. No wasted words or redundancy, achieving high efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and sparse annotations, the description does not mention what the agent should expect after invoking the tool (e.g., does it return a cook ID? Should it be followed by pdg_status?). This lack of contextual guidance limits completeness for a non-blocking operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'path' with 0% description coverage, and the description does not explain what 'path' refers to (e.g., the node path to the TOP network). This leaves the agent without guidance on how to set the parameter correctly.
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 action (start cooking) and the target resource (TOP network), and specifies non-blocking behavior. It distinguishes itself from sibling tools like pdg_cancel and pdg_status by focusing on initiation.
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 usage context is implied: call this to begin cooking a TOP network. However, it does not explicitly mention when to use alternatives (e.g., pdg_cancel for stopping, pdg_status for checking progress), which prevents a higher score.
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?
No annotations are provided, so the description must convey behavioral traits. It only states a high-level effect ('dirty work items') without disclosing consequences, reversibility, or whether dirty_all changes the scope. The description does not mention side effects or any prerequisites, leaving the agent without critical behavioral 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?
The description is a single, concise sentence that is front-loaded with the action and resource. Every word contributes to the meaning, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a modestly complex tool, the description is too sparse. It does not explain what 'dirty' does in the re-cooking workflow, how it relates to pdg_cook, or what the expected result is. The description lacks sufficient context for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the two parameters (path, dirty_all), so the description must compensate. It does not explain 'path' or 'dirty_all' beyond what the names imply. The description mentions 'work items' and 'TOP node', but it adds no additional meaning to the parameters, leaving a significant gap.
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 ('Dirty') and resource ('work items on a TOP node') with a clear purpose ('for re-cooking'). It clearly distinguishes from sibling tools like pdg_cook, pdg_status, and pdg_cancel.
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?
Usage is implied by the phrase 'for re-cooking'—the tool is used to mark work items before cooking. However, no explicit when-to-use or alternative conditions are given, so it lacks clear guidance on when to choose this over pdg_cook or pdg_cancel.
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 mentions the optional state filter, but does not describe the output format, whether it returns all work items or has pagination, ordering, or any side effects. Given that this is a read-only list operation, the description misses the opportunity to clarify safety and return 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 a single, front-loaded sentence with no unnecessary words. Every part contributes to understanding the tool's function and scope. It is optimally concise for the simplicity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters and no output schema, the description is adequate but sparse. It covers the main purpose and the state filter, but does not mention the return value (a list of work items) or any edge cases. For a simple list tool, this is reasonable but not fully complete, especially without annotations to fill in safety or output context.
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 0% description coverage, so the description is the only source of parameter meaning. It explains that 'path' refers to a TOP node and 'state' functions as an optional filter, which adds interpretation beyond the raw schema. However, it does not specify the allowed state values, path syntax, or defaults beyond the schema's default of null.
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 work items for a TOP node, with an optional state filter. This is a specific verb-resource pairing that distinguishes it from sibling PDG tools like pdg_cook, pdg_status, or pdg_dirty, which have different actions.
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. The description simply states what it does, without mentioning when it is appropriate or when to prefer other tools like pdg_status for checking node state or pdg_cook for cooking. This leaves the agent to infer usage from the name and description alone.
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 full responsibility for behavioral disclosure. It describes the action as 'reorder' which implies mutation, but fails to mention side effects, requirements (e.g., valid input indices, existence of the node), or whether the operation is reversible. The lack of any safety or persistence information is a significant gap 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 a single, tight sentence that conveys the core purpose without any redundant wording. It is wholly focused and appropriately sized for a straightforward operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a simple 2-param tool with no output schema, the description needed to be self-sufficient, but it lacks essential details about the input_indices format and expected behavior. There is no mention of return values, error conditions, or how the node path is resolved. Given the absence of annotations and output schema, this description leaves important gaps for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds minimal meaning by describing 'input_indices' as the 'new index order', but does not clarify what the indices refer to, whether they must be a permutation, or the base (0-indexed vs 1-indexed). 'path' is also not explained. The description provides only a slight hint 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: reordering a node's inputs by specifying a new index order. It uses a specific verb ('Reorder') and resource ('inputs of a node'), and distinguishes it from sibling tools like connect_nodes or disconnect_node_input by focusing on reordering existing inputs rather than adding or removing connections.
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 when to use the tool (when you want to reorder node inputs) but provides no explicit context, exclusions, or mentions of alternative tools. There is no guidance on when not to use it or how it relates to connect_nodes/batch operations, so it only meets the 'implied usage' level.
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. It discloses that the tool mutates flags but provides no additional behavioral context such as side effects, error handling, or prerequisite conditions. For a mutation tool, this is a significant gap.
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 a single sentence of eight words, front-loaded with the verb 'Set'. There is no fluff or unnecessary detail, making it appropriately concise for its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with no output schema or annotations. The description covers the core action and lists the flag parameters, but omits usage guidance, error behavior, and differentiation from set_node_flags. It is minimally viable but not comprehensive.
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 description names all three flag parameters (display, render, bypass) in prose, which adds meaning beyond the schema. However, it does not explain the effect of true/false/null values, nor does it mention the required node_path parameter. Since schema coverage is 0%, this partially compensates but is not fully complete.
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 display, render, and bypass flags on a COP node. The verb 'set' is specific, the resource is a COP node, and mentioning COP distinguishes it from the generic sibling set_node_flags.
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?
The description gives no explicit guidance on when to use this tool versus alternatives. While the purpose implies it is for COP nodes, it does not mention that set_node_flags exists for generic nodes or provide any exclusions or context for choosing this tool.
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?
No annotations are provided, so the description carries the full burden. It only states the action without disclosing side effects, requirements, error conditions, or persistence. It adds no behavioral context beyond the operation itself.
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 a single concise sentence that directly states the operation. There is no wasted information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the basic action but omits behavioral details like whether the take must exist or how errors are handled. Given no output schema and no annotations, this is a minimal viable description but with gaps.
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 schema has no description for take_name (0% coverage). The description's 'by name' clarifies the parameter's role, but it doesn't specify format, valid values, or relation to existing takes. It adds minimal value beyond the schema property title 'Take Name'.
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 'set' with a clear resource 'current take' and specifies the method 'by name'. This clearly distinguishes from siblings like list_takes, get_current_take, and create_take.
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?
The description provides no guidance on when to use this tool versus alternatives like list_takes or get_current_take. It does not mention prerequisites (e.g., take must exist) or when this should be called.
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, the description carries the full burden. It states the input format but omits important behavioral traits such as whether the color affects the network display, if there are side effects, prerequisites, or what happens on success/failure. The mutation nature is implied by 'set' but not elaborated.
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 a single sentence, direct and front-loaded. Every word earns its place, with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description conveys the core action and color format. However, it omits context about the node_path syntax, expected behavior on invalid input, or any return value. Given no output schema and no annotations, the description is adequate but not thorough.
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 schema has 0% description coverage. The description adds meaning to 'color' by specifying it is [r, g, b] within 0-1 range, which goes beyond the raw schema. However, it provides no additional meaning for 'node_path', leaving the format or semantics of that parameter underspecified.
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 a specific verb ('Set'), resource ('node's color'), and provides the exact format and range ('[r, g, b] (0-1 range)'). It is distinguishable from siblings like set_material or set_node_flags which serve different purposes.
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 does not mention exclusions or suggest when a different tool would be more appropriate, leaving the agent without context for selection.
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, the description carries full burden but only states that flags are set. It does not disclose critical behavior such as whether null parameters leave flags unchanged, what happens if the node path is invalid, or any side effects like recooking. This is a significant gap 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?
A single front-loaded sentence with no wasted words. It is appropriately concise for a simple setter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no annotations and no output schema, the description is minimally adequate but leaves out important context like default behavior for null values and return value. It is complete for basic intention but lacks detail for safe invocation.
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 description names the three flag types (display, render, bypass) and the target node, which adds some meaning to the parameters, but with 0% schema coverage it does not explain the effect of null defaults or how each flag affects the node. It only partially compensates for the missing parameter 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?
The description uses a specific verb ('Set') and resource ('display, render, and/or bypass flags on a node'), clearly distinguishing this from sibling tools like set_cop_flags and modify_node. The scope 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives, nor any exclusions. Usage is merely implied by the description; there is no explicit context or prerequisites.
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?
No annotations are provided, and the description only says 'set the playback range' without disclosing side effects, such as whether it overwrites the existing range, validates bounds against the global range, or requires a cooked timeline. The 'subset' hint adds minimal context but doesn't describe behavior on failure or clamping.
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?
One short sentence that gets straight to the point, with no filler. It's concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with no annotations or output schema, the description covers basic purpose but misses crucial details like unit format, parameter validation, and interaction with the global range, making it insufficient for safe autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has two numeric params (start, end) with no descriptions. The description doesn't explain units, ordering, or constraints, and only indirectly implies these define the subset boundaries. With 0% schema coverage, more compensation was 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?
States a specific action: 'Set the playback range', and clarifies it as a 'subset of the global range', which distinguishes it from sibling tools like set_frame_range that likely modify the global range.
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?
Gives an implied usage context by noting it's a subset of the global range, but no explicit alternatives or exclusions are mentioned, so agents must infer when to use this over other timeline tools.
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, the description must carry full behavioral disclosure. It only says 'Uninstall from the current session' without explaining whether the operation is reversible, destructive, or restricted. It does not disclose error behavior or impact on other HDAs, which is a significant gap 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 a single sentence that directly states the tool's core function. No filler or redundancy. It is appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a destructive/uninstall operation with no annotations and no output schema, the description is incomplete. It lacks information about error handling prerequisites, and the exact implications of removing an HDA from the current session, making it risky for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the only parameter (file_path). The description adds minimal meaning by indicating 'HDA file' but does not clarify expected format, whether it is a file system path or asset name, or how it relates to installed HDAs. It does not compensate for the 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?
The description clearly states the action ('Uninstall'), the resource ('an HDA file'), and the scope ('from the current session'). This distinguishes it from sibling tools like hda_install, hda_create, and update_hda.
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 naming the action, but provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, side effects, or conditions under which uninstalling is appropriate, despite several HDA-related sibling tools.
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 only mentions the optional parent take, but omits potential side effects (e.g., whether the new take becomes the current take), return values, or prerequisites. This is a significant gap for a creation 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 a single sentence, concise and front-loaded with the action. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation-like tool with no annotations and no output schema, the description should provide more context about side effects, state changes, or requirements. The current description leaves important unknowns (e.g., what happens to the current take), making it incomplete for an AI agent.
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 schema has 2 parameters with 0% description coverage. The description adds meaning by clarifying that parent_name is a 'parent take', but it does not elaborate on the name parameter or specify any constraints on the hierarchy. It partially compensates for the schema's lack of 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?
The description clearly states the tool's function: 'Create a new take' with a specific resource (take) and verb (create). It is distinct from sibling tools like list_takes, get_current_take, and set_current_take, which handle different operations.
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 when to use the tool (when you want to create a new take) but does not explicitly differentiate from alternatives or mention exclusions. There is no guidance about when to use create_take versus other take-related tools, beyond the obvious verb difference.
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, the description carries the full burden. 'Get info' implies a read-only operation, but it does not disclose what specific info is returned, whether the plane/layer must exist, or any error behavior. The lack of an output schema also leaves the return format unspecified.
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 a single, concise sentence that front-loads the verb and object. There is no wasted wording or redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with two parameters and no output schema, the description gives a basic idea but lacks essential parameter semantics and usage context. An agent would likely need additional details about what 'path' refers to and what 'info' includes to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides minimal parameter guidance. The phrase 'plane/layer' hints at the plane_name parameter, but 'path' (the required parameter) is not explained, and the default value 'C' for plane_name is not mentioned. The description does not compensate for the 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?
The description clearly states the action ('Get info') and the target resource ('a specific plane/layer in a COP node'). This distinguishes it from sibling tools like get_cop_info or get_cop_geometry, which focus on node-level info or geometry.
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 usage is implied: use this tool when you need details about a plane/layer within a COP node. However, there is no explicit guidance on when to prefer it over alternatives (e.g., get_cop_info for node-level info) 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?
Description indicates the tool returns detailed info (type, parameters, inputs, outputs), implying a read operation. However, with no annotations, it does not explicitly state that the tool has no side effects, does not cook the node, or how errors are handled, leaving some behavioral ambiguity.
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?
Single sentence with no unnecessary words. It front-loads the verb and resource, and lists specific information categories, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description offers a basic outline of returned data but omits parameter format details, return structure, and error cases. It is minimal but not fully inadequate for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has one 'path' parameter with 0% description coverage, and the description does not describe the parameter format or meaning (e.g., absolute vs relative path, Houdini node path syntax). The tool's name and context imply 'path' refers to a node path, but this is not stated explicitly.
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 'Get' with resource 'node info', and enumerates the returned content: type, parameters, inputs, outputs. This clearly distinguishes it from siblings like get_node_doc or get_geo_summary.
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?
Description states what the tool does but provides no guidance on when to use it vs alternatives, no exclusions, and no use case examples. It leaves the decision entirely to the agent.
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 explicitly warns that the tool is 'known to crash the MCP connection (WinError 10054)' and instructs to pass allow_dangerous=True to proceed. This is a critical behavioral disclosure well beyond what schema or annotations (none) provide, making the tool's risk profile 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 two concise sentences: a clear purpose followed by a critical warning. It is front-loaded with the action and resource, with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter descriptions, this description is incomplete. It lacks details about what 'path' should be, what 'frame_range' does, the expected behavior after starting a render, and any return values or side effects beyond the crash warning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only the allow_dangerous parameter is explained ('Pass allow_dangerous=True to proceed'). The required 'path' parameter and optional 'frame_range' are not described at all, and with 0% schema description coverage, the description fails to compensate for the missing semantic meaning.
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 action ('Start a render') and the resource ('from a ROP node'), which is specific and understandable. However, it does not explicitly differentiate among the many render-related sibling tools (e.g., render_flipbook, render_single_view), so it is clear but not fully distinguishing.
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?
There is no guidance on when to use this tool versus alternatives. The only usage hint is the warning that allow_dangerous=True is required to proceed, which is a conditional instruction, but it does not help select this tool over other render options.
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 transparency burden. It explicitly lists the output components (child count, attr count, active, payload), which fully discloses what the tool returns. It does not mention side effects, but this is a read-only stat query, so no side effects are expected.
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 a single, well-structured sentence that front-loads the core purpose and lists specific stats. Every word contributes value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description is incomplete due to the unexplained 'path' parameter and lack of any output schema. It does not provide enough context for a correct invocation, especially regarding the distinction between the two parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no parameter descriptions (0% coverage), and the description does not explain the meaning of 'path' or 'prim_path'. 'path' is especially ambiguous (could be a USD file path or node path), and the description offers no clarification, leaving the agent unable to correctly infer parameter semantics.
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 action ('Get stats') and the resource ('a USD prim'), and enumerates the specific stats returned (child count, attr count, active, payload). This distinguishes it from sibling tools like get_usd_attribute or list_usd_prims.
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 use when needing prim-level stats, but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention any alternative tools. Although the context is clear, the absence of exclusions or alternatives keeps it at a basic level.
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 is the only source of behavioral information. It states the tool retrieves current settings but does not describe the return format, whether it reflects unsaved changes, or any side effects. For a simple zero-parameter getter, this is acceptable but lacks detail.
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 a single clear sentence, highly concise and front-loaded with the primary action. It contains no filler.
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 (zero parameters, no output schema), the description provides adequate context with examples of camera and shading settings, though it omits details on the exact structure of the returned data.
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 the schema is trivially complete. The description adds no parameter-specific information, but as per baseline for 0 params, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the resource as 'current viewport settings' with examples 'camera, shading, etc.' This clearly distinguishes it from the sibling set_viewport_* tools, though it could specify the exact settings returned.
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?
The description provides no explicit guidance on when to use this tool or alternatives. The 'Get' verb implies a read-only purpose, but there is no mention of using set_viewport_* tools for modifications or any context about use cases.
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?
The description explicitly mentions the optional recursive behavior, which is a key behavioral trait. However, since no annotations are provided, the description does not disclose anything about return format, error handling, or whether 'children' means direct children only, leaving some behavioral ambiguity.
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 entire description is a single eight-word sentence, with no filler or redundant information. Every word contributes to the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list operation, the description covers the core action and both parameters. However, without an output schema, it does not describe the return value shape, and it lacks any usage context or error behavior, leaving some gaps for a not-so-obvious tool.
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 description maps the 'path' parameter to the node whose children are listed and 'recursive' to the optional recursion, adding meaning beyond the bare schema property names. However, it does not provide details about path syntax or the exact effect of recursion beyond the boolean flag.
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 'List' and a clear resource 'children of a node', with the optional recursive flag. It clearly communicates what the tool does and is distinct from sibling tools like list_materials or layout_children.
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 such as layout_children or list_materials, nor are any exclusions given. The agent must infer usage from the tool name and sibling context.
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, the description carries the full burden of behavioral disclosure. It only states 'List available COP node types' and does not describe the return format, whether it reflects the current scene or installed plugins, or any potential side effects. It implies a read-only operation but does not explicitly confirm 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?
The description is a single, direct sentence that states the tool's purpose with no wasted words. It is appropriately concise for a parameterless listing tool, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is minimal but lacks details about the output format or any context sensitivity (e.g., whether 'available' means types usable in the current session or all possible types). However, the absence of parameters and output schema reduces the need for extensive elaboration, making this adequate but not rich.
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 no parameters, so schema coverage is trivially 100%. The baseline for 0 params is 4, and no additional parameter semantics are needed since there is nothing to clarify 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: listing COP node types. It uses the specific verb 'list' and resource 'COP node types', which distinguishes it from sibling tools like list_node_types or list_material_types.
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 like list_node_types or list_material_types. There is no mention of context, exclusions, or any decision-making information, leaving the agent without direction on selecting this tool.
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 for behavioral disclosure. It explicitly warns about a known crash (WinError 10054) and explains that allow_dangerous=True is required to proceed, providing a significant safety-relevant behavior beyond the schema.
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 two sentences and front-loads the core purpose, followed by a critical warning. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description is too sparse. It does not mention what the render outputs, how render_path is used, or the distinction between karma_engine and render_engine, leaving the agent without sufficient context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only hints at allow_dangerous ('Pass allow_dangerous=True to proceed'). It does not explain camera_path, render_path, karma_engine, or render_engine, leaving most parameters semantically unclear.
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: 'Render from a specific camera path in the Houdini scene.' It names the verb (Render), resource (specific camera path), and scope (Houdini scene), distinguishing it from sibling render tools like render_single_view or render_quad_views.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention when to prefer this over render_single_view, start_render, or render_flipbook, nor does it provide context for appropriate usage scenarios.
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?
No annotations are provided, so the description must disclose behavioral traits. It states that it saves the current scene and optionally to a new file path, but it does not explain overwrite behavior, what happens if no file path exists, or whether the scene is saved in place or as a copy. This leaves important behavioral aspects unclear.
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 a single sentence, front-loaded with the action, and contains no fluff. It earns its place efficiently and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional parameter, no output schema), the description covers the main purpose and the optional parameter. However, it lacks details about behavior when file_path is omitted (saving to the current path) or potential side effects, making it minimally 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 only parameter, file_path, is semantically explained as 'a new file path', which maps directly to the description's mention of optionally saving to a new path. However, no additional details about path format, relative/absolute, or expected extensions are given, and the schema has no description for the parameter.
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 the specific verb 'Save' with the resource 'current Houdini scene', clearly distinguishing it from load_scene and other scene-related tools. The optional file path is also mentioned, making the 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool vs alternatives like load_scene. The context is clear (saving a scene), but no exclusions or alternative recommendations are provided, leaving usage to be implied.
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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action, with no mention of side effects (overwriting existing values), validation, error handling, permissions, or reversibility. This is a significant gap 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 a single, concise sentence that front-loads the action and resource. Every word is purposeful, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters (one being a nested object), no output schema, and no annotations, the description is severely under-specified. It lacks information about how parameters are structured, whether successful setting returns anything, and what edge cases exist. The minimal description may confuse an agent attempting to construct valid calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not compensate. While 'multiple parameters' hints that the 'parameters' object contains key-value pairs, it does not explain the structure of node_path or parameters, nor provide examples or constraints. The description adds minimal value over 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 action ('Set'), the resource ('multiple parameters'), and the scope ('on a node'). It distinguishes from singular set_parameter by highlighting 'multiple parameters at once', making the purpose clear and differentiated from siblings.
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 phrase 'multiple parameters at once' implies this tool is for batch setting as opposed to setting one parameter at a time, providing clear context. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of explicit when/when-not 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?
The description discloses the key behavioral traits of atomicity and undo grouping, which are valuable. However, with no annotations provided, it omits details about error handling, permissions, or whether operations are executed sequentially or in parallel.
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 remarkably concise at two sentences, front-loaded with the primary purpose and a concrete example. Every phrase earns its place, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a generic batch tool with no annotations, output schema, or parameter descriptions, the description is far from complete. It does not specify which operation types are valid, how errors are handled, what the return value is, or any constraints on the operations array, leaving the agent to guess for correct invocation.
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 schema only defines an array of objects with no descriptions, while the description provides an example operation structure ('type' and 'params'). This adds some meaning but does not enumerate valid operation types or provide parameter schemas for each type, leaving significant ambiguity.
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 multiple operations atomically in a single undo group, specifies the operation format with an example, and distinguishes it from individual operation tools like create_node.
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 phrase 'multiple operations atomically' implies use when atomicity across several actions is required, but there is no explicit statement of when to use this tool versus alternatives, nor any exclusions 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?
With no annotations, the description carries the burden of behavioral disclosure. It implies a read-only operation by saying 'Return,' and adds the performance nuance 'cheapest.' Yet it does not explain what 'changed' means (e.g., relative to default values), how results are returned, or potential edge cases like no changed parameters.
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 succinct and well-structured. It front-loads the primary action in the first sentence, adds a performance-oriented use-case phrase, and concludes with a necessary prerequisite. No unnecessary 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?
For a simple one-parameter read-only tool, the description covers the core purpose and environment requirement. It does not describe the return format, but the absence of an output schema and the low complexity make this a minor gap; the tool is still reasonably usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'path' parameter at all. The schema only provides 'path' as a string, and while it is somewhat self-explanatory, the description adds no extra meaning about the expected node path format or resolution context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Return only the changed parameters for a node.' It clearly states what the tool does and hints at its niche (the cheapest 'what did I tweak' call), though it does not explicitly distinguish itself from sibling parameter tools like get_parameter.
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 context for when to use the tool ('what did I tweak' call) and a prerequisite ('Requires a Houdini connection'). However, it does not mention when not to use it or compare it with alternatives such as get_parameter or get_parameter_schema.
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 transparency burden. It clearly indicates a read-only 'get info' operation and lists the returned fields, but it does not disclose potential error conditions, whether the node must exist, or if any cooking occurs. This is adequate for a simple getter but lacks richness.
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 a single, front-loaded sentence: 'Get info about a COP node: resolution, planes, depth.' No filler words, and the key information is immediately presented.
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 tool is simple with one parameter and no output schema. The description lists the three key pieces of information returned (resolution, planes, depth), which is sufficient for basic understanding. It omits error behavior but is otherwise complete for such a straightforward tool.
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 schema only defines 'path' with no description, and schema coverage is 0%. The description implicitly clarifies that 'path' refers to the COP node path via 'about a COP node', adding meaning. However, it does not specify path format or constraints, so the compensation is partial.
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 info about a COP node with specific details (resolution, planes, depth). This distinguishes it from siblings like get_cop_geometry and get_cop_layer, which focus on different aspects.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention any exclusions or alternative tools for related operations, leaving the agent to infer usage solely from the name and description.
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 carries the full burden. It discloses the output content (counts, bounding box, attribute names) but does not mention whether the operation is read-only (implied by 'Get'), whether it triggers a cook, what node types are valid, or error behavior. It adds some transparency over the name but lacks richer behavioral 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?
The description is a single, efficient sentence that lists the key stats. Every word contributes to conveying the tool's purpose, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description gives a clear idea of the returned data but omits details on return format, required node type, and potential errors. For a basic summary tool, it is mostly adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the node_path parameter at all. The schema only provides a title and type, which is minimal. The description should ideally specify that node_path points to a geometry node or what kind of node is expected, but it does not, failing to compensate for the low 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 its resource "geometry stats," and specifies exactly what is included: point/prim/vertex counts, bounding box, and attribute names. This distinguishes it from sibling tools like get_points, get_prims, get_bounding_box, and get_attrib_values, which focus on individual aspects.
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 appropriate usage (as a summary for geometry stats) but does not explicitly state when to use this tool over more specific siblings, nor does it mention any exclusions or alternatives. For example, it does not say 'if you need individual point positions, use get_points.'
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 carries the burden of behavioral disclosure. It implies a read-only operation via 'Get' and describes the output as the full parameter schema, but it does not specify behavior for invalid node paths, return structure, or potential side effects. This is adequate for a simple getter but not rich.
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 a single, front-loaded sentence with no filler. The parenthetical '(all parm templates)' clarifies the term 'parameter schema' without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only tool, the description covers the essential purpose and input. However, the absence of an output schema and annotations means the description could usefully mention path format or return structure. It is minimally viable but leaves some gaps for a smooth agent interaction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only says 'for a node,' which largely restates the node_path parameter name without adding format details, examples, or constraints. The parameter is self-explanatory in isolation, but the description adds little 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 action ('Get') and the specific resource ('full parameter schema (all parm templates) for a node'). This directly distinguishes it from sibling tools like get_parameter (which fetches parameter values) and get_node_doc (which retrieves documentation).
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 usage context is implied: use this tool when you need the complete parameter template list for a node. However, there is no explicit guidance on when not to use it or mention of alternatives such as get_parameter for parameter values.
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 provided, the description carries the full burden. It discloses that the tool returns positions and optional attribute values, and that pagination is supported. However, it does not elaborate on pagination mechanics, potential cooking side effects, or exact return format, leaving room for more 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 two sentences, front-loads the main action, and contains no filler. It efficiently states the purpose and key return content, making it highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a basic overview but omits details like pagination response structure (e.g., total count, next token), error conditions, and whether it triggers a cook. Given no output schema or annotations, these omissions leave the description incomplete for seamless use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'pagination' (implying start/count) and 'optional attrib values' (implying attribs). However, it does not explain the exact meaning of start and count, nor the expected format for attribs (array of strings), which are critical 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's action: 'Get point data with pagination.' It also specifies the return content ('positions and optional attrib values'), which distinguishes it from sibling tools like get_prims (primitive data) and get_attrib_values. The verb-resource pairing 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving point data with pagination, but does not explicitly state when to use it over alternatives (e.g., get_prims for primitives, get_attrib_values for attribute data). No exclusions or alternative references are provided, leaving usage guidance only implicit.
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, the description carries full responsibility for behavioral disclosure. It only restates the basic action and provides no information about return format, edge cases (e.g., empty selection), or safety profile. The description adds no behavioral context beyond the name.
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 a single, concise sentence with no wasted words. It is appropriately sized for the simplicity of the tool.
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 (0 parameters, no output schema), the description is mostly complete. However, it does not specify the form of the returned nodes (e.g., paths, names), which would be useful for an agent. This small gap prevents a perfect score.
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 no parameters, and the schema is empty with 100% coverage vacuously. According to the rubric, a 0-parameter tool receives a baseline of 4, and the description does not need to add parameter semantics.
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 ('Get') and resource ('currently selected nodes in Houdini'), clearly distinguishing it from sibling tools like set_selection. It unambiguously states what the tool does.
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, nor are any exclusions or context mentioned. The description simply states the function without any usage direction.
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 the burden of disclosing behavior. It states the action but does not mention whether the operation is read-only, how invalid paths are handled, or what the response format is. For a simple list operation, this is minimally adequate but adds little beyond the tool name.
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 a single sentence with no redundancy. It is front-loaded with the core action and resource, making it easy to parse quickly.
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 one parameter and no output schema, the description covers the essential purpose. 'List all channels' implies a list of channel names is returned. It could explicitly state the return type or mention edge cases, but overall it is sufficiently complete for this simple tool.
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 only 'path' with a 0% description coverage, so the description must compensate. It hints that the path refers to a CHOP node, but it does not specify the path format, constraints, or whether it is a node path or name. This provides some meaning but leaves significant gaps.
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 ('List') and identifies the exact resource ('all channels in a CHOP node'). This clearly distinguishes it from sibling tools like list_materials or list_cop_node_types, leaving no ambiguity about what the tool does.
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?
There is no guidance on when to use this tool versus alternatives such as get_chop_data or list_node_types. No context about prerequisites, typical scenarios, or exclusions is provided, leaving the agent to infer usage from the name alone.
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 only states the action 'move' without explaining consequences (e.g., removal from old parent, effect on connections, potential naming conflicts). This is a significant transparency gap for a state-changing operation.
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 a single sentence with no filler words. It is appropriately sized for the tool's simplicity and front-loads the key action ('Move a node').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description gives the core purpose, but it lacks parameter descriptions and behavioral details. It is minimally viable but not complete, especially given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain the meaning of 'path' or 'destination_path' beyond their self-evident names. No additional context is provided about how these parameters should be formatted or what they refer to exactly.
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 'move' with a clear resource ('node') and destination ('new parent network'). It distinguishes from sibling tools like copy_node, rename_node, and connect_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?
The description clearly implies the use case: when a node needs to be reparented to a different network. It does not explicitly mention alternatives or when not to use, but the context is clear enough for selection.
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?
There are no annotations, so the description carries the burden of disclosing the mutation. It clearly states that the current frame in the playbar is changed, but does not elaborate on side effects such as whether the scene recooks, whether fractional frames are accepted, or whether the operation is undoable.
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 a single, front-loaded sentence with no filler. Every word contributes to the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description covers the core operation, but it does not address the presence of closely related sibling tools like get_frame, set_frame_range, or playbar_control, nor does it mention return behavior or edge cases. It is minimally complete but lacks helpful differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the 'frame' parameter beyond what the schema's title already implies. With 0% schema description coverage, it fails to add semantics such as allowed values, integer vs. float, range, or the relationship between the parameter and Houdini's timeline.
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 the specific verb 'Set' and identifies the resource as 'the current frame in Houdini's playbar', making the tool's function immediately clear. It also distinguishes this from sibling tools such as get_frame and set_frame_range.
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 setting the current playhead frame, but it does not explicitly state when to use this tool versus alternatives like set_frame_range or playbar_control. No exclusions or recommended contexts 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?
With no annotations, the description carries the burden. It discloses that the fetch is live from houdinimd.jchd.me and that no Houdini connection is needed, which adds genuine context. However, it does not mention potential failures, network dependency, or that it is a safe read-only operation, so transparency is only partial.
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?
Two concise sentences, action-first, with the example bolted on. No filler. The key details (content, source, connection requirement) are all present and front-loaded.
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 single-parameter fetch tool with no output schema and no annotations, this description covers the essential action, source, and return format. It could add note about error handling or path resolution, but the example and constraint make it fairly complete for an agent to invoke 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 schema has a single required 'path' with 0% description coverage, so the description must compensate. It provides a concrete example ('nodes/sop/attribwrangle') that clarifies the expected format, giving agents a strong hint. It stops short of specifying path syntax rules (e.g., whether extension is needed), but for one parameter this is adequate.
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 fetches the full markdown of a Houdini doc page, with a concrete example. However, it does not explicitly distinguish this from sibling tools like get_node_doc or search_docs, leaving some ambiguity about the exact 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 mentions it fetches live from an external site and does not require a Houdini connection, which provides context for when to use it. But it does not state when to prefer it over alternatives or when not to use it, so guidance is implied rather than explicit.
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?
No annotations are provided, so the description carries the full burden. It does not disclose behavior such as what happens if the variable is undefined, whether the name should include the '$' prefix, or whether any side effects or read-only guarantees exist. The description is purely functional with no added behavioral 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?
A single sentence with an effective example list. No wasted words, and the information is front-loaded. The parenthetical examples add concrete value without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description is adequate but minimal. It is missing details about return value format, error handling for unknown variables, and whether it only works for Houdini-specific variables vs OS environment variables. Given the absence of an output schema or annotations, a bit more behavioral detail would improve completeness.
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 schema provides only a 'name' property with no description. The tool description adds context by naming example variables ($HIP, $JOB), which suggests what to pass. However, it does not explicitly state whether the '$' prefix is required or optional, leaving ambiguity. It partially compensates for the 0% schema coverage but could be clearer.
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 'Houdini environment variable', with concrete examples ($HIP, $JOB) that distinguishes it from sibling tools like get_parameter or get_expression. The purpose is immediately 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 gives clear context for when to use this tool: to retrieve Houdini environment variables. It does not explicitly mention alternatives or exclusions, but the specificity of the resource makes the usage context apparent, especially when compared to the broader list of 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?
With no annotations provided, the description carries the full burden. It states the operation is a read-only list, but does not disclose return format, ordering, or whether group membership is included. Since it's a simple query, this is adequate but not rich.
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 a single sentence plus a compact list, with no redundant words. Every element earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two parameters and no output schema, the description covers the core purpose but lacks context about the return value and how it differs from get_group_members. It is minimally complete but not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains group_type with its possible values, but does not clarify node_path beyond the schema. Thus it adds partial value but leaves one parameter ambiguous.
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 'List geometry groups' uses a specific verb and resource, and the enumeration of group types ('point, prim, edge, vertex') adds scope that distinguishes it from sibling tools like get_group_members. It clearly communicates what the tool does.
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 when to use the tool (when needing to list groups of a given type) but provides no explicit exclusions or alternatives. There is no mention of similar tools like get_group_members, leaving the usage context only implied.
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 burden. The verb 'Get' implies a read-only, non-destructive operation, which is behaviorally transparent. However, it does not disclose any return format, pagination, or side effects beyond the basic retrieval semantics.
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 a single, front-loaded sentence that directly states the tool's purpose. No unnecessary words or repetition, making it highly concise and well-structured.
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?
This is a simple getter tool with two clearly named parameters and no output schema or annotations. The description provides enough context to understand its purpose within the broader toolset. It does not explain return values, but given the simplicity, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'on a parameter' but does not explain the roles of node_path and parm_name, nor any formats or constraints. The parameter names are slightly self-explanatory, but the description adds minimal 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 ('Get') and resource ('all keyframes on a parameter'), clearly stating the tool's function. It also distinguishes from sibling tools like set_keyframe or delete_keyframe by focusing on retrieval of all keyframes for a given parameter.
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 (when you need to retrieve keyframes) but does not provide explicit when-to-use guidance, alternatives, or exclusions. It is essentially a one-line description with no additional context.
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 burden. The verb 'get' conveys read-only behavior, and the phrase 'from a wrangle node' adds a target constraint. However, it does not disclose details about return format, error handling, or requirements beyond the node type, so it adds only modest context beyond the name.
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 a single, short sentence with no unnecessary words. It is front-loaded and immediately clear, earning a perfect score for conciseness.
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—one parameter and no output schema—the description covers the core purpose and return value implicitly ('get the VEX code'). However, it lacks details on output format or error behavior, though these are less critical for a trivial getter. It is mostly complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not mention node_path at all, leaving the parameter's semantics to be inferred from its name and the tool's purpose. The description adds little 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 the specific verb 'get' with a clear object 'VEX code' and target 'wrangle node'. This unambiguously states the tool's purpose and distinguishes it from siblings like set_wrangle_code or create_wrangle.
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 the tool is used to retrieve VEX code from a wrangle node, but provides no explicit guidance on when to use it versus alternatives, nor any exclusions. It gives only the essential context of the operation.
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 provided, the description carries the burden. It indicates a read-only listing operation implicitly, but it does not explicitly state that it has no side effects, nor does it describe any rate limits or return format. For a simple list tool, this is minimally adequate but leaves gaps.
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 a single sentence with no filler. It is front-loaded with the primary action and includes the optional filter as a concise qualifier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema and no annotations, the description is minimal. It does not clarify what 'available' means (e.g., current network context) or what the returned node type list contains. This is just at the minimum viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides the only parameter context: 'optionally filtered by category'. This clarifies that the category parameter is an optional filter, but it does not specify valid values or format, leaving the parameter semantics partially compensated.
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 'List available node types' uses a clear verb and resource, and the optional category filter adds scope. It distinguishes from sibling tools like list_material_types and list_cop_node_types by focusing on node types generally.
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 this tool is for discovering node types with an optional filter, but it does not explicitly state when to choose it over alternatives like list_material_types or get_network_overview. No exclusions or alternative recommendations are 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 provided, the description carries the burden of behavioral disclosure. It openly warns of a known crash (WinError 10054) and explains the require flag to proceed. This is significant and truthful transparency about a critical side effect, though it does not mention other behaviors like output handling.
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?
Two sentences, front-loaded with the tool's purpose and immediately followed by a critical warning. Every word earns its place, with no unnecessary detail or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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, the description is too sparse. It does not explain what the return value looks like, what the output parameter should contain (file path? pattern?), or the expected format of resolution and frame_range. The warning is valuable but leaves most usage context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 4 parameters, so the description must compensate. It only addresses allow_dangerous by linking it to the crash warning. The meanings of output, resolution, and frame_range are left entirely to inference from their names, with no format or default clarification. This is insufficient for safe use.
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 ('Render') and resource ('flipbook sequence from the viewport'), clearly distinguishing it from sibling render tools like render_single_view or render_specific_camera. The purpose is unambiguous and immediately understandable.
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 this tool is for rendering viewport flipbooks but does not explicitly state when to use it over alternatives (e.g., start_render for final renders). It does provide a usage prerequisite: 'Pass allow_dangerous=True to proceed,' which is helpful, but lacks explicit alternative 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 provided, the description carries the full burden of behavioral disclosure. It states the operation is a setter but doesn't disclose potential behaviors like whether it replaces the existing selection or validates paths. This is a minimal but acceptable level for a simple selection setter.
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 a single sentence with no redundant words. It front-loads the verb and object, achieving maximum clarity per word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema, no annotations), the description is adequate but leaves gaps: no usage guidance, no mention of return value, and no path format details. For an agent to confidently select and invoke this tool, a bit more context would be helpful.
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 provides only a parameter name 'paths' with no description, so the description's phrase 'node paths' adds valuable context. However, it doesn't specify path format (absolute/relative) or whether paths must be valid, leaving some ambiguity.
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 action with a specific verb ('Set') and resource ('node selection'), and distinguishes it from sibling tools like get_selection which retrieves selection. It also clarifies that the selection is set to a list of node paths.
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 no explicit guidance on when to use this tool versus alternatives, such as get_selection or set_current_network. However, the action is unambiguous and its usage is implied by the name and description.
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 carries full burden. 'Get' implies a safe read operation, and the description lists the data returned (value, type, expression, metadata), which is useful. However, it doesn't disclose error conditions, whether the parameter must exist, or side effects. It's sufficient for a simple getter but lacks behavioral depth.
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 a single, concise sentence that front-loads the core purpose. Every word contributes to understanding what the tool does, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 2 parameters and no output schema, but the description omits the return format or structure of 'metadata'. It also lacks guidance on prerequisites (e.g., node must exist). While it provides the primary purpose, it leaves gaps in what an agent should expect in the response, making it minimally viable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining node_path and parm_name. It does not explicitly describe what these parameters mean or how they are used, relying on the parameter names alone. With 0% coverage, the description should provide at least basic semantics, resulting in a low score.
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 retrieves a single parameter's value, type, expression, and metadata, which is a specific verb+resource combination. It distinguishes itself from siblings like get_expression (expression only) and get_parameter_schema (schema only) by covering all four aspects.
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 this tool is for when you need comprehensive information about a single parameter. It doesn't explicitly mention alternatives or exclusions, but the context suggests it's the go-to for full parameter details. No explicit 'when not to use' is stated, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It implies a read-only operation ('get'), but does not explicitly state that the scene is not modified or describe any potential caveats (e.g., performance cost, freshness of data). It does specify the output contents, which adds some transparency, but falls short of fully disclosing 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 a single, well-structured sentence that immediately states the purpose and key information included. It is front-loaded with the core action ('Get a high-level summary') and adds just enough detail (node counts, frame info) without unnecessary 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?
For a simple tool with no parameters and no output schema, the description is fairly complete: it tells the agent what to expect (node counts, frame info). However, it does not clarify how this summary relates to other overview tools in the sibling set (e.g., get_scene_info), which would help an agent choose among them. Still, the core information is present, so it is slightly above adequate.
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, and the schema coverage is trivially 100% (empty properties). The description does not need to explain parameter semantics since there are none. Baseline of 4 is appropriate for a parameter-less tool.
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: retrieving a high-level summary of the scene, with specific contents (node counts by category, frame info). The verb 'get' and resource 'scene summary' are explicit, and the inclusion of 'node counts by category' and 'frame info' differentiates it from more detailed or focused tools like get_scene_info or get_geo_summary.
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?
The description provides no guidance on when to use this tool versus alternatives such as get_scene_info or get_network_overview. There are no usage scenarios, prerequisites, or exclusions mentioned, leaving the agent to guess when this summary is appropriate.
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 carries the full burden of disclosing behavior. It states that it returns server status info or an error if unreachable, which is useful. However, it does not explicitly state that the operation is read-only or has no side effects, though 'health check' strongly implies this. It lacks details on permissions, rate limits, or any potential 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 two sentences, front-loaded with 'Health check', and contains no extraneous information. Every word contributes to understanding the tool's purpose and behavior.
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, parameterless tool with no output schema, the description is complete. It provides the purpose, return behavior, and error condition, which is sufficient for an agent to select and invoke 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 tool has zero parameters, and the schema coverage is 100%. According to the rubric, a baseline of 4 is appropriate for 0 params. The description does not need to add parameter semantics since there are none.
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's purpose as a health check to verify Houdini is connected and responsive. It uses a specific verb ('verify') and resource ('Houdini'), and mentions returning server status info or an error. However, it does not differentiate from the sibling tool 'get_connection_status', which may serve a similar purpose.
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 as a connectivity health check but does not explicitly state when to use it versus alternatives like 'get_connection_status' or 'get_connection_status' or 'get_scene_info'. There is no mention of exclusions or specific scenarios, so guidance is implied rather than explicit.
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 explicitly discloses a known crash issue ('WARNING: known to crash the MCP connection (WinError 10054)') and instructs to pass allow_dangerous=True. This is significant behavioral transparency beyond a typical render tool. However, it doesn't elaborate on other side effects or why the crash occurs, so it doesn't earn a 5.
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 two sentences with no wasted words. It front-loads the primary action and immediately follows with a critical warning. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and no output schema, the description is minimal but covers the primary return value (image paths) and the main risk. However, it does not explain what the 4 canonical views are, how the render engines differ, or what render_path expects. For a complex tool with 0% schema coverage, it leaves too much to inference, making it just adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all 4 parameters. It only mentions allow_dangerous, explaining its purpose ('Pass allow_dangerous=True to proceed'), but provides no meaning for render_path, karma_engine, or render_engine. This leaves 3 out of 4 parameters unexplained, which is a significant gap given the schema has no 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?
The description clearly states the tool's function: 'Render 4 canonical views from Houdini and return the image paths.' This is a specific verb+resource+scope (render quad views) and is distinguishable from sibling tools like render_single_view and render_specific_camera. It immediately conveys what the tool does without ambiguity.
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 when 4 canonical views are needed, but it does not explicitly mention when to use this tool over alternatives like render_single_view or render_flipbook. There is no guidance on exclusions or alternatives, only a warning. Context from sibling tools suggests multiple rendering options, so more explicit usage guidance would be beneficial.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions what the tool does (connects node pairs) but does not disclose error handling behavior, whether the operation is atomic, what happens on partial failure, or any prerequisites (e.g., whether source and destination nodes must already exist). This is a significant gap 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 compact and front-loaded: a single sentence with a clear action and a concise specification of the item structure. No unnecessary words or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool involves a batch operation with a nested object array, and there are no annotations or output schema. The description provides the basic semantics but omits critical context such as return values, error handling, ordering guarantees, or atomicity. It is minimally viable but lacks completeness for robust agent usage.
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 'connections' as an array of objects with no field details. The description compensates by specifying the structure of each object: {src_path, dst_path, dst_input_index, src_output_index}. This adds essential meaning beyond the schema, though it lacks type information or required-field clarification.
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: to 'Connect multiple node pairs at once.' This is a specific verb (connect) with a clear resource (node pairs) and distinguishes from the sibling tool 'connect_nodes' by emphasizing the batch nature ('multiple', 'at once').
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 when to use this tool (for multiple connections) versus the singular 'connect_nodes' sibling, but it does not explicitly state alternatives or exclusions. The context is clear enough for an agent to infer the batch use case, but no explicit when-not 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 carries the full burden, but it only states the action without disclosing return format, ordering, or whether hidden pane tabs are included. It is not contradictory, but lacks behavioral depth.
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 a single, trimmed sentence that front-loads the action and resource. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description identifies the scope but lacks detail on the return value structure (e.g., names vs. paths, tab IDs). With no output schema, this omission creates a minor gap for an agent deciding how to use the result.
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 the schema is empty and the description has no parameter details to add. The baseline of 4 applies because there is nothing to explain.
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 action (list) and the specific resource (all pane tabs in the Houdini desktop), which exactly distinguishes it from sibling tools like list_materials or list_children. It is a specific verb+resource statement.
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 is a simple list operation with no explicit guidance on when to use versus alternatives. Since it is self-contained and read-only, usage is implied, but no when-to-use or exclusionary context is provided.
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?
No annotations are provided, so the description carries the full burden. It states 'Set viewport direction' but does not disclose any side effects, whether it affects the camera, or if the change is persistent. It is not misleading but adds little beyond the tool's name.
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 a single, front-loaded sentence with no redundant words. It efficiently conveys the action and the parameter values.
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 one-parameter setter with no output schema, the description covers the essentials: what it does and what values are accepted. It lacks only minor behavioral context (e.g., whether the direction change is applied to the current viewport only), but the tool is simple enough that the given info 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?
The input schema only defines a string parameter with no description, and schema coverage is 0%. The description compensates fully by listing all accepted values (front, back, left, right, top, bottom, persp), providing essential information 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 sets the viewport direction and lists the exact supported directions (front, back, left, right, top, bottom, persp), distinguishing it from sibling tools like set_viewport_camera and set_viewport_display.
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 changing viewport view direction, but does not explicitly mention when to use this tool versus alternatives or any exclusions. The list of directions gives some context, but there is no explicit 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?
No annotations are provided, so the description carries the full burden. It discloses the valid event types and the default behavior of None/empty meaning all events. However, it does not explain side effects such as whether previous subscriptions are replaced or whether the configuration persists.
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 long, front-loaded with the purpose, and every sentence adds value: what it does, the valid types, and the default behavior. 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 the core aspects: purpose, event types, and default behavior. However, given no output schema and no annotations, it lacks details on how this tool interacts with get_houdini_events or whether the subscription replaces or augments existing configured types.
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 zero description coverage, but the description fully compensates by listing all valid event types and specifying that passing None/empty subscribes to all events. This gives complete semantic meaning to the 'types' parameter beyond the bare 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 the tool's purpose with a specific verb ('Configure') and resource ('Houdini event types'), and lists the exact supported types. However, it does not explicitly differentiate from the sibling tool get_houdini_events, which likely retrieves the collected events.
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 setting up event collection but does not explicitly say when to use this tool versus alternatives like get_houdini_events. There is no mention of prerequisites, exclusions, or ordering relative to other 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?
With no annotations, the description carries the full burden. 'Frame the viewport on all geometry' states the primary behavior, but it does not disclose any additional behavioral traits such as which viewport is affected, whether camera settings are altered, or any prerequisites. This is adequate for a simple command but lacks depth.
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 a single, front-loaded sentence that efficiently states the tool's purpose without unnecessary words. Every word earns its place.
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 no parameters and no output schema, the description sufficiently conveys the core functionality. It is complete enough for a simple viewport operation, though it could optionally mention which viewport is targeted or that it affects the current view.
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, and the schema is an empty object. According to the baseline for 0 params, the description does not need to add parameter information. The baseline of 4 applies.
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 frames the viewport on all geometry, using a specific verb and resource. It distinguishes itself from the sibling tool frame_selection by explicitly focusing on all geometry rather than the current selection.
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 usage is implied by the description: use this to frame all geometry. However, there is no explicit guidance on when to use this versus frame_selection or other viewport tools. No alternatives or exclusions are mentioned.
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 bears full responsibility for behavioral transparency. It states the operation ('frame the viewport') but doesn't disclose prerequisites (e.g., valid selection) or side effects (e.g., changes camera). For a simple viewport operation, this is adequate but lacks depth.
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, front-loaded sentence with no filler. It conveys the essential action efficiently.
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 parameterless tool with no output schema, the description sufficiently explains the tool's action. However, it could benefit from a note about the relationship to 'frame_all' for full context, so it is complete but not exhaustive.
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?
There are zero parameters, so the baseline is 4. The description correctly omits any parameter details, as there are none to explain.
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 the specific verb 'frame' with the resource 'viewport' and scope 'current selection,' clearly distinguishing it from the sibling tool 'frame_all' which frames everything. It is precise 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (to bring the selection into view) but does not explicitly state when to use it instead of alternatives like 'frame_all' or 'set_viewport_camera.' No exclusion or alternative 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?
No annotations are provided, so the description carries the burden. The word 'get' implies a read-only, non-destructive operation, but the description does not disclose any behavioral traits such as return format, potential side effects, or whether it requires any context. It's minimal but not misleading, hence a mid-range score.
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 a single, concise phrase: 'Get the current frame and time.' It is appropriately sized for the tool's simplicity, with no unnecessary words or repetition, and it is front-loaded with the action.
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 simplicity of the tool (no parameters, no output schema, no annotations), the description is complete enough. It tells the agent what the tool does, and the expected return is intuitive for a frame/time getter. However, it could have explicitly stated the return format or clarified that it does not modify state, but for this simple tool the gap is minor.
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, and the schema already fully covers this (100% coverage). The description adds no parameter details, but none are needed. The baseline for zero-parameter tools is 4, and the description does not detract from this.
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: 'Get the current frame and time.' It uses a specific verb ('get') and resource ('current frame and time'), and it is unambiguous. Although there are sibling tools like set_frame, the get/set distinction makes it clear, so it distinguishes from 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 retrieving the current frame and time, but it does not explicitly state when to use it versus alternatives or any exclusions. Since it's a simple getter with no obvious alternatives, the implied usage is acceptable but not explicitly guided.
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 burden. It indicates a read-only listing operation but does not disclose whether the list is current, what exactly is included (VEX shaders, standard shaders, custom HDA types), or if any context affects the result. Still, for a simple listing tool, the behavior is fairly obvious.
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 a single, clear sentence that immediately conveys the action and target. It is concise without unnecessary elaboration.
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 nature (no parameters, no output schema), the description is mostly complete. It communicates the essential purpose, though it could mention the return format or any side-effect-free guarantee, but that's not critical for such a basic 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?
The tool has zero parameters, so the input schema is empty. The description doesn't need to add parameter semantics. Baseline 4 for no-parameter tools is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List') and resource ('material/shader node types'). It distinguishes itself from sibling tools like list_materials (which likely lists materials) and list_node_types (which covers all node types).
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?
Usage context is implied: the tool is for enumerating material/shader node types. However, there is no explicit guidance on when to use it versus related tools like list_materials or list_node_types, nor any exclusions or prerequisites.
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 behavioral disclosure. It clearly states the return values (status and stdout/stderr) and the safety behavior (blocking dangerous patterns unless allow_dangerous=True). This is valuable context beyond the raw schema, though it does not mention potential side effects or execution context limitations.
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, front-loaded with the primary purpose, followed by return behavior and safety mechanism. Every sentence earns its place with no redundancy or filler.
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 and lack of output schema, the description is fairly complete: it explains the execution target, return values, and security guardrails. It does not cover timeout behavior or side-effect risks beyond the blocked patterns, but for an arbitrary code executor, this is a reasonable level of detail.
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 the description must compensate. It explains the 'code' parameter implicitly through the 'Execute arbitrary Python code' clause, and explicitly explains allow_dangerous by describing the dangerous-pattern blocking and the bypass condition. This adds meaning to both parameters beyond their schema definitions.
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 ('Execute') and clearly identifies the resource (arbitrary Python code in Houdini's environment). It also distinguishes itself from siblings like execute_hscript by specifying 'Python code' rather than Hscript. The scope 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for running Python code in Houdini and gives a clear condition for when allow_dangerous should be set. However, it does not explicitly state when to prefer this tool over alternatives like execute_hscript or evaluate_expression, nor does it mention any exclusions or prerequisites.
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 internal process (querying the plugin, retrieving from an external markdown source) and the prerequisite of a Houdini connection. It does not cover failure modes or return format details, but the provided behavior is transparent enough for a read-oriented 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 three sentences, front-loaded with the main purpose, and each sentence adds value: what it does, how it works, and a key requirement. 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?
For a simple single-parameter tool with no output schema, the description covers the essential context: what is fetched, the process, and a requirement. It does not detail return values or error scenarios, but the markdown retrieval is sufficiently implied.
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 schema has one parameter 'path' with no description, so the description must compensate. It implies path refers to the scene node path, but does not specify path syntax or examples. This gives partial meaning but lacks precision.
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 fetches documentation for a scene node in one call, with a specific verb and resource. It distinguishes from sibling doc tools like search_docs and get_doc by focusing on scene nodes and consolidating the process into a single call.
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: it is for retrieving documentation of a scene node and requires a Houdini connection. It does not explicitly mention alternatives or when not to use it, but the context is sufficient for most cases.
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 the full burden of behavioral disclosure. It clearly states a read-only listing operation with scene-wide scope, which is transparent. It does not mention output format, but that is not a behavioral trait like side effects or permissions.
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 a single sentence that is concise and front-loaded with the most important information. There is no wasted wording or unnecessary detail.
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 list tool with no parameters and no output schema, the description adequately conveys the purpose and scope. It does not detail the return format, but the verb 'list' implies a list of nodes, which is sufficient for tool selection and invocation.
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 and the schema is empty, so there is no parameter information to clarify. The baseline for zero parameters is 4, and the description does not need to add parameter semantics.
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 action ('List'), the specific resource type ('ROP (render) nodes'), and the scope ('in the scene'). It distinguishes itself from sibling tools like list_materials or list_node_types by focusing on render nodes specifically.
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 when the agent needs to enumerate all render nodes in the scene, but it does not explicitly mention when to use this tool versus alternatives like find_nodes or list_children. There is no guidance on exclusions or alternative tools.
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 burden of behavioral disclosure. 'List' implies a read-only operation with no side effects, which is transparent and accurate. It does not mention error conditions or ordering, but for a simple list 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence: 'List all takes in the scene.' It directly conveys the action without any unnecessary words or 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?
Given the tool's simplicity (no parameters, no output schema), the description is complete enough to inform an agent about its purpose. It could explicitly state the return format (e.g., names), but the phrase 'list all takes' strongly implies a list of takes, making this adequate.
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, and the baseline score for 0 params is 4. Since there are no parameters, the description does not need to provide any parameter-specific semantics.
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 'List all takes in the scene' clearly states the action (list), the resource (takes), and the scope (in the scene). This is a specific verb+resource and distinguishes itself from sibling tools like get_current_take, set_current_take, and create_take.
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 enumerating takes but does not explicitly mention when to use this tool versus alternatives such as get_current_take or set_current_take. The context is clear from the name and description, but there are no exclusions or explicit alternatives.
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 for behavioral disclosure. It explicitly states the side effect of clearing the buffer after returning events, which is a key behavioral trait. It also mentions the optional timestamp filtering and the types of events returned. This provides good transparency, though it doesn't specify the exact structure of returned events.
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 two sentences, front-loaded with the main purpose, and includes only relevant details. It efficiently covers the tool's behavior, side effect, and parameter without any 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?
For a simple one-parameter tool with no output schema, the description covers the essential aspects: what it does, how it behaves (clears buffer), and how to use the optional parameter. It doesn't describe the return format or event structure, but this is not critical given the context. It could also mention the relationship to subscribe_houdini_events, but that's a minor gap.
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 the description must compensate. It does so by explaining that the 'since' parameter is a timestamp to filter events after a given time. This adds critical meaning that the raw schema (type number, default null) lacks, though it could be more specific about the timestamp format (e.g., Unix seconds).
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 ('Get') with a clear resource ('pending Houdini events') and lists event categories (scene changes, node operations, frame changes). It distinguishes itself from the sibling subscribe_houdini_events by emphasizing 'pending' and 'clears the buffer', which implies a polling mechanism rather than a continuous subscription.
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 clearly implies a polling workflow ('since last poll', 'clears the buffer') and explains how to use the optional timestamp to filter events. However, it does not explicitly mention the alternative subscribe_houdini_events or state when to use this tool versus that one, so it falls short of explicit when/when-not guidance.
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 takes on full responsibility. It discloses a key behavioral trait: it runs on the bridge side without requiring a Houdini connection. It also explains the optional output_path parameter triggers file existence and size reporting, which adds transparency about the tool's behavior and capabilities.
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 two sentences, each earning its place. The first states the core purpose; the second adds the optional parameter behavior and the important context of bridge-side execution. No redundancy or filler.
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 status-check tool, the description covers the core functionality, the optional parameter, and the architectural context (bridge-side, no Houdini connection). However, it does not specify the return value format (e.g., boolean or status object), and with no output schema, this is a noticeable gap. Still, the tool is simple enough that the description 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?
The only parameter, output_path, receives meaningful explanation beyond the raw schema. The description states it is optional and that passing it will additionally report file existence and size, 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 the tool's function: checking if Karma (husk) or Mantra (mantra-bin) renders are still running. It names specific engines and explicitly mentions the optional output_path behavior, which distinguishes it from sibling tools like start_render or get_render_progress.
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 specifies when to use the tool (to check render status) and adds valuable context that no Houdini connection is needed because it runs on the bridge side. It does not explicitly exclude alternatives or mention when not to use it, but the clear purpose implies the intended 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?
With no annotations, the description fully discloses the tool's behavior: ranks paths by token overlap, does not download content, returns specific fields, and does not require a Houdini connection. This is excellent transparency for a read-only search operation, leaving no surprises.
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?
Three short sentences with every sentence contributing unique information: purpose, ranking method, return format, and connection independence. Front-loaded and highly efficient, with no filler.
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 low complexity (2 simple params, no output schema, no annotations), the description covers what the tool does, how it works, what it returns, and a key environmental constraint. The explicit return fields substitute for an output schema, making the description self-sufficient.
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 schema has query and top_k, but the description only implicitly covers query via 'token overlap' and never mentions top_k or its role as a result count. With 0% schema coverage, the description should explicitly tie parameters to behavior, though the simplicity of the parameters mitigates the gap.
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 searches Houdini documentation via an online proxy, identifying a specific resource and action. It distinguishes itself from doc-retrieval tools like get_doc or get_node_doc by emphasizing no content download, no Houdini connection, and returning search results with scores.
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 a clear usage context: use this when you need to search documentation without a Houdini connection. However, it does not explicitly name alternatives or state when NOT to use it (e.g., when you need full doc content). The sibling list implies alternatives but the description could be more explicit.
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:

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

Score Badge

Copy to your README.md:

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

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/JTCHE/houdini-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server