opera-houdini-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation2/5
Many tools have overlapping purposes, such as get_geo_summary vs get_geometry_info, verify_hou_api vs get_houdini_help, and get_scene_info vs get_scene_summary. The sheer number of similarly named get_* and create_* tools makes it difficult for an agent to select the correct one without reading extensive descriptions.
Naming Consistency2/5Tool names follow no single consistent pattern: some use verb_noun (set_parameters), some use prefix-based conventions (hda_list, pdg_cook, lop_prim_get), and others mix forms (uninstall_hda vs hda_install). This inconsistency increases cognitive load and makes predictions about tool names unreliable.
Tool Count1/5With 174 tools, this server vastly exceeds the typical well-scoped range of 3-15 tools. The extreme count overwhelms agents and likely degrades selection accuracy, making it an extreme mismatch for a coherent MCP surface.
Completeness5/5The server provides extensive CRUD/lifecycle coverage across Houdini's major domains: nodes, parameters, geometry, rendering, DOPs, COPs, CHOPs, LOPs, PDG, materials, HDAs, takes, caches, and even a knowledge base. No obvious dead ends or significant missing operations were found.
Average 3.7/5 across 174 of 174 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 102 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.jsonto 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?
No annotations are provided, and the description gives no behavioral details: does it overwrite existing parameter links? Is it reversible? What errors might occur? The phrase 'channel reference' is ambiguous and leaves the agent with no understanding of side effects or requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It avoids padding but omits essential information needed for a tool with seven parameters, making it inefficient in practice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema, no annotations), the description is woefully incomplete. It fails to explain the core functionality, parameter semantics, or expected outcomes, making it nearly impossible for an agent to apply the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 lists only four of seven parameter names (chop_path, channel, target_path, target_parm) without explaining their meaning, types, or relationships. Critical parameters like ctx, output_index, and replace_existing are omitted entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '建立 chop() 通道引用' essentially restates the tool name 'export_chop_to_parm' without clarifying what the export does, whether it creates a link, writes data, or what 'reference' means. It fails to distinguish from sibling tools like get_chop_data or create_chop_node, which also deal with CHOP 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/5Does 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, scenarios, or exclusions. The parameter list 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?
No annotations are present, so the description must fully disclose behavior. It mentions 'NO_UNDO' and 'apply_response_cap', which are behavioral hints, but they are cryptic and unexplained. It does not state whether the tool is read-only or mutating, or what side effects might occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and could be considered concise, but it is under-specified. It is not front-loaded with a clear purpose; instead, it leads with a noun phrase and a parenthetical tag, which makes it harder to parse than a well-structured sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given 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 0% schema coverage, the description is the only source of context. It fails to describe return values, parameter usage, or operational effects. Given the tool's complexity, this is completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain any of the three parameters (ctx, node_path, max_layers). The phrase 'layer custom metadata / sublayer path' is the only hint, but it is not explicitly tied to the parameter names or required values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a fragment: 'layer 自定义元数据 / sublayer 路径' (layer custom metadata / sublayer path) with no clear verb like 'inspect' or 'get'. It hints at what the tool touches but does not state an action or resource clearly. As a result, it only weakly distinguishes itself from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 such as lop_layer_info or get_usd_composition. The description gives no context for selecting it or any 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?
The description mentions 'NO_UNDO' as a behavioral trait, which is useful, but with no annotations it fails to disclose whether the operation is read-only, what side effects it has, or any permissions needed. The reference to 'apply_response_cap' is obscure and adds little clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but it is under-specified, containing cryptic metadata like 'add-usd-solaris-tools' and 'apply_response_cap' that do not help an agent. It lacks a clean front-loaded purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given 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 terse description, the tool is severely under-documented. The description does not explain what the function returns, how the parameters relate, or any operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (ctx, node_path, prim_path) have 0% schema description coverage and the tool description does not explain them. An agent has no way to know what each parameter means or how to fill them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions 'variant set name and current selection', which hints at the tool's output, but it lacks an explicit verb like 'get' or 'retrieve'. It is vague but more informative than a tautology, so it partially conveys the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 other getters like get_usd_attribute or lop_prim_get. There is no mention of context, prerequisites, or alternative tools.
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 must disclose behavioral implications. The single sentence only says 'Create a new node' and gives no information about side effects, required permissions, or how the node is positioned or connected. Only the input schema suggests parent_path, but the description does not elaborate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise in the sense of being short, but it is under-specified and omits essential context. It is more of a placeholder than a well-structured description, and the single sentence does not earn its place as a useful guide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's multiple parameters and lack of annotations, the description is highly incomplete. It does not explain the role of parent_path or name, nor how node_type works. An output schema exists, but the description still leaves significant gaps in understanding the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines name, node_type, and parent_path, but the description does not mention any of them. Since schema description coverage is 0%, the description fails to add semantic meaning beyond the raw field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: creating a node in Houdini. It uses a specific verb and resource. However, it does not distinguish itself from other creation tools such as create_wrangle or create_cop_node, which also create nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not explain when to use create_node versus other tools, nor does it mention any prerequisites or alternatives. This leaves the agent without direction 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?
The description discloses that the tool is mutating, groups changes in a single undo step, returns an error if the parent is not Sop, and passes responses through apply_response_cap. However, it references parameter names 'snippet' and 'runover' that do not appear in the input schema (schema uses 'code' and 'attrib_class'), and the phrase 'apply_response_cap' is ambiguous. Since there are no annotations, the description carries full burden but the mismatch undermines 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and structured, but includes an unclear tag 'add-node-parameter-vex-tools' and a cryptic statement about apply_response_cap. It could be more focused and front-loaded, but it is not excessively verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description needs to cover parameters, usage, and behavior. It partially covers constraints and mutation but misses parameter explanations, usage vs alternatives, and return value semantics. Thus it's insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% description coverage, and the description only vaguely references 'snippet' and 'runover' without mapping them to 'code' and 'attrib_class'. It does list possible runover values but doesn't explain ctx, parent_path, or name. This is insufficient for an agent to understand how to populate the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates an Attribute Wrangle under a SOP parent, which is a specific action with a resource. However, it does not differentiate from the sibling tool 'create_wrangle' that likely has a similar purpose, so it gets 4 rather than 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/5Does 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 like create_wrangle or set_wrangle_code. It only mentions a constraint (parent must be Sop), which is not a usage guideline. There are no references to alternative tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It reveals important behaviors: it returns 'unsupported' when the information is unprovable, explicitly states it does not fabricate data ('不伪造'), and mentions NO_UNDO and server-side apply_response_cap. This adds meaningful context beyond the name, though it does not describe success return format or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (roughly three sentences), so it is concise, but the structure is not front-loaded: it begins with the unsupported condition rather than the tool's primary purpose. It also uses unexplained jargon like 'apply_response_cap' without definition, which hurts clarity. It is efficient but could be better organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two required parameters, no output schema, and no annotations, the description is incomplete. It provides some limitation context (unsupported condition, no fabrication) but omits parameter meanings, success return value, typical use cases, and any relationship to sibling tools. The description is not sufficient for an agent to confidently use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two required parameters, ctx and node_path, with no descriptions in the schema, and schema description coverage is 0%. The tool description does not mention either parameter at all, leaving their semantics completely unexplained. This is a severe gap for an agent attempting to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The name 'get_last_modified_prims' strongly suggests the tool retrieves prims by last modification, and the description mentions 'last-modified ordering' and 'recent modification info.' However, the description focuses on the unsupported case rather than clearly stating the core function (e.g., 'Returns prims sorted by last modification time'). The purpose is implied rather than explicitly defined, and no sibling differentiation is needed as no similar tool exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It only mentions that it returns 'unsupported' when last-modified info cannot be proven, which is a limitation but not a clear usage instruction. There is no 'use this when...' statement, no exclusions, and no reference to 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?
There are no annotations, so the description carries the full burden. It does not disclose side effects (e.g., whether it changes the current take), required context (ctx is unexplained), or any failure conditions. The parameter list gives a hint of behavior but no actual behavioral transparency beyond stating the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a single sentence plus a compact parameter listing. There is no wasted wording, though it is terse to the point of omitting necessary context. Still, it earns a high mark for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It fails to explain what a child take is, what 'ctx' means, whether parameters are inherited, what the tool returns, or any side effects. A complete description would need to address these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It explains that 'name' is the take name and that include_parms/parent_take are optional, but it leaves 'ctx' completely unexplained and does not clarify the meaning or effect of include_parms. This is partial compensation at best.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '创建 child take' (create child take), which specifies a concrete action and resource. Among sibling tools like list_takes, get_current_take, and set_current_take, this is the only create operation, so it is reasonably distinguishable, 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 Guidelines2/5Does 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 mentions the creation action and parameters, without any context about prerequisites, situations where a child take is appropriate, or why one might choose this over listing or switching takes.
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 state that the tool is MUTATING, operates in a single undo group, and that the response passes through apply_response_cap. However, it does not mention required permissions, side effects, or what happens if the parameter is not found or already in the desired 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with three short sentences each adding distinct information. There is no redundant wording. It could be slightly more structured, but it is appropriately concise for the content it covers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four required parameters, no output schema, and no annotations, the description is incomplete. It does not explain the meaning of ctx, path, or parameter, nor does it describe the return value or error behavior. The tool is more complex than the description acknowledges.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for its four parameters (0% coverage). The description only clarifies that 'locked' accepts a boolean, but it leaves ctx, path, and parameter unexplained. This is minimal compensation for the low schema coverage and does not enable an agent to correctly fill all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to toggle the lock state of a parameter ('切换 parm 锁定状态'). It uses a specific verb ('toggle') and a specific resource ('parm lock state'). However, it does not explicitly distinguish this from sibling tools beyond the unique action, 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/5Does 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, exclusions, or alternative tools that might be more appropriate. The only context is the tool's own description, so an agent gets no usage direction beyond the obvious.
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 does not mention side effects, return values, error behavior, or any constraints beyond reiterating required/optional parameters (which are already in the schema). The description adds no behavioral context beyond the basic action of creating a node.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: a single sentence plus a parameter list. It front-loads the primary action and contains no redundant wording. However, it is so sparse that it sacrifices clarity for brevity, though the conciseness itself is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description is incomplete. It does not specify what the tool returns, what constitutes a valid CHOP node_type, or how parent_path should be formatted. An agent would struggle to invoke the 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/5Does 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 only mentions that parent_path and node_type are required and node_name is optional, which duplicates the schema structure without adding semantic detail. It completely omits any explanation of ctx, valid node_type values, or parent_path format, failing to guide correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'CHOP parent 下创建节点' (create a node under CHOP parent), which clearly specifies the action (create node) and the resource context (CHOP parent). This distinguishes it from sibling creation tools like create_cop_node and create_lop_node by focusing on the CHOP network.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the type-specific create_cop_node/create_lop_node. The description does not mention exclusion criteria or alternative tools, leaving the agent to infer appropriate 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral burden. It usefully discloses that nonexistent parameter names are silently skipped and that parent_path falls back to '/mat' if missing. However, it does not mention potential side effects (e.g., what happens if a node with the same name exists), failure modes, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a clear purpose statement followed by a bulleted parameter list and return information. It is concise and each section serves a purpose, though the parameter block could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It covers most parameters but misses the required ctx, includes a type contradiction for parameters, and lacks usage context relative to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It explains material_type, name, parent_path, and parameters, but completely omits the required 'ctx' parameter, leaving the agent unable to determine what it should be. Additionally, it describes 'parameters' as a dict while the schema declares it as a string, creating confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: '在 Houdini 中创建一个材质节点并返回节点信息' (create a material node in Houdini and return node information). This is specific about the verb and resource, but it does not explicitly differentiate from sibling tools like create_node or create_material_network, only relying on the term 'material node'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_node, create_material_network, or assign_material. It includes parameter instructions but no context about the intended scenario or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description adds valuable behavioral context: NO_UNDO (irreversible viewport change), only adjusts view (not a capture), and response passes through `apply_response_cap`. These traits go beyond what the schema or annotations would convey, though the exact meaning of `apply_response_cap` remains vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, front-loaded with the core method name and the key 'only adjusts view' statement. No filler, but the Chinese-English mix and technical jargon may reduce clarity for non-Houdini users.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 unexplained parameter, the description is incomplete. It highlights no-undo and non-screenshot behavior but omits the meaning of `ctx` and does not cover expected usage scenarios, which is a significant gap 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter `ctx` has zero schema coverage and the description does not explain what it is or how to construct it. With 0% coverage, the description needed to compensate but fails entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description names the underlying method (`viewport.frameSelected()`) and explicitly states it 'only adjusts the view' and does not screenshot, making the core purpose reasonably clear for users familiar with Houdini. It distinguishes from screenshot tools like `capture_pane_screenshot`, though it could more explicitly say it frames 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a negative usage hint ('not screenshot') but no explicit guidance on when to use this tool vs alternatives like `frame_all` or `set_viewport_camera`. No when-to-use/when-not-to-use scenarios are described.
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 response structure, server-side response cap (apply_response_cap), and NO_UNDO behavior, which are useful. However, it does not explicitly confirm the operation is read-only, nor does it explain potential pitfalls such as scene requirements or behavior on invalid attributes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, using bullets for clarity. However, the parenthetical 'add-geometry-export-and-measure' appears to be an internal branch or feature tag that adds noise without value to an AI agent selecting the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 6-parameter schema and no output schema, the description is incomplete. It omits parameter meanings, usage scenarios, and error behavior. The return structure and response cap are disclosed, but an agent cannot confidently invoke this tool for a specific use case without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 clarifies attrib_class accepted values and introduces owner/storage/tuple-size as dispatch concepts, but it does not explain the core parameters (ctx, node_path, attribute) or clarify the relationship between limit/offset and pagination. The return structure is stated, but parameter semantics remain largely underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool reads attributes with a specific dispatch mechanism (by owner/storage/tuple-size) and mentions native pagination, which goes beyond merely restating the tool name. However, it lacks a plain-language summary like 'get attribute values from a node' and does not explicitly distinguish itself from closely related siblings such as get_geometry_data 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/5Does 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 get_geometry_data or get_parameter. The mention of native pagination implies use for large datasets, but this is not stated as a condition, and there are no exclusions or alternative tool references.
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. It implies read-only behavior via '读取' and 'bounded' but does not clarify what 'bounded' means practically (e.g., limits on data size or range). It also omits side effects, required permissions, or return format. This is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that conveys the essential purpose and the key parameter constraint. Every word 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters, no output schema, and no annotations, this description is far too sparse. It addresses only one aspect (parameter selection constraint) and ignores other important parameters like ctx, channels, and output_index, as well as return behavior. A more complete description is needed for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 for the core selection parameters (node_path, sample/frame/time/start/end 'choose one'), which is helpful. However, it leaves ctx, channels, and output_index completely unexplained, so it only partially compensates for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads CHOP samples ('有界读取 CHOP 采样'), specifying the verb (read) and resource (CHOP samples). It also hints at bounded access, which distinguishes it from broader CHOP tools like export_chop_to_parm or list_chop_channels. However, it doesn't explicitly differentiate from all sibling 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a parameter selection rule ('node_path，sample/frame/time/start/end 选一') but provides no context on when to use this tool versus alternatives like export_chop_to_parm or list_chop_channels. No exclusions or prerequisites are mentioned.
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 and provides useful behavioral details: it declares READ_ONLY, specifies that empty expressions return 'expression: None', and notes the response passes through 'apply_response_cap'. These go beyond the schema and help an agent understand safety and edge cases, though 'apply_response_cap' is not explained further.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the main action stated first. Each sentence adds information, but terms like 'add-node-parameter-vex-tools' are cryptic and could be omitted or explained to improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 descriptions, the description is incomplete. It fails to explain key parameters or usage context, leaving an agent without enough information to correctly construct a request. The tool's simplicity does not excuse the lack of parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 does not compensate by explaining ctx, path, or parameter. The names are ambiguous (especially ctx), and there is no hint of what each parameter represents or how they should be structured, making it impossible to invoke correctly with confidence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a parm expression ('读取 parm 表达式') and explicitly notes READ_ONLY. This differentiates it from write tools like set_expression. However, it does not explicitly name alternatives or contrast with get_parameter, so it misses some 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/5Does 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 that it retrieves the expression rather than the evaluated value, nor does it explain when a user should prefer this over get_parameter or set_expression. The usage context is entirely implied by the name.
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 transparency burden. It discloses specific behaviors: utf8 is strictly detected, binary is fixed true, and responses pass through apply_response_cap. However, apply_response_cap is unexplained jargon, and there is no mention of error cases, permissions, or side effects, though the READ_ONLY label is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. However, terms like add-hda-management-tools and apply_response_cap are not explained, which slightly reduces clarity. Overall it is compact and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only metadata tool, the description covers the output structure and some behavioral quirks, but the parameter is completely unexplained and the output field semantics are only partially described. Given the lack of annotations and output schema, the description falls short of being fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter node_type is required but has zero schema description and is never mentioned in the tool description. The agent has no information about valid values, default behavior, or how it affects the section enumeration, making the parameter effectively opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enumerates HDA section metadata and lists the returned fields (name, size, protected, binary, utf8). It implicitly distinguishes from the sibling get_hda_section_content by focusing on metadata rather than content, 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/5Does 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 gives no context on prerequisites, exclusions, or how node_type affects the operation, leaving the agent to infer usage from the name and generic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool has NO_UNDO (suggesting it is not an undoable operation), uses Usd.PrimCompositionQuery when available, and applies a server-side response cap (apply_response_cap). These details add meaningful context beyond the schema and name, helping the agent understand limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the purpose. It avoids verbosity and includes key behavioral notes (NO_UNDO, response cap) in a compact form. However, the Chinese phrasing may be less universally clear, and the mixing of technical terms and shorthand slightly reduces structural clarity. Still, it earns high marks for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, no output schema, and no annotations, the description is insufficient. It explains the underlying API and response handling but does not cover parameter meanings, return format, or usage scenarios. Given the complexity of USD composition arcs, a more complete description is necessary for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 of the four parameters (ctx, node_path, prim_path, max_arcs). There is no hint about what these parameters mean or how they relate to composition arc retrieval, leaving the agent without essential guidance for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'composition arc 摘要' (composition arc summary), which clearly indicates this tool retrieves a summary of composition arcs for a USD prim. The verb is implied by the tool name 'get' and the resource is explicit. It distinguishes from sibling get_usd_* tools by focusing specifically on composition arcs rather than attributes or 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/5Does 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 mention a fallback behavior ('if available; otherwise returns unsupported') but does not explain typical use cases, prerequisites, or why one might choose this over related USD inspection 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. It does disclose 'NO_UNDO' and that responses pass through 'apply_response_cap', which are useful behavioral traits. However, it does not mention permissions, side effects, or whether the stage must be cooked, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the key output fields, making it easy to scan. However, the mixed-language shorthand and technical jargon (e.g., 'apply_response_cap') reduce clarity, and the second sentence adds operational detail without full context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description only enumerates output categories without detailing the response structure. It also omits any explanation of required parameters or preconditions, leaving the tool under-specified for an agent to confidently invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the roles of ctx, node_path, or prim_path. While prim_path is inferable from the tool's purpose, ctx and node_path are undefined and the description adds no parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly lists what is reported: active/loaded/defined/abstract/instance status and attribute count, which clearly identifies the tool's purpose. It distinguishes itself from sibling tools like get_prim_intrinsics or get_usd_attribute by focusing on prim state statistics, though it lacks a formal verb phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_prim_intrinsics, get_geo_summary, or lop_prim_get. The mention of 'add-usd-solaris-tools' gives provenance but not 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 are available, leaving the description responsible for behavioral disclosure. It does not mention side effects (e.g., permanent position changes), whether the graph is cooked, or the exact scope of 'children'. The simple action verb is there 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the core purpose efficiently and remains easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 provides a minimum viable definition. However, it lacks usage context, alternatives, and behavioral details, making it incomplete for an agent to confidently invoke it in varied situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter ('path') with 0% coverage, so the description must clarify its meaning. It does imply the path refers to the network node, but it does not specify the path format, whether it supports wildcards, or any constraints. This is minimal compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Auto-layout'), the target ('all children of a network node'), and the outcome ('for a tidy graph'). It distinguishes from the sibling 'layout_children' by specifying 'network node' as the context, though it doesn't explicitly contrast 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/5Does 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, prerequisites, or alternatives like 'layout_children'. The description only states what it does without any contextual or exclusionary information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals key behaviors: it does not depend on the UsdLux.Light base class, returns a capability warning when the API is missing, passes the response through server-side apply_response_cap, and notes NO_UNDO. These details go beyond a basic description and alert the agent to potential limitations or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the tool's core purpose of light recognition. It packs a lot of technical detail into two sentences, and each sentence adds value. However, the heavy use of USD-specific jargon (UsdLux.LightAPI, schema IsA) may reduce clarity for agents not deeply familiar with USD, but it is still concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with three parameters and no output schema. It omits parameter explanations, return value format, and any usage examples. The mention of apply_response_cap and NO_UNDO hints at behavior but does not clarify the expected output or how to interpret results, making it insufficient for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for its three parameters (ctx, node_path, max_lights), and the description does not explain any of them. The tool description focuses entirely on detection logic and response handling, leaving parameter meanings to be inferred from the tool name and context. This is a critical gap for a tool that requires two mandatory parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose as light recognition (灯光识别) and details the identification strategy (UsdLux.LightAPI then schema IsA). This distinguishes it from sibling tools like list_usd_prims by focusing specifically on lights. However, it does not explicitly say that it returns a list of lights, which is the implied outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only describes the internal algorithm and does not mention any use cases, prerequisites, or exclusions. There is no reference to sibling tools or conditions for preferring list_lights over other listing 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?
The description self-labels as MUTATING and mentions pre-checking the target category and apply_response_cap, but with no annotations provided, it fails to disclose important behaviors like side effects on connections, error conditions, or reversibility. The description carries the full burden but provides only minimal insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two short sentences. It front-loads the core action. The inclusion of 'add-node-parameter-vex-tools' is somewhat cryptic but doesn't detract significantly from readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and no parameter descriptions, the description is the only source of context. It fails to mention return values, error handling, or the purpose of ctx. The operation's simplicity aside, too much essential context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 dest_parent as the target parent and implies src_path is the node to move, but ctx is not mentioned at all. No formats or examples are given, leaving substantial gaps for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves a node to a dest_parent, which is a specific verb+resource. This distinguishes it from sibling tools like copy_node or delete_node. The purpose is 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/5Does 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 copy_node or connect_nodes. The description mentions the underlying Houdini function but gives no context about scenarios or prerequisites, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: it is a scene write operation and is undoable. It also states validation matches set_frame_range, giving the agent a concrete behavioral contract, though it omits error handling and exact side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise and front-loaded, but the cryptic 'PR 19' abbreviation and cross-reference to set_frame_range require prior knowledge. Still, no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no annotations, no output schema, and 0% schema coverage, the description leaves critical invocation details unspecified—especially parameter semantics and differentiation from set_frame_range. The undo and validation notes provide some context but are insufficient for confident autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the meaning or expected format of ctx, start, or end. It only implies a range via the tool name, leaving parameter usage entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action—setting the playback range—and references the underlying Houdini API (hou.playbar.setPlaybackRange). It is clear, but it does not explicitly distinguish itself from the closely related sibling tool set_frame_range, merely noting shared validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to choose set_playback_range over set_frame_range or other playbar tools. The only reference to set_frame_range is for shared validation, not usage context 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 carries full burden. It discloses that it relays to server-side disc.find_nodes, but does not mention return format, pagination behavior, traversal depth, or whether it is read-only. The verb 'Find' implies reading, but no explicit safety or behavioral details are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise and informative. The second sentence 'PR 6: relays to server-side disc.find_nodes.' is an implementation note that does not help an agent select or invoke the tool and could be omitted. The description is somewhat padded with non-actionable info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does not state what the tool returns (e.g., node paths, types, counts) or how pagination works via limit/cursor. For a 5-param tool with no output schema, more context is needed to invoke it correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains pattern and node_type matching, and root_path as the search root. However, limit and cursor are not explained, leaving pagination semantics unclear. The description partially compensates for the schema gap but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and the resource 'nodes under root_path' with specific matching criteria (glob/substring pattern or node_type). It also distinguishes from siblings like list_children by emphasizing recursive search under a path, and the default root_path adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_children or find_error_nodes. The description only mentions the default root_path, which is more parameter information than usage context. No exclusions or alternative scenarios are given.
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 discloses that the return is a JSON string, but it does not state what the JSON contains, whether it is a snapshot or live data, or if there are any performance implications. Minimal behavioral context beyond the return type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, with no filler or redundant information. It clearly communicates the action and return format in an efficient manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return format details are likely structured. However, the meaning of 'scene info' remains ambiguous, and the description does not clarify the scope of data returned. For a zero-param tool, this is adequate but incomplete for an agent deciding between this and similar scene-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema trivially covers 100% of the (empty) parameter space. Per the baseline for 0-param tools, the description does not need to add parameter semantics, and any addition would be redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it 'Ask(s) Houdini for scene info' and returns JSON, giving a verb and resource. However, 'scene info' is vague and does not distinguish it from siblings like get_scene_summary or get_network_overview, which likely cover similar ground.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description implies it is for getting general scene information but does not mention when it should be preferred over specific scene-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 behavioral disclosure. It states the action 'delete' but does not reveal consequences (e.g., irreversibility, effect on connected nodes, or error conditions). This is insufficient 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the core action efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter), a short description can be adequate, but this one lacks any behavioral or usage context. No return value is mentioned, and there are no notes about failure modes, making it incomplete for a destructive operation without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 phrase 'by path' only reiterates the parameter name 'path' without adding detail about format, absolute vs. relative paths, or any constraints. This adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a node'), the target resource ('a node'), and the method ('by path'). It is concise and distinguishes this tool from siblings like move_node, rename_node, and copy_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites, or alternatives. It does not mention potential implications such as node connectivity or whether deletion is allowed on locked nodes.
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?
Since no annotations are provided, the description carries the full burden for behavioral disclosure. It states the tool is READ_ONLY and discloses a key limitation: volume/VDB fields do not return raw voxels but only cheaply obtainable resolution/bbox/min/max/average, with unavailable values marked as 'unavailable'. This adds meaningful context that an agent would need. However, it does not describe behavior for other field types, error handling, or the exact return structure, so it is not fully 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences—and front-loads the purpose. Every sentence adds information: the first identifies the action and scope, the second provides a specific behavioral caveat. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 7 parameters (5 required), the description is too sparse to provide complete context. It addresses the volume/VDB caveat but does not explain what other fields return, how to specify record_type or record_index, what 'ctx' means, or what the response format looks like. An agent would likely need to gather additional information to use this tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description explains none of the seven parameters (ctx, dop_path, object_name, data_name, field_name, record_type, record_index). It mentions 'field' generically but does not clarify the difference between data_name and field_name, or the role of record_type and record_index. The description fails to compensate for the lack of schema-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads DOP data/record fields, using the verb '读取' (read) with a specific resource. It also notes this is part of add-dops-tools and READ_ONLY, which helps distinguish it from mutation tools. However, it does not explicitly differentiate from sibling tools like get_dop_object or list_dop_objects, which could also involve reading DOP 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/5Does 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 scenarios where get_dop_field is preferred over get_dop_object, get_dop_relationships, or other DOP-related tools. The only implicit context is that it is READ_ONLY and targeted at field-level access, which is not enough for an agent to make a selection decision.
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 the READ_ONLY nature, the hard max_objects limit, and that responses pass through apply_response_cap, which adds useful behavioral context. However, it does not explain pagination mechanics, error behavior, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and resource, and every phrase adds information. There is no redundant text or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the basic purpose, read-only safety, and a key constraint (max_objects). However, it omits parameter semantics and any description of the return structure or pagination behavior. It is minimally complete for a niche tool but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only clarifies the max_objects parameter (hard limit) and the response cap, leaving ctx, dop_path, limit, and offset semantically unexplained. This is minimal compensation for a 5-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '分页读取 DOP relationships' (paged read DOP relationships) with a specific verb and resource, and also notes it is READ_ONLY. It does not explicitly differentiate from sibling tools like list_dop_objects or get_dop_object, 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/5Does 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 only implies a read operation with pagination, but does not state exclusions, prerequisites, or when to prefer other relationship-related 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 burden. It discloses that the operation is read-only ('读取') and mentions NO_UNDO and the server-side response cap. It does not detail error behavior or permission requirements, but for a read tool, the key safety aspect is covered. No contradictions with annotations (none exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences that front-load the core purpose. It avoids fluff, though terms like 'add-usd-solaris-tools' and 'apply_response_cap' are cryptic. Overall, it is efficiently sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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. The description gives a brief return format ('attribute value + type name') but fails to explain the parameters or usage context beyond the composed stage/time. This is inadequate for a tool with such low structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for parameter explanations. It mentions 'time' and 'attribute' but does not describe 'ctx', 'node_path', or 'prim_path'. The phrase 'from composed stage' hints at prim_path but insufficiently, leaving several parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a single attribute value and its type name from a composed stage at a given time. It is specific about the verb ('读取') and resource ('attribute'), and the phrase '单个' implies single-attribute scope, distinguishing it from plural-attribute tools. However, it does not explicitly name alternatives like get_attrib_values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool: reading an attribute from the composed stage at a specific time. It does not explicitly state exclusions or mention alternative tools, but the 'single attribute' scope and 'composed stage' context give implied usage 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, the description carries the full burden of behavioral disclosure. It provides useful operational details: single undo group, failure throws an error, and the response passes through 'apply_response_cap'. These are meaningful beyond a basic mutating operation, though it doesn't mention permissions or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, front-loaded with the core purpose, and every sentence adds new information (mutating flag, undo behavior, error handling, response cap). However, the cryptic term 'apply_response_cap' could be clarified, slightly reducing structure quality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 required parameters, no output schema, and no annotations, the description is too sparse. It fails to explain parameter usage, expected return values, or context needed for correct invocation. The undocumented parameters leave significant gaps for an agent trying to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description provides almost no parameter-level semantics. The names ctx, path, parameter, and value are somewhat self-explanatory, but the description does not explain their meaning, format, or how they interact. It 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'write parm value' (写 parm 值), identifying the specific action (write) and resource (a parameter). It is distinguished from the sibling 'set_parameters' by its singular focus, though this is implicit rather than explicit. The addition of 'MUTATING' reinforces its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'set_parameters' or other mutation tools. The description gives no context on prerequisites, typical scenarios, or exclusions. Usage is only implied by the generic 'write parameter value' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the mutating nature (MUTATING), the failure behavior (returns unsupported when mapping is lossy), the prohibition against fallback, accepted attribute_type values, and server-side apply_response_cap. This is substantial behavioral disclosure, though it omits prerequisites and reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and every sentence conveys a constraint or type list. It is appropriately sized for the amount of information, though the lack of paragraph breaks makes it somewhat dense. No unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It does not explain parameter meanings, value formats, return values, or usage conditions, leaving significant gaps for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds little. It only clarifies attribute_type accepted values. Other parameters (ctx, parent_path, prim_path, attribute, value, node_name) are unexplained, leaving the agent without essential semantics for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses the verb 'create' and identifies the resource as a whitelist attribute authoring LOP, which differentiates it from generic get/set USD tools. However, the technical jargon (authoring LOP) may be unclear to those not familiar with USD workflows, so it is 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It mentions internal constraints (no fallback, unsupported mapping) but gives no guidance on appropriate scenarios or exclusions, so it fails to help the agent choose this tool over siblings.
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 responsibility for disclosing side effects. It explicitly states that disk side effects cannot be undone and that the operation writes to disk for real. It falls short of covering authorization, overwrite behavior, or failure modes, but communicates the most critical risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences: the first states the action and result, the second states the critical side-effect caveat. There is no filler, redundancy, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 is too sparse. It leaves parameter semantics entirely unexplained, gives no return value details beyond 'returns result', and lacks usage context. The irreversible side-effect disclosure is valuable, but the tool cannot be invoked correctly without more parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are completely absent (0% coverage), and the description does not explain 'ctx' or 'node_path' at all. The parameter names provide only weak hints; an agent receives no information about accepted formats, defaults, or how the parameters relate to the cache operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('真实落盘' = actually write to disk) and resource ('cache'), and mentions that it returns results. This distinguishes it from read-only or management cache tools, though the exact cache type or scope is not detailed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 manage_cache or clear_cache. There is no mention of prerequisites, such as how ctx or node_path should be prepared, or when a different cache-related 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.
- 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 and does disclose that the tool is read-only and does not modify the scene, and that responses pass through a server-side cap. It also describes conditional field inclusion behavior. However, it omits error handling, permissions, or what happens with invalid paths, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and uses structured backtick formatting to list fields, making it scannable. The odd 'add-scene-context-selection-materials' phrase is not explained and could distract, but overall the description is efficient and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description enumerates the return fields and conditional additions, which gives a clear picture of the response structure. It also covers the response cap and read-only nature. The missing context is the meaning of the embedded tag and the expected behavior for edge cases, but for a summary tool this is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains include_params and max_params semantics, clarifying their conditional role. However, the two required parameters, ctx and node_path, are not described, relying on their self-explanatory names; this leaves a meaningful gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a 'single-node structured summary' and lists the exact fields returned, which distinguishes it from scene-level or geometry-specific tools. However, it does not explicitly contrast with sibling tools like get_node_info or get_geo_summary, so it's clear but 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/5Does 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. The description implies it's for explaining a single node, but there are no explicit context signals, prerequisites, or exclusions, leaving usage decisions to inference.
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 adds useful context by disclosing the internal API call `DopSimulation.memoryUsage()`, stating that the return value is explicitly marked in bytes, and noting the response passes through `apply_response_cap`. This goes beyond the bare purpose, though it doesn't cover error cases or detailed return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is remarkably concise, with two sentences that effectively cover the purpose and key behavioral details. Every clause earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool, the description covers the return type and response cap, but it lacks parameter semantics and usage context. The absence of an output schema and annotations makes the description the only source of information, yet it leaves gaps in understanding what the required inputs represent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not compensate. It never explains what `ctx` and `dop_path` mean, so the agent is left guessing. The parameter names are somewhat self-explanatory, but the description adds zero value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '读取 DOP simulation 内存' (read DOP simulation memory), specifying a verb and resource. It identifies the tool as part of add-dops-tools and READ_ONLY, but does not explicitly differentiate it from sibling tools like get_simulation_info, so it doesn't reach 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/5Does 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 is purely functional and does not mention scenarios, exclusions, or related tools, leaving the agent without context for choosing 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?
With no annotations, the description carries the transparency burden. It mentions 'NO_UNDO' and 'apply_response_cap', which are useful behavioral hints, and indicates it is read-only ('读取'). However, it doesn't disclose error behavior, output format, or side effects beyond these points, so it's partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant filler. The parenthetical 'add-usd-solaris-tools，NO_UNDO' is a bit cryptic but acceptable. It front-loads the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema, the description is somewhat brief. It doesn't explain what the returned data looks like or when the tool is appropriate. However, it covers key aspects like scope (root/session/sublayer) and limits (max_layers), making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains that 'max_layers' limits the number of layers, but 'ctx' and 'node_path' remain undefined. This adds some meaning for one parameter but not the others.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads root/session/sublayer layer stack information (identifier, real path, sublayer count) and is a summary. This distinguishes it from prim-focused or stage-level tools like lop_prim_search or lop_stage_info, though it doesn't explicitly name 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/5Does 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. It only describes what the tool does, implying it's for inspecting layer stacks, but there are no explicit conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses important safety and side-effect traits: default does not delete disk output, changes scheduler state, and is irreversible. This exceeds minimal expectations, though it could elaborate on exact scheduler consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded with the core purpose. Every word carries weight, but the mixed-language brevity slightly reduces structure clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's complexity (PDG scheduler state mutation), the description omits what 'dirty' does exactly, parameter meanings, and any return/result information. With no annotations or output schema, the description leaves major gaps in operational understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for two parameters, and the description provides no explanation of ctx or node_path. The description entirely fails to compensate for the lack of parameter documentation, leaving the agent unable to infer parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('dirty work items') and distinct resource, distinguishing it from siblings like pdg_cook and pdg_cancel. It conveys a clear PDG operation, though 'dirty' as a verb may be jargon for non-experts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (marking work items dirty) and adds cautionary notes (doesn't delete disk output by default, cannot undo). However, it does not explicitly state when to use this tool versus alternatives or provide context-specific 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, the description provides key behavioral details: NO_UNDO, error conditions (node_not_found, viewport_unavailable), and server-side response capping. This is helpful, though it does not explain success behavior or side effects beyond navigation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the core API call. It efficiently lists error cases. The parenthetical phrase is a minor distraction but does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool, the description covers the main operation and error cases, but misses the success return value and fails to define 'ctx'. It is adequate but leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It implies 'path' is a node path via the node_not_found error, but 'ctx' is completely unexplained. No details on formats or allowed values are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as NetworkEditor.cd(path), which sets the current network context. It provides specific error conditions that clarify the tool's behavior. However, the reference to 'add-viewport-control-tools' is cryptic and does not explicitly differentiate it from sibling 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/5Does 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. It does not state typical use cases, preconditions, or contrast with other navigation tools. The error conditions are behavioral, 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?
No annotations are provided, so the description must fully disclose behavioral traits. It does add a meaningful detail: omitting 'types' subscribes to all supported events. However, it lacks other important behavioral context such as whether subscriptions are additive or replace existing ones, whether there are side effects, or why 'ctx' is required. This is insufficient for a subscription tool with no 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose. It is efficient with no wasted words. However, it is so brief that it borders on under-specification, but that is more of a completeness issue than a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a subscription tool with two parameters and no output schema, but the description is minimal. It does not explain the event system, how subscriptions are managed, or how this relates to sibling tools like 'unsubscribe_houdini_events' and 'get_houdini_events'. The description is inadequate for an agent to fully understand the tool's role and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate. It explains the behavior of 'types' (when omitted, all events are subscribed), which adds meaning beyond the schema. However, it does not explain the required 'ctx' parameter at all, nor does it specify the format or accepted values for 'types'. The description only partially covers the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: subscribing to event types. It uses a specific verb ('subscribe') and resource ('houdini_events'), and the added detail about omitting types to subscribe to all events further clarifies scope. It distinguishes itself from siblings like 'unsubscribe_houdini_events' and 'get_houdini_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the action and the optional 'types' parameter, but it does not explicitly mention when to use this tool versus alternatives. There is no reference to 'unsubscribe_houdini_events' for stopping subscriptions or 'get_houdini_events' for listing events, so the guidance is 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?
Given no annotations, the description carries the burden of disclosing behavior. It does describe the return dict fields, the presence of _ai_hint, a fallback for unreachable SideFX, and timeout defaults. However, it does not mention potential side effects, error behavior, or what 'apply_response_cap' means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points for parameters, examples, and return format. It is appropriately sized, with no unnecessary fluff, and front-loads the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description explains return fields and the AI hint, which partially compensates. However, it lacks usage context compared to get_houdini_help, omits the ctx parameter, and does not cover error scenarios, making it moderately complete for a wrapper tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions, but the description covers item_name, help_type, and timeout with useful details including examples and default values. The critical omission is that required parameter ctx is not mentioned at all, leaving a significant gap for agent understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is an 'AI-friendly wrapper over get_houdini_help' and clearly indicates it queries hou API/node/VEX function names. It provides a specific verb+resource, but since it's a wrapper, it doesn't explicitly distinguish itself from get_houdini_help.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like get_houdini_help. It only mentions being a wrapper, implying some use cases but without clear context, exclusions, or alternative recommendations.
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 NO_UNDO (irreversible), that it only adjusts the view (no screenshot side effects), and that responses go through server-side cap. These are useful behavioral traits beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with key info front-loaded: the function call, NO_UNDO, view-only scope, and server cap. It's concise, though the technical snippet 'apply_response_cap' could be clearer to a general agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple viewport operation, the description covers purpose, undo behavior, and non-screenshot scope. However, it omits any explanation of the ctx parameter and doesn't describe return values or potential side effects beyond NO_UNDO. Given one parameter and no output schema, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'ctx' with 0% description coverage, and the description doesn't explain ctx at all. Since schema coverage is zero and no parameter info is given, the description fails to compensate, leaving the parameter meaning completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adjusts the view via viewport.frameAll() and explicitly notes it does **not** take a screenshot, which distinguishes it from capture tools. However, it doesn't explicitly say 'frame all objects' in plain language or contrast with frame_selection, so it's clear but not perfectly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives the context that this tool only adjusts the view and doesn't screenshot, implying when it should be used. But it doesn't mention alternatives like frame_selection for framing specific objects, so guidance on when to use vs alternatives is 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?
With no annotations provided, the description must bear the full burden of behavioral disclosure. It does disclose that the tool is READ_ONLY and that the response passes through apply_response_cap, adding some transparency. However, it lacks details on error handling, required permissions, or any side effects, which is a modest but not comprehensive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of three short sentences, with the first sentence immediately stating the core purpose. It is front-loaded, contains no redundant information, and every phrase adds value, including the return structure and the response handling note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple getter, but the description is incomplete given the sparse schema and missing annotations. It does not explain the input parameters, which are critical for correct use. The return structure is mentioned, but without further context on when or how to use the tool, the description is insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 either 'ctx' or 'path' parameters. It only mentions 'path' as part of the return structure, which gives a hint about its meaning but does not clarify its input role or the meaning of 'ctx'. The description fails to compensate for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('reads the snippet') and the resource ('Attribute Wrangle SOP'), making the tool's purpose unambiguous. It also includes 'READ_ONLY' to signal it is a read operation, which helps distinguish it from sibling tools like set_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its read-only nature and return type, but it does not explicitly state when to use this tool over alternatives. There is no mention of when not to use it or any alternative tools, leaving the agent to infer from the sibling list.
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 discloses the output nature (names and sampling range) and implies a read-only operation via the verb '枚举', but it does not clarify the required ctx parameter or potential failure modes. This is acceptable for a benign listing, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with purpose, but the second sentence mostly duplicates schema information and is incomplete by missing ctx. It is concise overall but not fully earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and zero annotation support, the description provides only a high-level outcome. Key gaps include the unexplained ctx parameter, ambiguous output_index semantics, and no return structure details. For a simple enumeration tool, this is near-minimal but still has clear omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 node_path and output_index (optional), but omits the required ctx parameter entirely. It also does not explain node_path format or output_index's expected values, despite the schema showing output_index as a string with default 0.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '枚举' (enumerate) and clearly identifies the resource (CHOP channels/tracks) plus additional scope (sampling range). This distinguishes it from siblings like get_chop_data or export_chop_to_parm.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_chop_data or create_chop_node. There is no mention of appropriate contexts, prerequisites, or exclusions.
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 pagination and a caching mechanism (NodeTypeCache population and reuse), which add behavioral context beyond the schema. However, the return format and side effects are not detailed, and the 'PR 6' note is cryptic. Since no annotations exist, the description carries the full burden but remains incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise and clear. The second sentence introduces internal implementation details ('PR 6', 'disc.list_node_types') that are likely confusing for an agent and add noise. The description could be tighter and more user-focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no annotations and no output schema, the description covers the core purpose but omits details like response structure, pagination cursor behavior, and explicit read-only nature. It is adequate but leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description maps 'category / name filter' to the 'category' and 'name_filter' parameters and mentions pagination, which implicitly covers 'limit' and 'cursor'. This adds some meaning, but it does not explain cursor mechanics or filter matching semantics. With 0% schema description coverage, the description partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'List Houdini node types' with optional filters and pagination. It distinguishes from sibling tools like 'list_cop_node_types' by referring generically to 'Houdini 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description implies usage for listing node types but does not mention exclusions or when a more specific tool like 'list_cop_node_types' should be preferred.
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 NO_UNDO (non-undoable) and mentions the response cap (apply_response_cap), which are useful behavioral traits. However, it does not explicitly state side-effect status (read-only vs mutating) or any prerequisites, leaving some 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The parenthetical notes about NO_UNDO and response cap add useful context without excessive length, though the structure could be slightly cleaner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main functionality and return contents, but given no annotations, no output schema, and 0% parameter coverage, it lacks details on required inputs (ctx, node_path) and when to use it. It is adequate for a simple list tool but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only explains max_depth and max_prims conceptually as limits. It does not clarify ctx or node_path, which are required parameters. The partial insight into two parameters is insufficient for full understanding of all four.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs prim traversal limited by max_depth and max_prims, and lists what it returns (paths, names, types, depths). This distinguishes it from sibling tools like get_prim_intrinsics or lop_prim_search, which have different focuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. It only implies its purpose through the traversal limits, but there is no explicit mention of when to prefer list_usd_prims over sibling tools like get_prim_intrinsics or lop_prim_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses disk and registry side effects and explicitly warns that the operation cannot be undone via Houdini's undo system. This is meaningful behavioral context, especially with no annotations provided. It could add preconditions or error behavior, but the core safety warning is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and contains zero filler. The NO_UNDO repetition is acceptable and reinforces the warning without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and side effects, but it lacks parameter clarification and usage timing. For a single-parameter tool with no output schema, the agent is left guessing what file_path should be. The description is adequate for a basic understanding but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description entirely ignores file_path. There is no indication whether the parameter expects a .hda file path, a directory, or a library name. The description adds no meaning beyond the schema's bare 'File Path' title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource: '重载 HDA 库' (reload HDA library). It distinguishes the action from siblings by the explicit 'reload' and mentions the underlying tool name, though it does not directly contrast with update_hda or hda_install.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative exclusions are provided. The NO_UNDO warning implies caution but does not state 'use this after editing HDA files on disk' or avoid during active sessions. There is no mention of sibling tools or 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?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose one behavior: rejecting when the take is not found or ambiguous. However, it does not mention that this changes the current take (mutation), potential side effects, or any prerequisites. Minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct: one sentence states the purpose and includes parameter details. It is front-loaded with the action and wastes no words. The parameter explanation is integrated efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool, the description covers the core action and one parameter, but it omits context about the role of ctx and the concept of 'current take'. No output schema or annotations exist, so more context would be beneficial. Adequate but incomplete in covering prerequisites or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains name_or_path as 'take 名或路径' (take name or path), adding meaning not present in the schema. However, the ctx parameter is entirely undocumented. Since schema coverage is 0%, the description must compensate but only covers half the parameters, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '切换当前 take' clearly states the action (switch) and the resource (current take). The verb is specific and unambiguous, and the name alone distinguishes it from siblings like get_current_take and create_take. It fully captures 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/5Does 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 related tools like get_current_take or create_take, nor does it specify use cases. The only extra information is about error handling ('找不到/歧义时拒绝'), which is 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the action 'force-cook' and the outputs, but it does not disclose potential side effects (e.g., scene modification, performance impact), prerequisites, or any restrictions. The behavioral information 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the core action and quickly add the verification framing. Every word earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but completeness is weak overall. The description covers the return aspects (cleanliness, errors, warnings, cook time) and notes the primary purpose, but it omits parameter guidance and any behavioral caveats. Given no annotations and no output schema, this leaves meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single required 'path' parameter with zero description coverage. The description never mentions the 'path' parameter, nor does it explain what path should refer to, expected format, or any examples. It adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'force-cook' and clearly identifies the resource 'node'. It states exactly what it does: cook a node and report on whether it cooked cleanly, with errors, warnings, and cook time. It also differentiates itself from siblings by claiming to be 'the definitive way to verify a node works.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: 'The definitive way to verify a node works.' It implies the appropriate scenario but does not explicitly name alternative tools or state when not to use it, 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the transparency burden. It discloses that it uses geo.intrinsicValue('bounds'), has NO_UNDO, and that the response passes through apply_response_cap. These are meaningful behavioral traits, though it does not explicitly state read-only safety or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the primary action. However, it includes a changelist reference 'add-geometry-export-and-measure' that adds noise and is not useful for tool invocation, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and incomplete parameter documentation. While the description explains the output structure, it omits crucial context about what to pass for ctx and node_path, making it incomplete for standalone use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the parameters 'ctx' and 'node_path'. The parameter meanings are left entirely ambiguous, so 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it unpacks a geometry 6-tuple bounds into a structured object {min,max,size,center} and mentions the specific intrinsicValue('bounds') layout. This is a specific verb+resource that distinguishes it from other geometry tools like get_geometry_data 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool or mention alternatives. It is only implied from the tool name and description that it is for retrieving bounding boxes, so usage context is inferred but not stated.
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 a read operation ('读取') and mentions 'NO_UNDO' and 'apply_response_cap', adding some context. However, it does not explicitly state side-effect-freeness, permission requirements, or error behavior, though the read-oriented wording is a strong safety signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the core function in the first line. The second paragraph adds meaningful detail about the response. Some mixed-language jargon ('add-usd-solaris-tools', 'apply_response_cap') may reduce clarity but does not waste space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no output schema, and no annotations, the description leaves gaps: parameter semantics, exact return structure, and error behavior are missing. It covers the main metadata fields but is insufficient for an agent to confidently select and invoke it without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 ctx, max_prims, or node_path beyond implying node_path is the LOP node from LopNode.stage(). The meaning of max_prims (e.g., limit on counted prims) is unstated, and ctx is entirely opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads composed stage metadata (upAxis, metersPerUnit, framesPerSecond, defaultPrim, and prim count) from LopNode.stage(). This is a specific verb+resource pairing that distinguishes it from sibling tools like lop_layer_info or get_usd_prim_stats, which focus on different layers or prim-level details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving stage-level USD metadata, but provides no explicit when-to-use vs alternatives, prerequisites, or exclusions. It is clear for the core scenario but does not guide the agent toward comparing it with other LOP-related tools like lop_layer_info or list_usd_prims.
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 burden. It discloses that the operation is MUTATING, pre-checks for same-name conflicts, and returns new path/old_name/new_name. However, it does not mention failure behavior or any side effects beyond the rename.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, with the core verb front-loaded. However, it includes some internal jargon like 'add-node-parameter-vex-tools' and 'apply_response_cap' that may be unclear to the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations, the description provides some behavioral context (conflict precheck, return values) but omits parameter semantics, prerequisites, and error handling. This makes it incomplete 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.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 3 required parameters (ctx, path, new_name) with no descriptions. The description does not explain any of these parameters, leaving their meaning to be inferred from names. With 0% schema coverage, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '重命名节点' (rename node), a specific verb+resource, and distinguishes from sibling tools like move_node by focusing on the name change. The mention of MUTATING further clarifies its intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for renaming a node, but does not explicitly state when to use it versus alternatives such as move_node or set_parameters. There are no exclusions or prerequisites 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 full burden. It discloses that the function returns a dict with 'path / position / success' and raises a ValueError if the node does not exist, which is valuable behavioral context. However, it does not mention side effects such as persistence, triggering a cook, or whether the position is absolute vs relative. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose sentence, a bulleted parameter list, and a brief note on return value and error behavior. Every sentence adds value, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter, the description covers the core behavior, return format, and error condition, which is fairly complete. However, the missing 'ctx' parameter explanation and lack of differentiation from 'move_node' are notable gaps. Given the tool's low complexity, the description is nearly complete but not fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains node_path, x, and y with meaningful semantics (e.g., 'x coordinate (Houdini units)'), but omits the required 'ctx' parameter entirely. Additionally, the schema types x and y as strings, while the description implies numeric coordinates—a potential confusion. The compensation is incomplete, warranting a score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Set node position in the network editor,' with a clear verb and resource. It lists the key parameters (node_path, x, y) that make the purpose unambiguous. However, it does not explicitly differentiate from the sibling tool 'move_node,' which may serve a similar function, so it loses one point for lack of 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/5Does 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 'move_node.' There are no mentions of prerequisites, exclusions, or contextual triggers. The usage is only implied by the tool name and basic description, which is insufficient for an agent choosing among many node manipulation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels: it discloses full pre-validation (atomicity), the specific clear approach avoiding clearAllSelected() to prevent side effects on box/note/dot, NO_UNDO behavior with batch dispatcher handling, and response capping. This is rich, actionable behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but relatively compact, covering multiple important behaviors in three sentences. It uses formatting (bold, code) effectively and every sentence adds value. Slightly heavy in technical jargon but not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description covers key aspects like atomicity, undo, and response cap, but it omits return value expectations and fails to explain the ctx parameter. For a selection tool with 3 parameters, the description is above average but still incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions), so the description must compensate. It explains node_paths (pre-validation) and clear behavior, but neither the ctx parameter nor the clear_others parameter is explicitly named or explained. The description does not fully map to the three schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'overrides node selection' with a specific scope (add-scene-context-selection-materials). This distinguishes it from get_selection and other selection-related tools, though it does not explicitly name alternatives as in the high calibration example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description focuses on internal mechanics (pre-validation, undo behavior) rather than usage context or prerequisites. There is no mention of when to prefer set_selection over get_selection or frame_selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly mentions the underlying calls ('geometry'/'geometryAtFrame'), what is returned, what is not (full geometry), and the NO_UNDO guarantee. It also explains the effect of the optional 'frame' parameter, adding valuable context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the purpose. Every sentence adds information: the first defines the scope and outputs, the second explains the 'frame' option and non-serialization. No redundant phrasing exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 annotations, so the description must provide comprehensive context. It covers purpose, key outputs, and the frame variant, but lacks details about the other three parameters and does not explain return structure. Given moderate complexity (4 params), it is adequate but leaves clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 explain the 'frame' parameter's behavior (triggers AtFrame variant), which is useful. However, it adds no meaning for 'ctx', 'node_path', or 'output_index', leaving their roles to be inferred from names alone. This is insufficient compensation for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: reading a Copernicus output geometry summary, including counts, bbox, and attribute summary. It uses a specific verb ('读取') and identifies the resource ('Copernicus output geometry'). However, it does not explicitly differentiate itself from similar sibling tools like get_geo_summary or get_geometry_data, 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for lightweight summary access ('只返回', '不序列化完整几何') and explains the selective use of the AtFrame variant based on the 'frame' parameter. It does not explicitly state when to choose this tool over alternatives or provide exclusions, so it provides only implied 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 available, the description carries the transparency burden. It discloses that the operation is read-only ('读取'), returns only bounded metadata (grid_name/storage/bounds) and not voxels, and describes the fallback behavior. This goes beyond minimal expectations, though it omits error handling and permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the main purpose in the first sentence, followed by a brief note on the fallback and return scope. Every sentence adds value, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return scope and retrieval fallback, but the absence of parameter documentation is a critical gap given the 0% schema coverage and no output schema. For a tool with four parameters, this makes it difficult for an agent to invoke it correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 for any of the four parameters (ctx, frame, node_path, output_index). The agent has no guidance on what values to pass or what each parameter means beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool reads Copernicus NanoVDB/grid metadata, using a specific verb ('读取' = read) and resource. It distinguishes itself from sibling tools like get_cop_info or get_cop_geometry by focusing on NanoVDB/grid metadata and explicitly mentioning the fallback strategy and return 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about the retrieval method (first try vdb/vdbAtFrame, then reflect from cable) and what it returns, but it does not explicitly say when to use this tool versus alternatives like get_cop_info or get_cop_layer. Usage is implied rather than directly stated.
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. It does disclose important behavior: recursive subtree traversal up to max_depth, compact output shape, and server-side relay. However, it omits pagination/cursor behavior, the meaning of non-compact output, error handling, and any read-only safety guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with actionable usage details. The first two sentences are concise and valuable. The final sentence about 'PR 6' and server-side relay is internal noise that does not help an agent invoke the tool, so it loses the top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no annotations, and no output schema, the description leaves material gaps: pagination via limit/cursor, the max_nodes safety cap, the full non-compact return format, and default behavior when node_path is invalid are all unexplained. The description covers core semantics but is not complete enough for correct advanced usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 meaning to node_path, recursive, max_depth, and compact, but completely ignores limit, cursor, and max_nodes. This is partial compensation for a 7-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'List the children of node_path.' It names a specific resource (children of a node path) and distinguishes itself from sibling list_* tools by targeting node hierarchy children rather than node types, panes, or channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool when you need the children of a given node path. However, there is no explicit mention of when to choose this over alternatives like find_nodes or get_node_info, nor are any exclusions or prerequisite conditions 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 present, so the description carries the full burden. It notes NO_UNDO and that responses pass through server-side apply_response_cap, which adds context, but it does not disclose error behavior, confirm read-only nature, or elaborate on the response capping'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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two terse sentences that commit no waste: the first states the core output, the second covers the required parameter and response handling. Every sentence earns its place, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description omits essential context for three parameters and does not position the tool among closely related query siblings. Significant gaps remain for an agent to use it correctly in varying situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only explains prim_path with a concrete example. ctx, node_path, and max_attributes remain entirely undocumented, so the description fails to compensate for the schema gap for three of four parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns type/active/loaded/kind plus bounded attributes for a single prim, making its purpose specific and unambiguous. It distinguishes from sibling query tools like lop_prim_search by targeting a single prim's core properties rather than searching or general 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage is for retrieving a specific prim's info and marks prim_path as required, but it does not explicitly compare to alternatives like get_usd_prim_stats or provide when-not-to-use guidance. It gives a prerequisite but no exclusions or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that unknown/expired IDs return a structured error and mentions optional ownership validation. However, it does not state whether the operation is read-only, who has access, or what the response format is beyond the error case.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the primary purpose stated first. No redundant details or fluff, achieving maximum efficiency for the information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, no annotations, and no output schema, the description is insufficient. It explains cook_id partially but omits semantics for ctx and node_path, and does not describe the success response structure, only the error behavior. This leaves significant gaps 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.
Parameters2/5Does 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 adds meaning for cook_id (optional ownership check) but leaves ctx and node_path completely unexplained. Both are required, and without description the agent cannot infer their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb '查询' (query) and identifies the exact resource (TOP cook status and work item count). This clearly distinguishes it from sibling tools like pdg_cook (trigger cook) and pdg_workitems (list work items).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking status and counts, but does not explicitly state when to use this tool versus alternatives like pdg_workitems or pdg_cook. No exclusions or alternative mentions are given, leaving usage context vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly discloses that the tool returns a dict rather than a string, details the Pydantic validation failure that motivated this behavior, mentions server-side return behavior and error fallback, and explains the environment-specific fork redirect and consent token mechanism. This is rich behavioral context 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with an IMPORTANT block but is verbose and includes an exact Pydantic error message and a reference to _render_policy.py. Every sentence adds some technical detail, but the structure is dense and could be more concise by separating critical usage notes from implementation details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers output type, error behavior, and consent token requirements, and mentions that the result dict contains 'renderer / image_path / size_bytes / etc.' However, it lacks parameter semantics and clear usage boundaries relative to sibling render tools. For a 6-parameter tool with no annotations and no output schema, this is only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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, but it only indirectly explains karma_engine and consent_token. It does not describe rotation, render_path, orthographic, render_engine, or the meaning of their defaults. Though parameter names are somewhat self-explanatory, the lack of any schema descriptions or clarification leaves a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states "Render a single view inside Houdini and return a structured result dict." This gives a specific verb (render), resource (a single view inside Houdini), and output type. It distinguishes from siblings like render_quad_views by emphasizing "single view," though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The IMPORTANT block provides usage context for specific environments: on machines lacking OGL 3.3, the opengl renderer redirects to capture_pane_screenshot, and karma_cpu/karma_xpu renderers require a consent_token obtained from the first call's _interrupt field. However, it does not explicitly say when to prefer this tool over sibling render tools 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fully discloses that this is a scene-write operation, is undoable, requires finite floats with start<=end, supports sub-frame end values, returns status=error on invalid inputs without writing, and persists on success via hou.playbar.setFrameRange. This is excellent transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, using two compact sentences. It front-loads the purpose, then packs validations and error behavior without fluff. Every sentence adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, validations, error behavior, and persistence, but misses the meaning of ctx and the success return shape. Given no output schema, a brief note on success status would improve completeness. The tool is simple enough that this isn't critical, but the gap in ctx is noticeable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 constraints for start and end (finite floats, start<=end, sub-frame possible) but completely omits ctx. Without explanation, ctx remains ambiguous. This partially compensates for the schema gap but leaves a key parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set global frame range' with a specific verb and resource. It mentions it's global and scene-writing, which distinguishes it from related tools like set_playback_range, though it doesn't explicitly name alternatives. Purpose is clear and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description notes it's global and writes to the scene, but there is no mention of preferred use cases or exclusions. Without context, the agent gets no direction on selecting this over similar 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?
The description explicitly marks the tool as MUTATING and discloses the implementation mechanism (parmTemplateGroup() copy + setParmTemplateGroup() commit). This gives the agent awareness of the mutation without relying on annotations. It does not detail side effects or reversibility, but the core mutating behavior is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of three short sentences that front-load the purpose. However, it includes low-level implementation details (e.g., 'parmTemplateGroup() copy') that might not be necessary for an agent to invoke it correctly, slightly reducing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, no output schema, no annotations), the description is incomplete. It does not explain most parameters, provide examples, or describe return values/errors. An agent would likely struggle to use it correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 for data_type (lists accepted values) and folder (optional), but the other 10 parameters (ctx, path, name, label, default, etc.) remain undocumented. This is insufficient for a 12-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '单项 spare 参数创建' (single spare parameter creation), which identifies the action and resource. It distinguishes itself from sibling tool create_spare_parameters by emphasizing the singular nature ('单项'), providing clear 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a single parameter via the '单项' qualifier and the singular name, but does not explicitly say when to use this over create_spare_parameters or other parameter tools. No direct alternatives or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well. It discloses that the operation is a scene write, is undoable, requires a finite float frame for sub-frame precision, returns an error without writing if the frame is missing, and advises verification by re-reading the keyframes list. This is rich, actionable 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with key details separated into short sentences. It avoids fluff and is front-loaded with the main purpose. The mention of 'PR 19' is cryptic and not explained, but overall it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 required parameters, no output schema, and no parameter descriptions. While the description covers behavior and the 'frame' constraint, it omits the meaning of ctx, path, and parameter, and does not specify success return values. For a mutation tool with no structured schema support, this is incomplete for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 specific meaning only for the 'frame' parameter (finite float, sub-frame exact point). The other three required parameters (ctx, path, parameter) are left entirely unexplained, which is a significant gap for invoking the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'keyframe at specified frame', making it obvious what the tool does. It also distinguishes itself from sibling tools like set_keyframe and get_keyframes by specifying the deletion operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides behavioral constraints (e.g., frame must be finite float, missing frame returns error) but gives no guidance on when to use this tool versus alternatives like set_keyframe or set_keyframes. No exclusion criteria or alternative tool names 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?
No annotations are provided, so the description carries the full burden. It mentions the return behavior ('reports what it was connected to'), which is a useful disclosure. However, it does not describe side effects, reversibility, or behavior when the input is already disconnected, leaving gaps in transparency for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action. Every word earns its place, avoiding unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but no output schema exists. The description hints at the return value but does not specify its structure or edge cases. While sufficient for a basic understanding, it lacks details that would fully inform an agent, such as behavior on invalid input or already-disconnected inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides no explanation of 'path' or 'input_index'. The phrase 'one input' is vague and does not clarify index semantics. This 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.
Purpose5/5Does 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 ('Disconnect') and resource ('one input of a node'). It also adds value by noting the tool reports what it was connected to, which distinguishes it from siblings 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this when you need to remove an input connection. It does not explicitly provide exclusions or name alternatives, but the purpose makes the usage scenario well-understood. A slight deduction for missing explicit 'when not to use' 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 carries the full burden. It discloses important behavioral traits: that the operation may trigger a COP cook (side effect) and that the response passes through apply_response_cap (response modification). It also notes 'NO_UNDO' indicating no undo support. This is valuable context beyond a simple 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the first line stating the core purpose and flags, and the second line adding return details and side effects. It avoids unnecessary filler, though the heavy use of technical jargon ('outputCableStructure', '反射探针') may reduce clarity for some agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and no parameter descriptions, the description is incomplete for reliable invocation. It does not explain the 'ctx' parameter, how to structure node_path, or what the 'reflection probe' means. While it lists return types, the missing param semantics and usage context make it insufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 2 parameters (ctx, node_path) with no descriptions, and the description does not explain their meaning or format. While 'node_path' is somewhat self-explanatory, 'ctx' is ambiguous and could refer to context or a Houdini context. With 0% schema coverage, the description should have compensated but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('读取' / read) and resource ('Copernicus 节点信息' / Copernicus node info). It also specifies the unique return data (input/output types, outputCableStructure, cable metadata), which distinguishes it from sibling tools like get_cop_geometry or get_cop_layer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing node info or cable metadata, and mentions side effects (may trigger COP cook). However, it does not explicitly state when to use this tool over alternatives, nor does it provide any 'when not to use' guidance. The specificity of the return values gives some contextual hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the NO_UNDO behavior, a server-side response cap (apply_response_cap), and version-specific availability of edge groups. This adds useful behavioral context beyond the bare function 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, immediately stating the main purpose and then adding key caveats. It is well-structured and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the group types and edge group version, but lacks parameter guidance (ctx, node_path) and does not clarify what the response looks like beyond 'name list'. Because the output schema is absent, this leaves notable gaps for an agent to fully understand the tool's expected usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the meaning of ctx or node_path. The agent has no information about these parameters beyond their names, making it hard to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns name lists for four specific group types (point, prim, vertex, edge). This distinguishes it from sibling tools like get_group_members which deal with group membership, and other geometry inspection tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied from the purpose: use when you need group names. The note about edge groups requiring H21+ provides some context but does not explicitly mention when to prefer this tool over alternatives or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the internal function (hou.selectedNodes()), the exclusion of non-node items, the return structure (selected/count with path/type/category), and the server-side response cap. This is strong transparency, though it could mention edge cases like empty selection or order.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. Every sentence adds meaningful detail about behavior, scope, return format, or limitations. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool, the description covers purpose, behavior, and return format well. However, the missing parameter semantics for the required 'ctx' parameter is a critical gap. The description does not enable full understanding of how 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The required 'ctx' parameter is completely undocumented in the description, and schema description coverage is 0%. The agent has no clue what 'ctx' represents or how to populate it, making correct invocation impossible without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the current node selection, specifies it uses hou.selectedNodes() rather than selectedItems(), and explicitly excludes network boxes/notes/dots. This distinguishes it from any generic selection tool and matches the name and sibling context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a usage context: use this when you need the node selection only, not mixed items. However, it does not explicitly name alternatives or provide when-not-to-use guidance, so the agent must infer when this is the right choice.
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 that it manually calls setPosition, is portable across Houdini versions, and returns a dict with specific fields. However, it does not mention side effects on existing child positions, error conditions, or whether the operation is destructive. With no annotations, this is moderate transparency but leaves important behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a main sentence, bullet-point parameter explanations, and a returns note. It is slightly verbose but every sentence adds value, especially given the sparse schema. Front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with no annotations and no output schema, the description covers the return dict and parameter details well, but lacks usage context, why choose this over layout_network, and any caveats or examples. It is serviceable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates well: it explains all parameters except ctx, providing defaults (horizontal_spacing=2.0, vertical_spacing=1.5, direction='horizontal'), types (parent_path is PR9 recommendation, parent is alias), and precedence rules. It omits ctx, which is a required param, but the rest are well documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '布局父节点下的子节点' (layout children under a parent node) with a specific implementation detail ('按间距参数手动 setPosition') that distinguishes it from other layout tools like layout_network. The verb and resource are 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives (e.g., layout_network). It provides parameter precedence (parent_path over parent) and backward compatibility, but no context for choosing this tool over others. This is a significant gap given layout-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and explicitly states '只读不改场景' (read-only, does not modify scene), which is a key behavioral disclosure. It also lists return fields, but lacks details on permissions, performance, or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action, and every word serves a purpose. No redundant or irrelevant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main functionality and return fields, making it clear for a simple list tool. However, the total absence of context for the 'ctx' parameter and the lack of any detail on expected behavior or prerequisites leaves a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'ctx' with 0% description coverage, and the tool description does not mention it at all. There is no explanation of what 'ctx' means or how it affects the listing, leaving the agent without guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '枚举全部 takes' (enumerate all takes), which is a specific verb+resource action. It further specifies return fields (name/path/parent/current), making it distinct from siblings like set_current_take or 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by defining the action, but it does not explicitly state when to use this tool versus alternatives such as get_current_take or create_take. It lacks exclusionary guidance or mention of alternative approaches.
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 states read-only behavior, the return tuple structure, and the meaning of 'is_current'. The mention of 'apply_response_cap' is cryptic but adds some context beyond basic 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the purpose, followed by return format and safety note. No wasted words or repetitive content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers the core purpose and return format, but the unexplained 'ctx' parameter and ambiguity about 'current all desktops' leave gaps. The response cap note is vague, but overall the description is adequate for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the required 'ctx' parameter at all. This is a critical gap, leaving the agent without any understanding of what ctx should be.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses a specific verb 'list' and identifies the resource as 'visible pane tabs in current desktop'. This distinguishes it from sibling tools like capture_pane_screenshot and get_viewport_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for enumerating visible panes but provides no explicit guidance on when to use it versus alternatives, nor any exclusions. It is a clear purpose but without direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite lacking annotations, the description proactively discloses critical behavioral traits: full validation before any commit ('先全量校验、失败零部分提交'), execution via a single setParmTemplateGroup() call, and response processing through apply_response_cap. This provides a solid mental model of the operation's safety and mechanics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, using three short sentences to convey purpose and key execution details without redundancy. It front-loads the main action and avoids unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with no annotations or output schema, the description provides atomicity and execution details but omits essential parameter format and semantics for all fields. The undefined spec dict format and unstated roles of ctx, path, and folder make the tool under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies that 'parameters' is a list of spec dicts, which helps given the schema only types it as a string. However, it does not explain the structure of the spec dicts or the meaning of ctx, path, and folder. With 0% schema description coverage, this leaves significant ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a batch spare parameter creator ('批量 spare 参数创建'), which is distinct from the singular sibling create_spare_parameter. It also references the underlying function, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word '批量' implies batch usage, but there is no explicit guidance on when to use this tool versus create_spare_parameter or set_parameters. No exclusions or alternatives are mentioned, 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.
- 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 stdout/stderr return format, rejection of empty/whitespace code, and error message format. However, it does not mention potential side effects of arbitrary command execution, permissions, or execution context beyond 'in Houdini', leaving significant behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate sections for the command and parameter details, includes a concrete example, and wastes no words. It could be slightly tighter but is effectively concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, input, and output format, but lacks details on `ctx`, safety considerations, command execution limits, and error conditions beyond the generic error message. For an arbitrary command execution tool, this is only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must document all parameters. It thoroughly explains `code` with an example and constraint, but completely omits `ctx`, which is required. Only half the parameters are documented, leaving a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes HScript command strings in Houdini, explicitly naming built-in commands like `ls`, `cd`, and `opset` as examples. It also distinguishes HScript from the Python interface, differentiating it from sibling 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says HScript is suitable for executing built-in commands, which gives clear context for when to use this tool. However, it does not explicitly mention alternatives or exclusions (e.g., 'use execute_houdini_code for Python'), so it stops short of full 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 the transparency burden. It discloses the fallback mechanism (layer/layerAtFrame then cable reflection), the cable_fallback_used response flag, and the NO_UNDO characteristic. This is valuable beyond what annotations would offer, though edge cases like complete failure are not covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core purpose, and provides implementation details and return limitations without unnecessary fluff. Each sentence serves a distinct purpose, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and sparse annotations, the description should be more thorough about parameter semantics and response structure. It states high-level return types but omits details on how output_index and frame affect results, or what happens on error, leaving significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain any of the four parameters (ctx, node_path, frame, output_index). While node_path and frame can be inferred from context, the lack of explicit parameter definitions leaves the agent to guess at their exact usage and formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads Copernicus ImageLayer metadata, specifies the exact return fields (resolution/storage/bounds), and explicitly excludes raw pixels. This differentiates it from sibling tools like get_cop_info or get_cop_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for metadata retrieval but does not explicitly state when to use this tool versus alternatives like get_cop_info or get_cop_geometry. No exclusions or comparison with siblings are provided, so the guidance is only implicit.
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 behavioral disclosure burden. It reveals important traits: NO_UNDO, pagination behavior with offset/limit, server-side response cap via 'apply_response_cap', and the exact structure of returned values. This goes beyond the schema, though it does not explicitly state whether the operation is read-only (though '读取' implies it).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and uses bullets for clarity, but includes an extraneous tag 'add-geometry-export-and-measure' and cryptic terms like 'apply_response_cap' that are not explained. Despite this, it is relatively efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides return structure and pagination details, which is helpful given no output schema. However, it omits key context such as accepted group_type values, the meaning of node_path/ctx, potential errors, and permissions. For a tool with 6 parameters and no output schema, this leaves gaps in usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 offset/limit (including default limit) and describes vertex/edge member formats, but fails to define ctx, node_path, group_type, and group_name, which are required parameters and not self-explanatory from the schema. Additionally, the description states offset/limit are '必填' (required), contradicting the schema which lists them as optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's primary function: '分页读取 group 成员' (paged read group members). It specifies a distinct resource ('group members') and differentiates from sibling tool 'get_groups' which lists groups. The pagination aspect and member structure details further clarify the tool's 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs to read group members with pagination, but does not explicitly state when to use this tool over alternatives or when not to use it. No exclusions or alternatives are provided beyond an implicit separation from 'get_groups'.
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 read-only nature, the max_nodes traversal budget, truncation behavior via truncated/truncation_reason, and the server-side response cap. This is strong behavioral context, though it doesn't cover error cases or exact category semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and information-dense, using inline code formatting effectively. However, the parenthetical 'add-scene-context-selection-materials' is cryptic and adds little value, slightly reducing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It lists return fields and truncation behavior, giving a good picture of output. But ctx is unexplained and 'category' is ambiguous; the timeline is mentioned but not detailed. It's adequate but has notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 max_nodes as controlling the HOM traversal budget, but the required ctx parameter is completely unexplained, leaving half the parameters underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides full-scene category counts and timeline, and explicitly distinguishes itself by noting it returns aggregated category distribution rather than the full node list. This sets it apart from sibling 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied—use it when you need scene-wide category counts and timeline data. However, it does not explicitly compare to alternatives or state when not to use it, so guidance is only implicit.
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 and adds meaningful behavioral details: it warns about the 'viewport_unavailable' edge case when no GUI/pane exists, and notes that the response passes through the server-side 'apply_response_cap'. These go beyond the simple 'returns info' implication and the input schema, though it omits any mention of permissions or exact return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose, followed by a field list and edge-case notes. Each sentence adds value, though the parenthetical 'add-viewport-control-tools，NO_UNDO' is somewhat cryptic but still informative as a tag-like metadata. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action, output fields, and a failure mode, which is decent for a simple getter. However, the unexplained parameter and the lack of any output schema leave a notable gap: the agent doesn't know what 'ctx' is or how the response is structured beyond a field list. Enough to be adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'ctx' is required but completely unexplained. Schema description coverage is 0%, and the description does not compensate; it only discusses return fields. The agent is left guessing what 'ctx' means, how to populate it, or what valid values are. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the current SceneViewer viewport schema, listing specific fields (camera, viewport_type, display_set, shaded_mode, hydra_renderer). This specific verb+resource combination distinguishes it from sibling setter tools like set_viewport_camera or set_viewport_display, and from other getters targeting different contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case: when you need to know the current viewport schema or its fields. It does not explicitly mention alternatives or exclusions, but the context is unambiguous – this is the tool for reading viewport information, while siblings are for setting or capturing. No misleading 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 carries the full burden. It discloses that the operation is mutating and outlines the internal validation and creation calls, plus a response cap via apply_response_cap. However, it does not mention permissions, reversibility, or failure behavior when canCreateDigitalAsset() returns false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but information-dense, with a clear purpose statement and code-like steps. It is well-structured and front-loaded, though the parenthetical '(add-hda-management-tools, MUTATING)' adds context without excessive length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main workflow but lacks details about return values, error handling, or prerequisites beyond the canCreateDigitalAsset check. With no output schema, the response format is not explained, leaving the agent with an incomplete picture for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must explain parameters. It explains that 'label' maps to the description parameter, but it references 'hda_file_name' which does not appear in the schema, and it does not clarify the roles of 'node_path' or 'save_path'. This creates ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '从节点创建 HDA' (create HDA from node), identifying a specific verb, resource, and scope. It also labels the operation as MUTATING, distinguishing it from read-only HDA tools like hda_get or hda_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a procedural sequence (canCreateDigitalAsset() then createDigitalAsset()) but does not explicitly contrast with sibling tools such as hda_install or update_hda. There is no explicit 'when not to use' guidance, though the 'from node' phrase implies a specific use case.
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 assumes full responsibility for behavioral disclosure. It goes beyond the basic action by revealing a side effect: 'Server-side also calls cmn.invalidate_all_caches() so downstream caches reset on scene switch.' This is valuable transparency, though it omits other potential behaviors like overwriting unsaved changes or error 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, both essential. The first states the core action, the second adds a relevant side effect. No redundancy or filler, and it is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema) and the lack of annotations, the description covers the essential purpose and a significant side effect. It does not mention return values, but none are expected, and the cache invalidation context adds completeness beyond a bare description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 says 'Load a .hip file' without explaining the file_path parameter's format, supported paths, or constraints. The connection between the parameter and the action is implied but not explicitly detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Load a .hip file as the current Houdini scene.' This uses a specific verb (Load), a specific resource (.hip file), and the context (current scene) which differentiates it from sibling tools like new_scene or save_scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention 'use this instead of new_scene when you need to restore a saved scene' or any prerequisites, making it ambiguous for an agent deciding between load_scene, new_scene, or serialize_scene.
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, and it does well by disclosing that it is MUTATING, uses parm.revertToDefaults(), groups changes into a single undo group, and applies response cap. It lacks details on error handling or permissions, but the core behavioral traits are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of three short sentences, each adding specific information: purpose, implementation, and response handling. It is front-loaded with the main action and includes no fluff, though it assumes familiarity with terms like 'apply_response_cap'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool, the description provides the essential operation details and notes the undo behavior, but it omits parameter meanings, prerequisites (e.g., node existence, parameter existence), and potential return values. It is minimally adequate but leaves gaps for an agent to make assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 three parameters (ctx, path, parameter). It only mentions "parm" generically, leaving the agent to infer which parameter is the target. This 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: "恢复 parm 至默认值" (Restore parm to default values), using a specific verb+resource. It also explicitly marks it as "MUTATING", which distinguishes it from non-destructive parameter tools like get_parameter or lock_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you want to reset a parameter to its default value. However, it does not explicitly mention when not to use it or contrast it with alternatives like set_parameter or delete_keyframe. The 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 provided, the description takes on full disclosure responsibility. It clearly discloses critical behavioral traits: only 'Help' and 'IconSVG' sections are allowed (case-sensitive exact match), all other sections result in 'section_write_denied' with zero writes, content is limited to 65536 UTF-8 bytes, and responses pass through 'apply_response_cap'. This goes beyond minimal disclosure, though it doesn't mention 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using three compact lines to convey the core behavior and all critical constraints. Every sentence carries specific information (allowlist, section names, size limit, response cap) with no filler words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with three parameters and no output schema, the description covers most essential context: what it does, which sections are permitted, content size limits, and response handling. However, the 'node_type' parameter is unexplained, and the meaning of 'apply_response_cap' is left for the reader to infer, leaving minor gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 meaningful semantics for two of three parameters: 'section' is restricted to Help/IconSVG with case-sensitive exact match, and 'content' has a UTF-8 byte limit of 65536. However, it does not explain 'node_type', leaving that parameter ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool writes a section ('allowlist 写入 section') and labels it as MUTATING, clearly indicating a write operation on HDA section content. The resource is implied by the tool name and the 'add-hda-management-tools' category, but it doesn't explicitly name 'HDA' in the description, so it's not fully specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_hda_section_content or update_hda. It only lists constraints (allowed sections, content size) but does not state usage context or scenarios 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral burden. It discloses pre-validation of key/value/parm writability, snapshoting old values, explicit restore on failure (not relying on undo), status codes for success, apply-failure with restore success, restore failure with 'restore_errors', and the response cap. This is exceptional transparency for a write 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but structured, with a leading summary phrase and clear bullet-like details about validation, restore behavior, status codes, and response cap. It avoids unnecessary filler and each sentence contributes meaningful information. It is slightly technical but appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 description covers essential behavioral aspects including error handling, restored flags, and response cap. It does not provide parameter examples or detailed return structure beyond status codes, but for a write operation it is reasonably complete. The lack of parameter semantics is a gap, but the tool's core behavior is well explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage. The description mentions 'key/value/parm' which gives a hint that the 'parameters' object contains key-value pairs validated for writability, but it does not explain 'node_path' or the structure of 'parameters'. It adds some semantic about validation but is insufficient to fully 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with "受限可撤销写入" (limited reversible write), indicating a write operation with rollback, and references the specific design.md section. While it doesn't explicitly say "sets render settings", the tool name and context make the resource clear. It distinguishes itself from generic set_parameters etc. by focusing on reversible write semantics, though it doesn't name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for applying render settings with pre-validation and rollback, which suggests it should be used when reversible writes are needed. However, it never explicitly states when to use it or when to prefer alternatives like set_parameters. No exclusions are provided, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does an excellent job: it flags the operation as MUTATING, discloses that it does NOT call `definition.save()`, lists validation prerequisites (node exists, has definition, instance type matches), and mentions the response passes through `apply_response_cap`. This gives an agent insight into side effects and safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a first sentence states the purpose and mutating nature, followed by a short paragraph with implementation details. No fluff, and code identifiers are clearly marked.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter mutation tool without an output schema, the description covers the core behavior, validation steps, and a key non-behavior (no save). It does not explain what 'apply_response_cap' does or what the return value signifies, which would help an agent anticipate the response. Overall, it's above average but has minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines `node_path` with no description, and schema coverage is 0%. The description indirectly clarifies that `node_path` refers to the instance node via references to '节点' and the validation logic. However, it does not explicitly define the path format or provide examples, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the primary action in the first line: '从实例更新定义' (update definition from instance), with a specific verb and resource. It also names the underlying API method (`definition.updateFromNode(node)`), which disambiguates from generic HDA tools. However, it does not explicitly contrast with sibling tools like `hda_create` or `reload_hda`, so it's clear but 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no instructions on when to use this tool versus alternatives. It mentions verification steps and implementation details, but no use-case context or exclusion criteria. It does not say 'use this when...' or point to a sibling for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains ordering guarantees (strict top/front/right when views=None; caller's order otherwise), validation (PNG IHDR check), and return structure (per-view results and state_restored). This is solid transparency, though it does not detail potential side effects or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, consisting of two sentences that front-load the core purpose and then immediately cover behavior and return information. Every word earns its place with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters, no annotations, and no output schema, so the description must compensate for complexity. It adequately covers the core capture behavior and views constraints but leaves parameter semantics for 5 of 6 parameters unexplained, and the return structure is only vaguely described as 'structured per-view results.' This is a minimum viable description but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 provides detailed semantics for the 'views' parameter (ordering, duplicates, unknown views) and mentions 'Perspective' as an explicit request. However, the other five parameters (ctx, save_dir, pane_name, desktop_name, fit_contents) are completely unaddressed, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: capturing Top/Front/Right flipbook views from the SceneViewer, with an option to request Perspective. This specific verb+resource+scope distinguishes it from sibling tools like capture_pane_screenshot or render_quad_views, which target different capture mechanisms or view configurations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for generating standardized flipbook captures from the SceneViewer, but it does not explicitly state when this tool is preferred over alternatives or when it should be avoided. The views parameter behavior is described, but no exclusions or alternatives are mentioned, leaving the 'when to use' guidance merely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly warns that side effects cannot be undone and explains the remove_disk_file parameter's impact on disk files. However, it does not mention other potential side effects or return behavior, so it is not fully 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence (two clauses) that conveys core purpose, a parameter condition, and an important side effect. Every word earns its place, with no redundant or fluff content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 annotations, yet the description covers the main action and key side effects. However, it omits details about required parameters (ctx, node_path), potential return values, and any preconditions. For a mutation tool of moderate complexity, this leaves gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 remove_disk_file parameter's effect, but the required parameters ctx and node_path are not described at all. This is a significant gap for a tool with no parameter documentation in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'clears runtime cache' with a specific verb and resource. It also distinguishes itself from sibling tools like manage_cache and list_caches by noting the optional disk file deletion behavior, making it unmistakable what this 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for clearing caches, but it does not explicitly state when to use it versus alternatives like manage_cache or list_caches. There are no exclusions or alternative tool references, 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 provided, the description carries the burden and discloses that the operation is MUTATING, uses hou.copyNodesTo, and pre-checks category and name conflicts. However, it does not specify conflict outcomes (error vs rename) or required permissions, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with the core action front-loaded in the first clause and supporting details in short subsequent sentences. It includes extra identifiers like the tool category but remains focused and free of unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no output schema; the description covers the main action and some behavior (mutating, pre-checks, name handling) but leaves out return format, error handling, and the role of ctx. It is adequate for basic use but not fully complete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for the 'name' parameter by noting it is optional and that None defers to hou, and it implies dest_parent is the target parent. It does not explicitly describe src_path or the ctx parameter, leaving them to be inferred from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the primary action: '复制节点到 dest_parent 下' (copy node to under dest_parent), which provides a specific verb, resource, and destination. It distinguishes from sibling move_node by explicitly using 'copy', 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for copying nodes but does not explicitly contrast with alternatives like move_node or create_node, nor does it state prerequisites or exclusions. It mentions pre-checks for category and name conflicts, which hints at behavior but not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and successfully discloses that the tool is MUTATING, validates parent editability and child category, requires node_type to exist in the Cop registry, and operates as a single undo group. It does not cover error behavior or return values, which would enhance transparency, but the mutation and validation context is well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (two sentences) and front-loaded with the core purpose ('create a node under the Copernicus parent'). It packs essential behavioral detail (mutation, validation, undo group, optionality) without redundancy, making every sentence earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering the 4-parameter schema, no output schema, and no annotations, the description covers purpose, mutation, validation, and undo behavior, but it omits return value semantics and failure behavior. Since there is no output schema to clarify what the tool returns, the description should explain what the agent can expect on success (e.g., the created node path), making it incomplete but not severely lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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: node_name is explicitly noted as optional, parent is described as needing to be 'editable', and node_type must exist in the Cop registry. However, the required 'ctx' parameter is completely unexplained, and node_type's actual value range is not given beyond registry existence, leaving a significant semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('create') and resource ('a node under the Copernicus parent'), and includes validation rules that clearly distinguish it from generic create_node and other node-type-specific tools like create_lop_node or create_chop_node. The parenthetical labels '(add-cops-tools，MUTATING)' reinforce the specific scope and mutation intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the name and 'under Copernicus parent' phrasing, and it mentions validation constraints that guide when it is appropriate. However, it never explicitly names alternatives (e.g., 'use create_node for generic nodes') or states when not to use this tool, so guidance remains implicit 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 provided, the description carries the full burden and does reasonably well: it discloses the whitelist restriction, post-creation parameter validation through the same whitelist, a renderer recognizability check, and a response cap. It does not elaborate on side effects or return format, but key behavioral constraints are stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the action and restriction. It could drop the design.md reference and the internal apply_response_cap note, but overall every sentence adds some useful constraint or behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description is not sufficient for confident invocation. It lacks parameter semantics, response/return details, and only covers errors for unknown node types—not for invalid parameter values, naming, or parent_path behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate by explaining parameters. It only hints at allowed values for node_type and vaguely mentions 'parameters' without describing the structure of the parameters object or the meaning of name and parent_path. Most parameters remain semantically ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific action—restricted creation of classifiable ROP nodes—and enumerates the allowed node types (ifd/opengl/karmarender). This distinguishes it from generic siblings like create_node and render-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage boundaries: only whitelisted node types are allowed, and unknown node types cause a complete error. It does not explicitly name an alternative for unrestricted creation, but the restriction clearly implies when this tool is appropriate.
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 takes on the burden of disclosing behavior. It explicitly states '只读' (read-only) and notes that unknown types return 'unsupported_cache_type', providing error-handling context. It does not cover permissions, rate limits, or output format, but the disclosed traits are useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact two-clause sentence that conveys purpose and a key behavioral trait without waste. It front-loads the core action and keeps the read-only note at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameter descriptions, the description leaves significant gaps, particularly around ctx and the structure of the returned summary. However, it covers the basic purpose and one error case, making it minimally viable for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must explain parameters. It implies node_path refers to a cache node path, but ctx is entirely unexplained. The description does not define the expected format or semantics for either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb '读取' (read) and identifies the resource as 'cache 节点 status 摘要' (cache node status summary), clearly distinguishing it from mutation tools like manage_cache or clear_cache. It also notes behavior for unknown types, reinforcing its 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states '只读' (read-only), implying use for querying status without side effects. However, it does not explicitly name alternatives or provide when-not-to-use guidance, so the usage context 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 behavioral disclosure burden. It explicitly states '只读' (read-only), indicating no modification side effects, and specifies return fields. It omits error handling but for a simple read operation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that front-load the action and output. Every word contributes value, making it extremely concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits any explanation of the 'ctx' parameter, and there is no output schema to detail the return structure. It notes the return fields but leaves parameter semantics unexplained, creating a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema includes one parameter 'ctx' with no description, and the description does not mention 'ctx' at all. With 0% schema coverage, the description fails to add any meaning to the parameter, leaving it completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states '读取当前 take' (read current take) and lists return fields (name/path/parent) plus '只读' (read-only). This clearly identifies the operation and distinguishes it from sibling tools like list_takes, 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by indicating it reads the current take and returns its properties, implying when to use it. However, it does not explicitly mention alternatives or exclusions, so it falls short of full 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 transparently describes the pagination mechanism and cursor flow, which is valuable. However, it does not mention whether the operation has side effects (e.g., consuming/acknowledging events), preconditions (e.g., valid ctx), or what happens on empty results. This partial disclosure is insufficient for a tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource, followed by the essential cursor detail. Every word contributes to understanding the tool's core behavior and usage. It is appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and no annotations, placing a high burden on the description. The description covers the primary purpose and pagination flow but omits details about required 'ctx', the 'limit' parameter, and the structure of the returned events. It is minimally viable but leaves the agent guessing about how to construct an initial call and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 three parameters. It only explains 'cursor' by stating it is returned from the previous page, adding meaning beyond the schema's default null. The other parameters 'ctx' (required) and 'limit' (with default 100) are not mentioned at all, leaving their purpose and format undocumented. This is a significant gap given zero schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '分页拉取 Houdini 进程级事件' (paginated fetch of Houdini process-level events). The verb '拉取' (fetch) specifies the action, and the resource '进程级事件' is distinct from sibling tools like subscribe_houdini_events and unsubscribe_houdini_events, which manage event subscriptions. The scope is unambiguous and differentiates 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for paginated retrieval of Houdini events, with the note that the cursor comes from the previous page's response, guiding how to iterate through pages. However, it does not explicitly state when to use this tool over alternatives like subscribe_houdini_events or exclude scenarios. The pagination context is clear but lacks direct comparison to sibling 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 full responsibility for behavioral disclosure. It explicitly warns about '落盘 + 全局 HDA registry 副作用' (disk + global HDA registry side effects) and that changes are '不由 Houdini undo 恢复' (not recoverable by Houdini undo). It also mentions 'apply_response_cap', which adds behavioral context. However, it does not cover permissions, error handling, or return values, keeping it slightly below full 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, using three short sentences to convey the main action, side effects, and response cap. Every sentence contributes meaningful information, and the most critical facts are front-loaded. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with global side effects, no output schema, and no annotations, the description covers the most important points: what it does, that it is non-undoable, and its response cap. However, it omits parameter details and return/error behavior, which would be needed for fully safe deployment. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 'file_path' parameter beyond the schema's title. It does not compensate for the low coverage by describing path format, expected file types, or how to resolve paths. The parameter is self-explanatory by name, but the description adds no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '安装 HDA 库' (install HDA library), specifying a concrete verb and resource. It distinguishes from sibling HDA tools like hda_create, update_hda, and uninstall_hda by focusing on the install operation. 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes significant side effects and non-undoability, which implicitly conveys when to be cautious. However, it does not explicitly state when to use this tool versus alternatives like hda_create or update_hda, nor does it mention any prerequisites. Usage context is implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the read-only nature, the underlying Houdini API calls, deduplication logic, and the server-side response cap. These are meaningful behavioral traits, though it does not cover potential errors or pagination details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose first. It includes implementation details and dedup logic, but these might be more detailed than necessary for an AI agent. Still, there is minimal redundancy, and each sentence contributes information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list tool with no output schema and no annotations. The description covers purpose, behavior, and the filter, but it does not explicitly state the return value structure (e.g., array of objects with fields). The dedup keys imply some fields, but the lack of explicit return format leaves a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'category' lacks any schema description (0% coverage). The description adds only '可选透传过滤' (optional pass-through filter), giving minimal semantic meaning. It clarifies that the parameter filters results but does not explain allowed values or filtering behavior in detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with '枚举已加载 HDA' (enumerate loaded HDAs), which is a specific verb+resource statement. It clearly identifies the tool as a listing operation for loaded HDAs, distinguishing it from sibling tools like hda_install or hda_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing loaded HDAs but does not explicitly state when to use this tool versus alternatives. It mentions the optional category filter but provides no exclusions or comparative guidance relative to other list-oriented sibling 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, the description carries the full burden. It discloses read-only behavior ('只读'), BFS traversal, and the max_nodes limit, which are important safety and algorithmic traits. It does not explain return format or the meaning of 'whitelisted', but for a simple listing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key action and scope, with no filler words. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no output schema, the description covers the core action, safety, and limitations. However, missing details about the whitelist definition and the parent_path parameter make it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 semantics. It only clarifies max_nodes as a limit; ctx and parent_path remain unexplained. This is insufficient for full parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '枚举白名单 File Cache 节点' specifically states the action (enumerate) and resource (whitelisted File Cache nodes), with additional details about BFS and max_nodes limit. This clearly distinguishes it from sibling tools like list_children or list_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a read-only enumeration tool but does not provide explicit when-to-use guidance or mention alternatives. It mentions BFS and max_nodes, which gives context, but no exclusions or comparison to related cache 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. It states READ_ONLY, pagination, returns only name/object_id with bounded summaries, does not expand simulated data, and applies a response cap. These are concrete behavioral traits beyond the tool name and 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: three sentences deliver the primary action, output scope, and behavioral caveats without redundancy. It uses technical precision and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description must cover both behavior and return shape. It adequately describes pagination and response caps, but misses parameter semantics and exact return value structure beyond the field summary. Adequate for a listing tool but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain any of the four parameters (ctx, dop_path, limit, offset). '分页' hints at limit/offset, but their types, defaults, and required context (ctx, dop_path) are undocumented in either schema or description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '分页列出 DOP objects' (paginated list of DOP objects), identifying both the verb (list) and the resource (DOP objects). It also distinguishes itself from sibling tools like get_dop_object by specifying it returns only summaries, not expanded data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a listing use case and highlights pagination and limited field returns, but does not explicitly mention when to prefer this over alternatives like get_dop_object or get_dop_field. There is no explicit 'when not to use' or reference to sibling tools for detailed lookups.
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 discloses NO_UNDO semantics and the server-side response cap (apply_response_cap), which are useful beyond the tool name. However, it does not mention whether this is a read-only operation, permissions required, or any pagination/error 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with each sentence providing meaningful information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or output schema, the description covers core behavior (match type, fallback, cap) but omits parameter details, result format, and edge cases. It is adequate for basic use but lacks complete operational context for an agent needing to set max_depth or understand ctx/node_path.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 for name (substring) and type_name (exact match), and implies cap applies to max_prims, but it leaves ctx, node_path, max_depth, and max_prims mostly undocumented. This is insufficient for a 6-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies a verb ('search') and resource ('prim') with match criteria ('name substring / type_name exact'), distinguishing it from sibling tools like list_usd_prims and lop_prim_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when both search criteria are omitted, the tool behaves equivalently to list_usd_prims (subject to cap), providing clear fallback usage context. It does not discuss exclusions or when to prefer alternatives, but the primary usage scenario is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that cancelling is irreversible, idempotent for terminal handles, and returns 'cancelled' for such handles. This is meaningful behavioral context beyond just 'cancel a cook'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with three short segments each adding key information: operation, idempotency, and irreversibility. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core behavior but lacks parameter roles, return value details, and edge cases (e.g., what happens if the cook is not running, or how cook_id vs node_path are used). Given no output schema, this is a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 never mentions any of the parameters (ctx, cook_id, node_path). The term 'handle' is vague and not mapped to any specific parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels a running cook, using a specific verb plus resource. It also notes idempotent behavior for terminal handles, which distinguishes it from sibling tools like pdg_cook and pdg_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies use when a cook is running and needs to be cancelled. It does not explicitly name alternatives or exclusions, but the context is unambiguous; the idempotency and non-undo warnings add practical 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?
Without annotations, the description carries the full burden. It discloses the in-process handle lifecycle (valid only in process, invalid after server restart), the blocking polling behavior until terminal state or timeout, and the effect of blocking=True. This is meaningful behavioral context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core purpose and then key behavioral details. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 covers the essential behavioral aspects (handle, blocking, timeout) but lacks parameter explanations and expected return format. It is adequate for a high-level understanding but leaves out details that could impact correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 node_path or ctx. Only blocking=True is mentioned, offering partial clarity for that parameter. The semantics of the required parameters are left entirely to the agent, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool launches a PDG/TOPs cook and returns a handle. The verb '启动' (launch) and resource 'PDG/TOPs cook' are specific, and the mention of returning an in-process handle distinguishes it from sibling tools like pdg_status or 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about blocking behavior and handle validity, implying when to use it (for cooking PDG graphs). However, it does not explicitly state when not to use it, nor does it reference alternatives like cook_node for regular nodes. Guidance is present but not fully 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 provided, the description carries the full burden. It discloses an important edge case (returns empty list when PDG not generated) and explicitly mentions the limiting effects of status_filter and max_items. It does not mention error conditions or whether it may trigger cooking, but the read-only semantics are clear from the verb 'read'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. The core purpose is front-loaded, and every clause adds meaningful behavior (return fields, empty-list behavior, filter limits). There is no repetitive or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides useful context: return fields, empty-list behavior, and result limits. However, with no output schema and 0% parameter coverage, it falls short of explaining the exact return format and the roles of ctx and node_path. It is functional but leaves gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 status_filter and max_items by name and their limiting role, but does not describe acceptable values or format. The required parameters ctx and node_path are not mentioned at all, leaving their purpose unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation: reading generated work item summaries with fields index/name/state. It clearly distinguishes this from sibling tools like pdg_cook or pdg_status by focusing on the work item summary rather than cooking or overall status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: it is a read-only inspection tool for generated work items, likely after a PDG cook. However, there is no explicit guidance on when to choose this over pdg_status or other PDG tools, nor any conditions where it should not be used.
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 the full burden of behavioral disclosure. It clearly explains input clamping ('负值 clamp 为 0.0，>1 值 clamp 为 1.0'), the return structure ('返回 dict 包含 path / color / success 三项'), and error behavior ('节点不存在时函数会抛 ValueError'). This is strong transparency, though it omits details about the ctx parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear parameter bullets and separate sections for return value and error behavior. Every sentence adds operational value, and there is no redundancy or filler. The use of a compact list format improves readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's relative simplicity and the absence of annotations or output schema, the description is largely complete: it covers purpose, parameters (except ctx), clamping, return fields, and exception behavior. The omission of ctx prevents a full score, as it is a required parameter. Overall, it provides sufficient context for confident invocation in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description compensates for the 0% schema coverage by explaining node_path and the r/g/b components with their clamping ranges. However, the ctx parameter, which is required in the schema, is entirely missing from the description. Also, r/g/b are typed as strings in the schema, but the description treats them as numeric color components without clarifying how strings are converted, leaving a semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '设置节点颜色' (set node color), identifying the specific resource (node color) and action (set). It also distinguishes itself from sibling tools like set_node_flags and set_node_position by focusing solely on color. The clamp behavior adds useful 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/5Does 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_parameters or set_node_flags. It neither states ideal use cases nor explicitly excludes scenarios where other tools would be more appropriate. This leaves the agent without contextual decision-making support.
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 discloses two important behaviors: that unspecified flags are left unchanged and that unsupported flags return an 'unsupported' report. However, it does not mention potential side effects, required permissions, or how the result is returned, leaving 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, immediately stating the action and resource, then adding two key behavioral notes. Every sentence adds value and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no annotations, and no output schema. The description covers the core purpose and two behavioral nuances, but it omits details about return values, parameter semantics, and edge cases (e.g., what happens if path is invalid). It is moderately complete but leaves room for agent confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 names the flags but does not explain what true/false means for each boolean or the role of the required path parameter. The flags are listed but their semantic meaning is left to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Set node flags' with an explicit list of flag types (display/render/bypass/template). This distinguishes it from sibling tools like set_parameters or set_cop_flags, 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful usage context by explaining that only flags explicitly passed are changed, which helps avoid accidentally resetting other flags. It does not explicitly name alternatives or when-not conditions, but the partial-update guideline clarifies expected behavior.
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 disclosing effects. It discloses the key 'clear all subscriptions' behavior and the cancellation action, but does not mention reversibility, permissions, or error cases. Since this is a mutation tool, additional detail on side effects would be expected, but the main behavior is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with two clear clauses. It front-loads the main action and adds the important conditional behavior without any waste. Perfectly 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema and no annotations, the description covers the core action and the special omission case. However, it lacks details on 'ctx' and the accepted format of 'types', which are necessary for correct invocation. The overall picture is adequate but with noticeable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for parameter meaning. It only implies that 'types' is optional and omitting it clears all subscriptions, but does not explain what 'types' contains or what 'ctx' represents. This leaves significant ambiguity for the 2-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: canceling event subscriptions, with a specific resource ('指定事件' specified events) and an explicit behavior when types is omitted. It distinguishes from the sibling 'subscribe_houdini_events' by directly indicating the opposite action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: omitting 'types' clears all subscriptions, which guides on how to use the tool for different scenarios. It does not explicitly mention alternatives or exclusions, but the context is sufficient for an agent to know when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that save_dir is auto-created, each pane's result is independently reported, exceptions in one pane do not affect others, and the response passes through size cap handling. This is useful behavioral context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with three short sentences that front-load the core purpose and then add essential behavioral details. No redundant information or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description explains the return structure and failure isolation, it does not clarify what 'ctx' means, and the pane_types type mismatch with the schema is a gap. For a tool with 3 required parameters and no output schema, the description is not fully complete, though it covers key aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 that pane_types is a list of pane type names and save_dir is auto-created, but it does not explain the 'ctx' parameter at all. Also, there is a mismatch: schema says pane_types is a string while description says it is a list, which could be confusing. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (batch capture multiple panes) and the target resource (pane types). It distinguishes itself from sibling tools like capture_pane_screenshot by emphasizing the batch aspect, 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for capturing multiple pane types at once, but it does not explicitly compare with alternatives such as capture_pane_screenshot or when to prefer one over the other. There is no when/not-to-use guidance, only the implied batch use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explicitly states '仅做只读查询，不会修改 .hip 文件、节点或网络' (read-only, no modification to .hip, nodes, or networks), fully disclosing its non-destructive nature. It also details the return structure, which is strong behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but information-dense: it states the purpose, lists all return fields, notes structural consistency with server.py, declares read-only behavior, and gives usage timing. Every sentence adds value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The return fields and read-only nature are well documented, which covers most of what an agent needs for a diagnostic tool. However, the unexplained 'ctx' parameter is a notable gap, and there is no mention of potential errors or whether an active Houdini session is required. Overall, it is complete for the simple purpose but not perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain the required 'ctx' parameter at all. This is a single required parameter with no semantic guidance, so the agent cannot know what value to pass. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks Houdini connection information and lists the exact fields returned (hou_version, hip_file, etc.), giving a specific verb+resource. It does not explicitly contrast with sibling tools like ping_houdini, but the unique return fields and 'read-only' scoping make its purpose distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends calling this tool 'once at the beginning of a long session' to get Houdini version and scene scale, providing clear usage context. It does not mention alternatives or when not to use it, but the timing guidance is valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does an excellent job: it discloses validation steps, structured error types, undo grouping via hou.undos.group, and the response cap. These are behavioral traits beyond basic mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it leads with the core action, then details validation and error handling in a compact format. No redundant words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with no output schema, yet the description covers creation, validation, errors, undo grouping, and response handling. It lacks an explanation of ctx and the expected return value, but overall it is substantially complete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It implicitly references parent_path ('under parent') and name ('createNode("matnet", name)'), but completely omits context for the ctx parameter. The description does not explicitly map parameters to their roles, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool creates a matnet node under a specified parent, with a specific verb ('create') and resource ('matnet'). It also references the scene context selection materials, which helps distinguish it from general create_node or other material-related 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/5Does 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 like create_node or create_material. It mentions MUTATING and the scene context but does not state exclusions or preferred usage scenarios.
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 behavioral burden. It discloses that nonexistent nodes are silently skipped, that a ValueError is raised when the parent is missing, and that the return dict contains path/name/nodes_in_box. It does not mention permissions or reversibility, but the covered behaviors are meaningful for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear main sentence followed by a parameter list. It avoids redundant text and includes only necessary behavioral and return information. It is 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers return values and error behavior well, but omits the `ctx` parameter entirely, which is required by the schema. Given no output schema or annotations, the missing context for a required parameter leaves a notable gap. Overall, the description is mostly complete but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to parent_path, name, and node_paths, explaining optionality and the silent-skip behavior. However, the required parameter `ctx` is entirely missing from the description, creating a critical gap since the schema provides no description for it either. This partial coverage is not fully sufficient to guide the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it creates a network box under a parent node, with a specific verb and resource. It distinguishes itself from sibling tools like create_node by specifying 'network box' and 'group box in network editor'. The scope is clear 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for grouping nodes in the network editor, but provides no explicit guidance on when to use it versus alternatives. It does not mention exclusions or preferred use cases relative to other tools. The usage context is inferable but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It clearly declares 'READ_ONLY' and discloses a key behavioral constraint: 'max_data limits data summaries' and 'does not return unbounded record content'. This provides useful safety/expectation-setting, though it doesn't cover all edge cases (e.g., object-not-found 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences front-loading the core purpose, then providing a specific parameter limitation. No redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query tool with no output schema, the description gives the essentials: purpose, method, and a key limitation. However, it lacks detail on the return format, error behavior, or how this tool fits among the many DOP-related siblings (e.g., get_dop_field, get_dop_relationships). This is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero parameter descriptions, and the description only explains 'max_data' (limits the number of data summaries). The other parameters (ctx, dop_path, object_name) are left to name-inference, which is fairly self-evident but not explicitly clarified. The description adds some value for max_data but does not fully compensate for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('查询'/'query') and resource ('单个 DOP object'/'single DOP object'), and mentions the underlying method 'findObject'. This clearly distinguishes it from siblings like 'list_dop_objects' (multiple objects) and 'get_dop_field' (a specific field).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying a single DOP object, but it does not explicitly discuss when to prefer this tool over alternatives, nor any exclusions. The note about 'not returning unbounded record content' is a limitation, 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.
- 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 states READ_ONLY, details the return structure, and discloses that expression is None when absent. The mention of apply_response_cap adds a behavioral nuance even if not fully explained. This goes beyond the schema and gives useful 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose. It includes essential details (return format, None handling, response cap) in just a few lines without unnecessary fluff. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema and no annotations, the description covers the key context: read-only, return keys, expression behavior, and a response cap. It does not specify error handling or parameter semantics, but for this tool's simplicity, it is reasonably complete. The missing parameter details are a minor gap given the tool's straightforward nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 does not explain the meaning or format of ctx, path, or parameter. It only mentions 'parm' in a generic sense. This leaves significant ambiguity about how to construct the path or what ctx refers to, especially for an agent unfamiliar with the Houdini context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads the current value, type, expression, and time dependency of a parameter. The verb '读取' (read) and resource 'parm' are specific, distinguishing it from mutation tools like set_parameter and more focused tools like get_expression.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing what it reads and noting READ_ONLY, but does not explicitly compare with alternatives like get_expression or set_parameter. There is no direct 'use when' or 'when not to use' guidance, though the context of the return value provides some implicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses that the operation is NO_UNDO, returns a structured error on out-of-bounds access, and passes through server-side 'apply_response_cap'. This goes beyond a bare minimum by revealing error behavior and side-effect constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and every sentence adds value: purpose, key parameters, error behavior, and response capping. No filler or repetition exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description is not fully complete. It lacks explanations for 'ctx' and 'node_path', and does not describe the return structure or format. While it covers error behavior and response limits, key context is missing for an agent to operate confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 clarifies 'prim_index' as the target and 'names' as an optional filter, but it does not explain 'ctx' or 'node_path'. Partial compensation is provided, leaving two parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries intrinsics for a specified prim_index, using the verb '查询' (query) and naming the specific resource. It distinguishes itself from sibling tools by focusing on intrinsics and adding contextual flags like 'add-geometry-export-and-measure' and 'NO_UNDO'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through '仅查询' (only query) and mentions optional subset filtering with 'names', but it does not explicitly state when to use this tool versus alternatives or provide exclusions. Usage context is inferred rather than directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses read-only status, bounded queries (performance safety), and server-side response capping via 'apply_response_cap'. This goes beyond a simple 'get info' description, though it does not detail error behavior. It adds meaningful 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and each sentence adds value: the first defines the tool, the second specifies return values and safety/response cap. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity metadata getter with two parameters and no output schema, the description lists the return fields and mentions response capping, which is important context. It lacks error-handling details, but overall provides adequate context for a metadata retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 meaning of 'ctx' or 'dop_path'. The parameter names give some inference (dop_path is a path to a DOP node, ctx likely a context), but the description provides no explicit semantics, leaving a significant gap for a two-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool '读取 DOP simulation 元数据' (read DOP simulation metadata) and lists specific return fields (frame/time/timestep/object_count). This distinguishes it from siblings like get_dop_field (which returns a specific field) and get_dop_object (which returns object details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies safe, bounded usage ('只使用有界 DopSimulation 查询') and read-only operation, but does not explicitly state when to use this tool versus alternatives or provide exclusions. It offers context but lacks direct 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, the description carries the burden of behavioral disclosure. It mentions the operation is 'MUTATING' and describes the underlying implementation (Parm.set(Parm)/setExpression()), plus notes that responses go through 'apply_response_cap'. However, it does not disclose side effects, reversibility, or required permissions, leaving gaps in 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with the core purpose front-loaded in the first sentence. Every sentence adds meaningful information (purpose, method, parameter format, response cap) without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 3 parameters and no output schema, so the description provides the essential purpose, parameter format, and a note on response handling. However, the 'ctx' parameter is left unexplained, and return values/error behavior are not mentioned, leaving some contextual gaps for an agent to fully invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage). The description explains the format for source and target ('node_path.parm_name') but does not explain 'ctx'. This partially compensates for the schema gap but leaves one parameter undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '建立 parm 之间的真实引用' (establish real references between parms). It specifies the method (Parm.set(Parm)/setExpression()) and distinguishes itself from alternatives by explicitly rejecting channel aliases ('不用 channel alias 冒充').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context by indicating this is for creating cross-parm references and advises against using channel aliases as a substitute. However, it does not explicitly name alternative tools (e.g., set_expression) or state when not to use this tool, so guidance is present but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explicitly states READ_ONLY, validation behavior, output fields (path/name/node_type/category), stable sorting by path, and response cap. This is rich behavioral disclosure beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with purpose and read-only status. It efficiently packs validation, output format, and sorting. However, it includes the cryptic internal identifier 'add-scene-context-selection-materials' which adds noise without clear value, so it is not a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool, the description provides useful details: validation, output fields, sorting, and response cap. It lacks an explanation of the ctx parameter, but the overall behavior and return shape are sufficiently described. Given no output schema or annotations, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It clarifies that 'parent' refers to parent_path, but it does not explain the required ctx parameter at all. The description adds minimal meaning beyond the schema, leaving a key parameter undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the task: enumerate material nodes under a parent. It uses a specific verb '枚举' (enumerate) and resource '材质节点' (material nodes), which is clear. However, it does not explicitly differentiate from sibling tools like list_material_types, so it misses the full sibling differentiation criterion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that the parent must exist and that childTypeCategory must be Sop, providing a clear prerequisite. It also indicates READ_ONLY, but it does not mention alternatives or when not to use it. This is clear context with no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses important behavioral traits: the rendering path can be redirected to capture_pane_screenshot under certain conditions, karma engines require consent_token, and the return value is a structured dict rather than a string. These are non-obvious behaviors that help the agent anticipate 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized but structurally disjointed. It starts with a prominent Chinese 'IMPORTANT' note, then a one-line English purpose, and a return-type sentence. Each part has value, but the mix of languages and abrupt topic shifts makes it less clean. It could be better organized without losing content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and no output schema, the description covers the core purpose, return type, and environment-specific redirect behavior. However, it leaves gaps: render_path is not explained, return keys are listed but not elaborated, and no examples are given. It references an external docstring for additional background, which is a slight completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning to several parameters: 'specific camera path' maps to camera_path, mentions opengl renderer (render_engine), karma_cpu/karma_xpu (karma_engine), and consent_token. However, render_path is not mentioned, and parameter value formats/defaults are left to the schema. It partially compensates for the lack of schema descriptions but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Purpose is clearly stated: 'Render from a specific camera path in the Houdini scene.' This is a specific verb+resource combination. It also differentiates from sibling render_single_view by explicitly noting that it returns a structured dict instead of a string, making the tool's unique role clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is provided: rendering from a specific camera path. The description also gives environment-specific guidance (H21 lacking OGL 3.3) and warns that karma_cpu/xpu need consent_token, implying when to adjust engine/token usage. It references render_single_view for dict-vs-str background, which hints at alternative selection criteria.
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 and effectively discloses key side effects: cache clearing/rebuilding is not HIP-undoable, and permission failures return structured warnings. It also mentions the force-reset gating conditions, adding transparency about what triggers the destructive path. However, it does not fully explain consequences like losing current simulation state in general terms.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly-packed sentences; the first states purpose and the second details procedural and side-effect behavior. No wasted words, and the structure front-loads the essential verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 covers behavior, side effects, and failure modes. It could be more complete by explaining success indicators and what 'owned simulation' means, but it is largely sufficient for an agent to invoke safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description only implicitly covers reset_frame via 'move to reset frame'. The required parameters ctx and dop_path are not explained, leaving the agent to guess their intended values. A DOP reset tool's key identifiers deserve explicit mention.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Timeline-first reset of DOP simulation', a specific verb and resource that clearly distinguishes the tool from siblings like step_simulation or get_dop_object. It also names the module and NO_UNDO flag, reinforcing the operation's 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing the reset procedure, but it does not explicitly state when to choose this over alternatives or provide any exclusions. Sibling tools like step_simulation are not referenced, so an agent must 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavioral details beyond any annotation (which are absent): input validation (accepts int/float, rejects bool/NaN/inf), sub-frame preservation, exception handling (degrading to error dict), and undo behavior (NO_UNDO_COMMANDS with batch dispatcher closing undo segments). This is thorough for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense yet efficient, with each sentence providing unique information: purpose, parameter validation, error behavior, and undo mechanics. It is front-loaded and contains no filler, making it ideal for agent consumption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description thoroughly covers validation, error handling, and undo behavior, it omits the return value (no output schema exists) and does not explain the 'ctx' parameter. These gaps leave an agent uncertain about the operation's result and the required context, preventing fully safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to the 'frame' parameter, explaining accepted types and validation, which is essential since the schema declares it as string. However, the 'ctx' parameter is not explained at all, leaving its purpose and accepted values undocumented. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: setting the current frame in Houdini. It distinguishes itself from sibling tools like get_frame and set_frame_range by explicitly focusing on the current frame, with additional context about runtime timeline writes and no-undo behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about runtime timeline writes and no-undo but does not explicitly state when to use this tool versus alternatives like set_frame_range or playbar_control. No exclusions or alternative tool references are given, leaving the agent to infer the appropriate use case.
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 structured annotations, the description carries the full burden and does well: it discloses READ_ONLY safety, explicit encoding modes (utf8/base64), and the internal use of binaryContents() as the authoritative raw byte source for pagination. It also notes the response passes through apply_response_cap, giving the agent a clearer model 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary purpose. Every sentence adds value: the encoding constraint, the pagination truth source, and the response cap handling. No filler or redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains core behavior but has clear gaps: it does not describe the return format (no output schema), parameter semantics for offset/limit, or any error/edge cases. For a tool with 5 parameters and no structured annotations, more detail would be needed to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description only meaningfully explains the 'encoding' parameter (utf8/base64 and its relationship to binaryContents). The remaining parameters (limit, offset, section, node_type) are left undocumented beyond their names and types, so the description does not compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '分页读取 section 正文' (paged reading of section content), which clearly identifies the verb (read), resource (section content), and unique pagination aspect. It distinguishes itself from sibling tools like set_hda_section_content (write operation) and get_hda_sections (list sections).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating 'paged reading of section body' and marks it as READ_ONLY, which helps an agent understand it is for reading content. However, it does not explicitly mention when to choose this tool over alternatives or provide exclusionary guidance, so it relies on 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does this exceptionally well by explaining defaults for all optional parameters, the side effect of force_cook (calls node.cook(force=True)), the compact return structure, and error propagation (throws ValueError, bridge passes through error envelope). This goes well beyond a generic 'get' 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a heading, bullet-pointed parameter list, and separate sections for return format and error behavior. Every sentence adds value, 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers parameters and error behavior well, but it does not enumerate the full (non-compact) return fields, instead referencing an internal function '_node_info.get_node_info' which is inaccessible to the agent. Without an output schema, this leaves the return format incomplete. Additionally, there is no usage context relative to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description compensates by explaining every parameter's meaning and default value: node_path, include_errors, force_cook, include_input_details, and compact. This adds essential meaning beyond the bare schema, making parameter usage unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '获取节点的详细信息' (get detailed information of a node), providing a specific verb and resource. However, it does not explicitly distinguish this tool from sibling tools like get_geometry_info or explain_node, so the purpose is clear but lacks 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/5Does 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 only describes parameters and return behavior, leaving the agent to infer usage context without any exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important behaviors: returning only existing and data-safe parms, rejecting script/callback/command/executable types, and applying a response cap. This adds meaningful context beyond a simple 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, using code formatting and a reference to design.md, with no extraneous words. Every sentence adds specific behavioral or scope information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool's behavior is well covered: what it reads, what it filters, and the safety cap. It does not describe return format or error handling, but for a read tool with a simple schema, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description references node_path and indicates it is the target node for reading settings, but does not explain the path format or expected structure. Since schema coverage is 0% and this is the only parameter, more detail would be helpful, but the reference provides some meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads whitelisted parm values for a given node_path, with a specific verb and resource. It distinguishes itself from siblings like set_render_settings (write operation) and get_parameter (generic) by narrowing to render settings and explicit renderer 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading render settings but does not explicitly state when to use this over alternatives or when not to use it. It mentions filtering behavior but no direct comparison to sibling 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?
No annotations are provided, so the description carries the full burden. It discloses significant behavioral traits: the fork-render-policy redirect under specific hardware/software conditions, the consent_token requirement for karma engines, and that it returns a dict rather than a string. This goes beyond basic schemas and adds concrete environmental 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, front-loading a critical note before stating the core purpose. It contains a mixed-language structure and a slightly verbose redirect explanation, but each sentence contributes useful information without excessive padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, return type, and edge-case behavior, but lacks an output schema and detailed parameter narratives. It references render_single_view for Pydantic background, which offloads some explanation. For a tool with four parameters and no output schema, it is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 by mentioning karma_engine values (karma_cpu/karma_xpu) and render_engine (opengl), but it doesn't explain render_path or fully elaborate on consent_token semantics. Only about half the parameters receive meaningful contextual explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 a structured result dict.' It specifies the resource (Houdini) and scope (4 canonical views), distinguishing it from render_single_view by count. The return type is also clarified, resolving ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides conditional usage guidance: in environments without OGL 3.3, the opengl renderer is redirected to capture_pane_screenshot, and karma engines require a consent_token. It also mentions the legacy command name for backward compatibility. While it doesn't explicitly say when to prefer this over alternatives, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 explicitly mentions NO_UNDO (not entering the undo group), 'only UI/view write', whitelist token constraints, and response cap handling. This is substantial transparency, though it omits error handling or exact return details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and packs essential behavioral constraints into a few sentences without redundant information. Each sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with three string parameters and no output schema, the description covers purpose, key constraints, and side effects. It lacks usage context and error behavior, but the simplicity of the tool and the disclosed constraints make it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only parameter names with 0% coverage. The description adds that display_set and shaded_mode must be whitelist tokens and that reflective setters/non-existent enums are rejected, but it doesn't explain the meaning of each parameter or provide allowed values. ctx remains entirely unexplained. It partially compensates but leaves significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the viewport display set and shaded mode, using a specific verb and resource. This distinguishes it from sibling tools like set_viewport_camera and set_viewport_direction, which target different aspects of viewport control.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly say when to use this tool versus alternatives like set_viewport_camera or set_viewport_renderer. It implies usage for viewport display via the purpose, but lacks exclusions, prerequisites, or alternative comparisons.
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 of behavioral disclosure. It explicitly warns that the operation has disk and registry side effects and cannot be undone via Houdini undo. This is valuable and goes beyond a generic 'uninstall' statement, though it does not describe return values or error 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action and immediately warning about side effects and undo behavior. Every word earns its place; no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema). The description covers purpose, side effects, and undo limitation, which is sufficient for an agent to decide and invoke it. It lacks details like whether confirmation is needed or what happens on failure, but these are not critical for a basic uninstall tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes only one parameter, file_path, with no description. The description does not explicitly explain the parameter, but its meaning is inferable from the tool name and purpose (the HDA to uninstall). Since schema coverage is 0%, the description provides minimal added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: uninstalling an HDA library. The verb '卸载' (uninstall) plus the resource 'HDA 库' is specific and distinguishes it from siblings like hda_install, reload_hda, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied by the name and description: use this to uninstall an HDA. However, there is no explicit guidance on when to choose this over alternatives, nor any exclusions or prerequisites. 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of behavioral disclosure. It explains important edge cases: save_path=None avoids disk writes and uses QBuffer for size estimation, fit_contents=True triggers alignment via homeAll()/home(), responses go through apply_response_cap, and environments without PySide return a _warning dict. These details go well beyond a simple statement of 'capture screenshot'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, and subsequent sentences each add essential behavioral details without redundancy. The line breaks improve readability, and no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderate complexity with 4 parameters and no output schema, so the description must explain return values. It mentions apply_response_cap and the _warning dict fallback, but does not describe the success response structure (e.g., image data, file path, or size_bytes format). Additionally, the 'ctx' parameter remains unexplained, making the description incomplete for fully invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 three of four parameters: pane_type_name must be a valid hou.paneTabType property, save_path=None indicates no disk persistence, and fit_contents=True controls view alignment. However, it omits any explanation for the 'ctx' parameter, leaving its purpose and format unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures a screenshot of a specified pane type, listing examples (NetworkEditor, SceneViewer, etc.) and explicitly mentions 30 types. This distinguishes it from sibling capture tools like capture_multiple_panes, which captures multiple panes. The verb 'capture' and resource 'pane' are 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives parameter behaviors but does not provide guidance on when to use this tool versus alternatives such as capture_multiple_panes or render_* tools. There is no explicit 'when not to use' or comparison to sibling tools, leaving the selection criteria implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and delivers substantial detail: it explains the return structure, that parameters are filtered to a whitelist with a stable key set, and that texture_references are determined by eval values matching known texture suffixes. This goes beyond a simple 'get' and informs the agent of important filtering 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: the first sentence states the purpose, followed by a breakdown of the return dict. Every clause earns its place, with no repetition or unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
In the absence of an output schema, the description thoroughly explains the return value and its filtering logic, which is good. However, it does not cover usage context (when to choose this tool) or parameter semantics, leaving minor gaps for a read-only tool with two obvious-ish parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for its two parameters (ctx and material_path), and the description does not compensate by explaining them. material_path is fairly self-explanatory from the tool name, but ctx remains unclear, and the description does not address parameter meaning or format at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '获取' (get) and a specific resource '材质节点的详细信息' (detailed info of material node), and enumerates the exact return fields (path/type/name/parameters/texture_references), clearly distinguishing it from sibling tools like get_node_info or get_geometry_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: if you need material node details with filtered parameters and texture references, this is the tool. However, it does not explicitly state when to use it over alternatives or mention any exclusions or prerequisites, so guidance is only implicit.
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 carries the burden and does an excellent job: discloses READ_ONLY, acceptable categories, stable sorting, return fields, use of nameWithCategory(), error handling for unsupported categories, and server-side apply_response_cap. This goes beyond basic expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured: purpose and READ_ONLY first, then category constraints and return details, then error handling and response cap. Every sentence adds value, though the technical references could be clearer for less Houdini-savvy agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple enumeration tool with no output schema, the description covers purpose, return format, sorting, error handling, and response cap. Missing explanation of the `ctx` parameter and exact format of node_type, but otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 thoroughly explains `category` (only Vop/Shop, unknown returns unsupported_category), but the required `ctx` parameter is left unexplained. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enumerates node types under the material category, with specific verbs and resource. It distinguishes itself from siblings like list_node_types and list_cop_node_types by scoping to material categories (Vop/Shop).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied through the material category scope, but no explicit guidance is given on when to use this tool instead of list_node_types or list_cop_node_types. There are no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the response structure (parent_path/count/nodes) and documents an edge case: unknown ROP types are still listed with renderer="". It also mentions apply_response_cap. However, it does not state whether the listing is read-only or recursive, which are minor gaps for an enumeration 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it front-loads the purpose, then uses bullet points to detail response fields and notable behavior. Every sentence contributes useful information without 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter enumeration tool, the description is largely complete: it states the response fields, handles the unknown-type edge case, and mentions response cap. Minor omissions include whether the listing is direct children or recursive, and lack of an explicit read-only hint, but these do not significantly impair usability given the tool's simplicity and the presence of an output description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description only references parent_path in passing ('under parent_path') without explaining its format, valid values, or default behavior. For a tool with a single parameter, the description should at least clarify that parent_path is a Houdini node path, especially given the schema provides no description. This lack of compensation for low schema coverage results in weak parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enumerates ROP nodes (ifd, opengl, karmarender) under a specified parent_path, using the specific verb '枚举' (enumerate). This distinguishes it from sibling tools like list_dop_objects or list_cop_node_types by focusing specifically on render nodes and including the renderer field.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to list categorizable ROP nodes under a path. It does not explicitly mention alternatives or exclusions, but the specificity to ROP nodes and renderer types makes its use case evident relative to generic listing tools like list_children or find_nodes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals key behaviors: homeAll() invocation, disk save behavior with QBuffer estimation for size_bytes, and response cap. However, it stops short of explicitly noting read-only nature or all side effects, though homeAll is 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no wasted words. The main action is front-loaded, and each sentence provides meaningful implementation detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers key operational aspects well but omits return value details (beyond size_bytes) and the meaning of ctx. The fit_contents type mismatch (string vs boolean) is not addressed. For a 4-param tool with no output schema, it is moderately complete but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 node_path (must exist), fit_contents (triggers homeAll), and save_path (None means no disk write, uses QBuffer). ctx is not explained, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: locate the node's NetworkEditor pane, cd to the node, and take a screenshot. This specific verb+resource description distinguishes it from other rendering/screenshot tools like render_single_view or capture_pane_screenshot by focusing specifically on node network rendering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides operational guidelines (node_path must exist, fit_contents triggers homeAll, save_path=None behavior) but does not explicitly state when to use this tool versus alternatives. It doesn't mention 'use this instead of X' or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the return value format (dict with path/old_order/new_order/success) and the error behavior (throws ValueError on missing node, no silent swallowing). It also reveals the deprecated alias 'order' and the precedence rule. This adds non-obvious behavioral context beyond the operation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening statement, bulleted parameter explanations, and a separate return/error note. It is concise yet thorough, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers return values and error behavior, and gives a concrete example. However, it leaves ambiguity about whether new_order must be a complete permutation of all input indices or can be a partial reorder, and it does not describe the 'ctx' parameter or constraints on index validity. Given the tool's moderate complexity, these are gaps that could lead to incorrect usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the semantics of node_path, new_order, and order in detail, including the mapping example and empty-list meaning, compensating for the 0% schema description coverage. However, it omits any explanation of the required 'ctx' parameter, and the schema types new_order/order as strings while the description calls them lists, creating ambiguity about the expected input format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '重新排列节点的输入顺序' (Reorder the input order of a node), which is a specific verb+resource. It further explains the semantics of new_order with an example ([2,0,1]), distinguishing it from generic connect/disconnect operations. This is a clear, non-tautological purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context by explaining the parameter meanings, including the empty-list behavior (disconnect all) and the precedence rule between new_order and order. However, it does not explicitly mention when to use this tool versus alternatives like connect_nodes or disconnect_node_input, nor does it state any prerequisites. So it's clear context but lacks exclusions.
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 carries the burden and does an excellent job. It discloses the mutating nature, undoability, language validation behavior (hscript/python with status=error for invalid values), and its classification as not read-only/no-undo. This gives agents essential behavioral context 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core action. It uses structured formatting for the language parameter and includes essential caveats in three sentences. Minor noise includes the cryptic 'PR 19' reference, but overall it is well-organized and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers mutating behavior, undo, language validation, and undo group policy, which is good. However, it does not explain return values or success/error response structure (e.g., what a typical output looks like). Given the lack of an output schema, this is a notable gap for an agent to infer results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 explains the 'language' parameter's allowed values and mapping to hou.exprLanguage. Other key parameters (ctx, path, parameter, expression) remain unexplained, leaving the agent to guess their meaning. This is insufficient for a 5-param tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '写入 parm 表达式' (write parm expression), specifying a specific verb and resource. It distinguishes from siblings like get_expression (read) and set_parameter (set value) by focusing on expression writing, with additional context about persistence and undoability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this command is for parameter channel data writes and is not read-only or no-undo. It implicitly differentiates from read tools like get_expression and other mutating tools by mentioning undo group policy. However, it does not explicitly name alternative tools or provide 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
在无注释的情况下，详细披露了原子性（任一无效则整调用失败、零写入）、undo分组、返回set_count/requested以及错误截断机制，使代理能清楚预期调用效果。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
总体简洁，关键信息集中。但'PR 19'这类未解释的引用对代理可能无帮助，略增加理解成本。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
覆盖了原子性、undo、返回值等关键行为，但缺失输入序列化方式和ctx说明，且存在schema类型矛盾，对无输出schema的工具而言完整性有缺口。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
keyframes参数描述了list及必填字段，但schema定义keyframes为string，两者存在明确类型矛盾；ctx参数未做任何说明，且无schema描述，导致代理难以可靠构造参数。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
描述明确说明是批量关键帧写入，且提及场景写、可undo等，与set_keyframe等兄弟工具在功能和规模上有明显区分。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
描述了批量写入的适用场景（批量关键帧），但未明确给出与set_keyframe的对比或排除性说明。不过'批量'本身就隐含了使用情境。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels: it discloses the use of temporary .vfl files, subprocess.run with timeout=10, shell=False, a 64KB output cap, finally-cleanup of source and artifacts, and a detailed return structure. It also specifies what it does NOT do (no exec/eval/compile/hscript), giving the agent a clear safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence adds critical information: purpose, implementation details, exclusions, timeouts, cleanup, return type, and response handling. It is efficiently structured with clear separations, no filler, and front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and absence of an output schema, the description provides a thorough specification including the return shape, safety constraints, and resource limits. It does not fully clarify the semantics of the 'ctx' parameter or the meaning of diagnostic severity levels, but overall it is sufficiently complete for an agent to invoke the tool correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain the meaning or expected format of the three parameters (ctx, code, context). While 'code' is inferable, 'ctx' and 'context' are ambiguous. The description mentions a 'context' field in the return value but not how the parameter should be set. The description fails to compensate for the schema's lack of coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compiles VEX using the real HFS/bin/vcc compiler, which is the core purpose of validation. It explicitly contrasts itself with execution tools by forbidding exec/eval/hscript and stating it does not execute compiled artifacts, thereby distinguishing it from siblings like execute_houdini_code or execute_hscript. The verb 'compile' and resource 'VEX' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for safe syntax checking without execution, and explicitly lists what it does NOT call (Python exec, hscript, etc.), which hints at when to use it. However, it does not explicitly state 'use this when you need to validate VEX without executing' or name alternative sibling tools. The 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides the essential behavior: connecting output to input, with 0-based index handling. However, it does not disclose whether existing connections are overwritten, whether cycles are prevented, or what error conditions apply, leaving some behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler: the core action, a prerequisite, and the index semantics. Every sentence adds necessary information and the structure is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Relative to the tool's simplicity, the description covers the main action, constraints, and index semantics. It lacks detail on return values or edge cases like replacing existing inputs, but the core operation is well-specified for an agent to invoke it correctly in typical scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must clarify parameters. It explains the role and indexing of input_index and output_index, and the from_path/to_path relationship is implicit in the main verb. It does not detail path formats, but that is likely a conventional concept.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Wire') and clearly identifies the resource being operated on: connecting one node's output to another node's input. It distinguishes this from sibling tools like disconnect_node_input 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit prerequisite: both nodes must live in the same network. It does not explicitly name alternatives or when-not-to-use, but the context is clear enough for an agent to understand this is the tool for establishing connections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, but the description discloses dual-path behavior (Point or None), the NO_UNDO trait, server-side apply_response_cap, and the exact fields returned for both cases. It lacks error/permission details, but is substantially 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with bullet points. Each line provides distinct, valuable information about parameters, return values, or behavior without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description appropriately specifies the exact return contract for both Point and None cases and notes the response cap. Minor omissions around ctx/node_path semantics and error handling prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds critical meaning for position (must be [x, y, z]) and max_distance (default 1.0, used as max_radius), but leaves ctx and node_path unexplained. With schema coverage at 0%, this is a partial compensation that leaves clear gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific operation, '最近点查询' (nearest point query), and specifies the return type 'Point | None'. It clearly distinguishes this from sibling geometry tools by focusing on spatial nearest-point search with distance constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage conditions: position must be [x, y, z], max_distance defaults to 1.0 and maps to geo.nearestPoint's max_radius. It does not explicitly discuss alternative tools or when not to use it, so it stops 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, the description carries the full burden. It discloses that it accepts either a SOP path or a geometry container (using its display SOP), which adds behavioral context. However, it does not explicitly state read-only nature, potential side effects (e.g., cooking), or error behavior. The verb 'summarize' implies safety but lacks explicit confirmation, leaving some 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence packs a dense list of output contents, and the second provides input flexibility and a use case. Front-loaded with the core purpose and immediately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the expected output (counts, bbox, attribute listings, groups), input flexibility, and the recommended use case. There is no output schema, so listing return categories is helpful. It does not cover error cases or performance implications, but given the tool's relative simplicity and clear scope, it is sufficiently complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, and the sole parameter 'path' is documented only by name and type. The description compensates by explaining that the path can be a SOP path or a geometry container, giving the agent clear guidance on what to pass. It adds semantic meaning beyond the schema, though it omits examples or exact path formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'summarize' and identifies the resource as 'a node's geometry', listing exact contents (counts, bounding box, attributes, groups). This clearly distinguishes it from sibling tools like get_bounding_box, get_groups, and get_geometry_data, making its unique purpose evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context for when to use the tool: 'verify what a network actually produced instead of judging from a render.' It does not explicitly name alternatives or state when-not-to-use, but the use case is well-defined and implies inspection rather than modification.
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?
由于没有 annotations，描述承担了行为披露的全部责任。它详细说明了自动降级行为：point_count 超过 max_points_for_full 时跳过 sample_points 和详细 attributes/groups，并解释了原因（避免大几何撑爆 MCP）。这提供了 schema 之外的宝贵行为上下文，但未提及是否只读（尽管从内容显然可推断），因此给予 4 分。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
描述结构清晰，首句点题，随后用列举方式说明返回内容，再描述降级行为，最后给出对比和适用场景。每一句都有实际价值，没有冗余或重复信息，在长度和信息密度之间取得了很好的平衡。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
工具没有输出 schema，描述列出了返回的核心数据（计数、bbox、attributes/groups 列表、属性采样）以及降级行为，足以让代理理解返回内容和执行成本。未给出 bbox 六元组的顺序等具体格式，但整体完整性较高，足以支持工具选择与调用决策。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema 描述覆盖率为 0%，描述为 sample_size（前 N 个点采样）和 max_points_for_full（降级阈值）补充了关键语义。但 ctx 和 node_path 仍未在描述中解释，尽管这两个参数名称相对直观。考虑到核心参数已说明，而通用上下文参数缺失，评分为 3。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
描述以明确动词'获取'和资源'几何节点的轻量级概要信息'开头，并枚举返回内容（point/primitive/vertex 计数、bbox 6 元、attributes/groups 列表、采样点）。同时通过与 get_geometry_info 和 get_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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
提供了明确适用场景'先看看节点生成了什么规模的几何'，并对比 get_geometry_info（更轻）和 get_geometry_data（更结构化）来指导选择。虽然未明确说明'何时不用'，但替代关系与典型场景已足够清晰，属于良好但不完美的用法指导。
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 fetches from a cached pair and pretty-prints the diff, implying a read-only operation. However, it does not reveal edge cases such as behavior when no cached diff exists or potential errors, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, with the primary action front-loaded. The second sentence adds valuable context about the server-side caching and the purpose for the agent. Every sentence earns its place, and there is no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description adequately explains what the tool does and why it exists. It references related concepts (execute_code, serialize_scene_state) that are part of the sibling tool ecosystem. However, it could be slightly more complete by mentioning prerequisite conditions or error scenarios, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly avoids adding parameter details that don't exist, and the schema coverage is trivially 100%. No additional semantic info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and identifies a precise resource (the last execute_code scene diff). It clearly distinguishes itself from sibling tools by referencing the capture_diff=True mechanism and the caching of serialize_scene_state pairs, making the tool's unique function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the intended use case: to verify what a privileged execution changed in the scene. This provides clear context for when to use the tool. However, it does not explicitly mention when not to use it or suggest alternatives, though the specialized nature makes the context sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It discloses bounded BFS execution, exact semantics of max_depth and max_nodes, path-based visited deduplication, handling of cycles/shared ancestors, and server-side response cap. It also reports truncation and truncation_reason, which is more transparent than most tool descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and well-structured, front-loading the core purpose and then using bullets and code spans to explain parameters, return fields, and dedup behavior. Every sentence adds value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (BFS with limits, dedup, truncation) and has no output schema. The description covers return fields, truncation, and dedup, which is essential. However, it leaves ctx unexplained and does not describe the shape or semantics of nodes/edges beyond their names, nor error scenarios. These gaps prevent a perfect score, but most critical operational details are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 max_depth and max_nodes in detail (including the special case 0 = only parent_path) and implicitly defines parent_path via the phrase 'parent 节点的网络拓扑'. However, ctx is entirely unexplained, and the return structure of nodes/edges is only listed by name without further semantics. Thus compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it performs a bounded BFS traversal of the parent node's network topology and explicitly marks it as READ_ONLY. It clearly distinguishes this from sibling tools like list_children or find_nodes by describing the traversal algorithm (BFS, depth/node limits) and specifying return fields. The verb and resource are specific and accurate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for traversing a node's network topology with configurable depth and node budget, and the cryptic 'add-scene-context-selection-materials' may hint at a use case. However, it does not explicitly state when to use this versus list_children, find_nodes, or other related tools, nor does it mention any exclusions or 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?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly marks the operation as READ_ONLY, specifies that short/unknown/ambiguous names return a stable error, and mentions response handling via apply_response_cap. This adds meaningful context beyond the schema, though the exact metadata contents are not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every clause adds value. It is dense yet readable, with no redundant wording or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers input constraints and error behavior well. However, it does not describe the structure or content of the returned definition metadata, which would be important without an output schema. This is a notable gap for an agent deciding whether the tool returns what it needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It does: it explains that node_type must be a full category name from hou.NodeType.nameWithCategory(), provides an example (Sop/box), and warns against short/unknown/ambiguous names. This goes far beyond the schema's 'Node Type' string field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '读取 definition metadata' (read definition metadata), which is a specific verb+resource. This clearly distinguishes it from sibling tools like hda_list (listing HDAs) and get_hda_sections (getting sections). 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying the required format for node_type, but it does not explicitly state when to use this tool over alternatives. No sibling tools are mentioned as alternatives or exclusions. The input constraint is helpful but does not provide full usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and steps up by explicitly stating '只查询 registry，不触发 COP cook 或写入' (only queries the registry, does not trigger COP cook or writes) and labeling itself READ_ONLY. This adds valuable behavioral context about side effects, though it does not describe return format or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences. The first sentence states the purpose and read-only nature; the second covers the default, exclusions, and safety. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only enumeration tool, the description covers the key aspects: purpose, safe behavior, and parameter guidance. It lacks details on return values and ctx parameter, but given the simple list operation and no output schema, these are not critical gaps. The overall context is sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does explain the 'category' parameter, including its default and the invalid legacy value 'Cop2', but it leaves the required 'ctx' parameter completely unexplained. This partial compensation yields a mid-range score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '枚举 Copernicus node type registry' (enumerate the Copernicus node type registry), with a specific verb and resource. It distinguishes itself from the sibling list_node_types by focusing on Copernicus-specific node types and mentions 'add-cops-tools' as a contextual qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance on the 'category' parameter: the default is 'Cop' (H21+ Copernicus) and 'Cop2' is explicitly rejected as legacy. However, it does not mention alternative tools or explicitly state when to use this tool instead of siblings, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and delivers rich behavioral context: MUTATING, operations in a single undo group, failure destroys semi-finished products, unsupported when adapter unavailable, and response passes through apply_response_cap. These are valuable disclosures beyond what annotations would provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded with purpose, and uses structured line breaks to separate behavioral notes. Every sentence conveys distinct information without redundancy, making it appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is strong on behavior (mutation, undo, failure) but weak on parameter semantics for most inputs and does not explicitly describe return values beyond the response cap mention. For a 6-parameter tool with no output schema and no annotations, this leaves notable gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only documents import_type accepted values ('reference'/'sublayer'). With 0% schema description coverage and 6 parameters, the description fails to explain ctx, parent_path, file_path, node_name, and prim_path. This is insufficient compensation for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create Reference or Sublayer LOP' with the specific node type 'add-usd-solaris-tools' and marks it as MUTATING. This provides a specific verb, resource, and scope, clearly distinguishing it from generic node creation tools like create_lop_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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (creating Reference/Sublayer LOPs) and explicitly states an exclusion ('does not directly modify stage layer stack'). However, it does not name alternative tools or provide explicit when-not-to-use guidance beyond that limitation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses the key behavioral trait of being read-only. It also explains the effect of include_params on node contents, providing concrete output details. It doesn't mention max_depth behavior or potential performance impacts, but for a simple serialization 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and efficient, using two short sentences to convey the purpose, read-only nature, and parameter behavior. It is well-structured and front-loaded with the core action, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three optional parameters and no output schema, the description provides sufficient context: it specifies the return type (dict), the recursive nature, and the structure of nodes based on include_params. It doesn't explain max_depth or error scenarios, but given the simplicity of the tool and that the output schema is absent, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 explicitly explains include_params behavior, but does not elaborate on max_depth or root_path beyond their names, which are fairly self-explanatory. This partial compensation is insufficient to fully cover all three parameters, but it adds meaningful value for one key flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: recursively serializing the node tree under root_path into a dict. It specifies the output structure and distinguishes this from simple listing tools by emphasizing structural serialization for comparison/documentation, differentiating it from siblings like get_scene_info or get_network_overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating it is a read-only operation intended for scene structure comparison and document generation. It does not explicitly name alternative tools or exclusion criteria, but the use cases are well-defined, which gives the agent a good sense of when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully discloses critical behaviors: atomicity, mutation, validation (only allowed keys and bool values), and that unknown keys cause rejection before any write. It also mentions the single undo group, which is valuable beyond normal expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary action, followed by concise, relevant details about validation and undo behavior. Every sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly covers the core behavior (atomicity, validation, undo), which is sufficient for a simple mutation tool. However, it omits details about the required parameters 'ctx' and 'node_path' and any return value, making it slightly incomplete for an agent without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for the 'flags' parameter by listing allowed keys and value types, but does not clarify 'ctx' or 'node_path'. With 0% schema coverage, this partial compensation leaves gaps, though the key parameter is well explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('atomically set Copernicus whitelist flags') and specifies the exact resource (Copernicus) and the mutation type (MUTATING). It distinguishes itself from siblings like 'set_node_flags' by clearly targeting Copernicus flags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explicitly naming 'Copernicus whitelist flags' and defining the valid flag keys, but it does not explicitly state when to choose this tool over alternatives like 'set_node_flags' or provide any exclusion criteria. The context is clear but not fully directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses critical behaviors: mutating operation, single undo group, failure destroys half-finished work, does not call cooked node.geometry() write methods, and server-side response cap. This is rich, specific context beyond typical mutation tool descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a summary line followed by bullet points. Each sentence adds meaningful behavioral or parameter details, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 annotations or output schema, the description covers key operational context: mutation, undo grouping, failure cleanup, and accepted parameter values. However, it omits success return behavior and explicit explanations for several parameters, leaving minor gaps for a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 explicitly explains attrib_type accepted values (float/int/string/vector) and implies name/value semantics as attribute name and value. However, other parameters like ctx, node_name, and node_path remain unexplained, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an Attribute Create SOP with class=detail, identifying the specific node type and scope. This distinguishes it from generic node creation tools like create_node and create_wrangle, and the resource is clearly specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming the node type, but does not explicitly mention when to use this tool versus alternatives. No exclusions or direct comparisons to sibling tools like create_node or set_parameter are provided, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses validation requirements (non-empty strings, finite floats), the exact Houdini API calls used, and error behavior (status=error, no write). It also notes undoability. However, it doesn't detail the success return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight paragraphs, the first sentence states purpose and key properties, second provides validation and implementation. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-param tool with no output schema, it covers validation, operation, undoability, and error status. Missing success return spec and arcane 'PR 19' reference are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, and the description compensates by constraining path/parameter to non-empty strings and frame/value to finite floats, and explaining value conversion via hou.Keyframe. Ctx remains unexplained, so not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'single keyframe write' with a specific verb and resource, distinguishing it from the sibling set_keyframes tool. It also notes it's scene-scoped and undoable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a single keyframe but does not explicitly compare to alternatives like set_keyframes or state when to use this over other parameter-set tools. No exclusions listed.
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?
Since annotations are absent, the description carries full behavioral disclosure. It explicitly states the tool is a 'UI/view write' that does NOT enter the undo group, and it reveals error behavior (camera_not_found for invalid paths). It also mentions the response passes through server-side apply_response_cap. These details go beyond typical expectations and give the agent a clear picture of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three short sentences that convey purpose, constraints, and behavior. It is front-loaded with the main action and uses formatting (code spans, bold) to highlight key terms. Every sentence adds value, making it compact and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool, the description covers the essential context: what it does, error handling, undo behavior, and a note on response processing. The main omission is the return value, but since no output schema exists, a brief mention would have helped. Overall, it's fairly complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for the two parameters (ctx, camera_path). The description adds meaning for camera_path by specifying it must refer to an existing node, but ctx remains unexplained. With 0% schema coverage, the description partially compensates but does not fully clarify both parameters, leaving a noticeable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '设置 SceneViewer viewport camera' (set SceneViewer viewport camera), with a specific verb and resource. It also includes 'NO_UNDO' which distinguishes this as a viewport-control operation separate from other setter tools like set_viewport_display or set_viewport_renderer. The purposes 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage constraints: camera_path must be an existing node, and invalid paths return camera_not_found. It also clarifies this is a UI/view write that does not enter the undo group. However, it does not explicitly mention when to use this tool versus alternatives like set_viewport_direction or frame_selection. The usage context is implied rather than explicitly contrasted.
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. It discloses the re-cook behavior when validate=True and the inclusion of a validation report, which is meaningful 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The purpose is front-loaded, and the validation behavior is succinctly explained.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description covers the key return value (validation report) and default behavior. Minor omission: what happens if the path is invalid, but this does not detract significantly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning for 'vex_code' (the snippet) and 'validate' (default True with side effects). However, the 'path' parameter is not described, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States 'Replace the VEX snippet on an existing wrangle node' with a specific verb and resource. This clearly distinguishes it from siblings like get_wrangle_code (read) and create_wrangle (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly implies usage for existing wrangle nodes and describes the validation behavior. Does not explicitly name alternatives or exclusions, but the context is unambiguous.
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?
Although no annotations are provided, the description thoroughly discloses behavioral side effects: it changes the current frame, triggers dependency graph cooking, generates/replaces DOP cache, rejects frames <= 0, and does not enter the undo group. This level of detail fully compensates for missing annotations and gives the agent critical execution expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense. The first sentence states the purpose and key constraints, the second describes the mechanism, and the third discloses side effects. No filler or repetition; every sentence contributes meaningful information, and it is well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 rich behavioral disclosure, the description is nearly complete for agent decision-making. It covers what happens, side effects, and constraints. The only gaps are the undefined 'ctx' parameter and lack of explicit mention of return values, but these are not critical for a simulation-stepping tool that performs a state-changing action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to 'frames' (number of frames to advance, must be > 0) and implicitly links 'dop_path' to the DOP node being cooked. However, 'ctx' remains unexplained, and with schema coverage at 0%, the description only partially compensates. It improves clarity for two params but leaves a significant gap for the third.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: advancing a DOP simulation by a number of frames. It provides specific implementation details (hou.setTime + dop_node.cook) and explicitly distinguishes itself from merely setting the frame or cooking generically. The verb '推进' (advance) and resource 'DOP模拟' are 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context: advancing DOP simulations. However, it does not explicitly mention when to prefer this over alternatives like set_frame, cook_node, or reset_simulation, nor does it state exclusions or prerequisites. The guidance is implicit rather than explicit, earning a mid-range score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits beyond what annotations (none provided) would cover: it specifies the return dict contents and explicitly states that binding failures raise ValueError and will not be silently swallowed as success:True. This adds transparency about error handling and return behavior, though it does not mention permissions or side effects on existing assignments.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it opens with the main purpose, then lists parameter explanations in a clear, bullet-like format, and finishes with return and error behavior. Every sentence is informative and contributes to understanding the tool, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is comprehensive for a simple assignment tool. It covers the action, all relevant parameters (except ctx), the return dict contents, and error handling semantics. Since there is no output schema, the description provides the necessary return information, making it complete for the agent to invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only parameter names with no descriptions (0% coverage), so the description carries the full burden. It explains geometry_path and material_path as node paths, and gives detailed semantics for the 'group' parameter, including the None vs specific group behavior. However, the required 'ctx' parameter is not described at all, leaving a small gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: binding a material at material_path to a geometry node at geometry_path. The verb 'bind' and the specific resource paths make the purpose unambiguous, and it is distinct from sibling tools like list_materials or create_material.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool, including optional group binding behavior and the distinction between None and a specific group. However, it does not explicitly state when to use this tool over alternatives, such as set_parameters or other material-related tools, 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.
- Behavior5/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 mutation (MUTATING), the requirement that node_type exist in a probe, single undo group behavior, failure cleanup (destroys half-finished product), and that responses pass through apply_response_cap. This is strong behavioral disclosure 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, then provides essential behavioral details in just a few sentences. Every sentence adds meaningful information without fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the critical behavioral aspects (mutation, undo, failure cleanup, response cap) and the node_type constraint. It does not explain the format or meaning of ctx and parent_path, nor what the successful return value looks like, but for a creation tool with these constraints, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 valuable context for node_type (must exist in the probe), but provides no additional meaning for ctx, parent_path, or node_name. The parameter names are self-descriptive to a degree, but with no schema descriptions, this leaves gaps for required parameters like ctx and parent_path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb (create) and resource (LOP node), plus a key constraint: the node must be created under an editable LOP parent. It also references the add-usd-solaris-tools category and explicitly marks the operation as MUTATING, clearly distinguishing it from sibling tools like create_node 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this when creating a node under an editable LOP parent and when node_type must come from the hou.lopNodeTypeCategory() probe. It does not explicitly name alternatives or exclusion conditions, but the editable-parent restriction and reference to the LOP-specific probe imply when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does exceptionally well. It discloses the return format (list of objects with frame and value as floats), the no-int-truncation behavior, the empty-list case (returns keyframes=[]), and explicitly states it is read-only and will not modify the scene or parameters. This goes well beyond 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: the first sentence states the purpose, the second defines the return format and edge cases, and the third confirms side-effect-free operation. Every sentence adds value with no redundancy. It is appropriately sized for a simple read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, the description covers return values, edge cases, and side effects. However, the lack of parameter explanations is a notable gap because there is no output schema and the input schema is minimal. The description covers the tool's functional behavior but leaves parameter semantics incomplete, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 does not explain the meaning of ctx, path, or parameter. The description only mentions 'parm' (parameter) generically. While the tool name gives some hint, the parameter roles remain underspecified, making it hard for an agent to infer required values without additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('读取 parm 的全部关键帧') and resource (all keyframes of a parameter). It distinguishes itself from sibling keyframe tools like set_keyframe and delete_keyframe by emphasizing read-only behavior. The specific verb and resource make 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating this tool only queries state and does not modify the scene or parameters. It implicitly guides when to use it (for reading keyframes) versus alternatives (set/delete keyframe tools). However, it does not explicitly name alternatives or state when not to use this tool, leaving a small gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the destructive nature (resetting to empty scene), the suppress_save_prompt=True behavior, the default-disabled permission gate, and the side effect of invalidating caches. This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the main action stated in one sentence, followed by a bilingual safety warning and a side-effect note. It is front-loaded and each sentence adds value, though the bilingual repetition slightly lengthens it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive reset tool with no annotations and no output schema, the description covers the core function, safety gate, and side effects. It is complete enough for an agent to decide and invoke correctly. Return value is not described, but for a reset action this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty (100% coverage trivially). The description adds context about suppress_save_prompt and cache invalidation, which are not parameters but internal behaviors. No parameter explanation needed, so baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Reset Houdini to an empty scene', which is a specific verb+resource. It does not explicitly distinguish from siblings like load_scene or save_scene, but the meaning is unambiguous and unique enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance via the environment variable gate: it is disabled by default and only works when HOUDINI_MCP_ALLOW_NEW_SCENE=1 is set. It also explicitly warns against autonomous use ('禁止 AI 自主清空用户场景'), giving a clear exclusion. No alternatives are mentioned, but the safety constraint guides usage effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it explicitly mentions NO_UNDO (operation is not undoable), states it does not accept a reflective setter, and notes that responses go through server-side apply_response_cap. These are valuable behavioral disclosures 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, purposeful sentences. The main action is front-loaded, followed by a list of allowed values and constraints. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter setter with no output schema, the description covers the core purpose, valid inputs, and key side effects (NO_UNDO, no reflective setter). This is sufficiently complete for an agent to invoke the tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds crucial meaning to the 'direction' parameter by listing the seven valid token values, which the schema lacks. However, it does not clarify the purpose or format of the 'ctx' parameter, and the exact mapping from direction tokens to geometryViewportType values is not specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool maps a direction token to geometryViewportType and invokes changeType, and it enumerates the seven accepted tokens (front/back/left/right/top/bottom/perspective). This makes its purpose specific and distinguishes it from sibling viewport tools like set_viewport_camera or 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for changing viewport direction but provides no explicit guidance on when to prefer it over alternatives or when not to use it. The note about not accepting a reflective setter is a constraint, not a usage directive.
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, description discloses key behaviors: immediate cooking, a validation report, and removal of the node on invalid input. These go beyond basic creation semantics, though it doesn't detail permissions or exact return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose; every sentence adds value (create, params, validation/cleanup). No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers creation, parameter hints, validation reporting, and failure cleanup, which is strong for a tool without annotations or output schema. Could be more explicit about the return value structure, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description explicitly explains run_over allowed values, input_node wiring, and vex_code snippet. parent_path and name remain implicit but are self-evident from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Create' and resource 'Attribute Wrangle SOP', clearly distinguishing from generic create_node and from set_wrangle_code/validate_vex. The scope and optional input wiring are explicitly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use case for creating a new wrangle with VEX and checking validation, but does not explicitly contrast with sibling tools like set_wrangle_code or validate_vex. Still provides clear context for when the tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels. It discloses atomic overwrite via fsync + os.replace, error codes like extension_mismatch and target_exists, failure cleanup, no undo group, and server-side response cap. This is thorough and goes well beyond basic statements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and information-dense, using a bulleted list. Every line adds useful information without fluff. The title 'translator 驱动的原子几何导出' is front-loaded, and the rest is precise. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an export tool with no output schema, the description covers most critical behavioral aspects (formats, overwrite, atomicity, undo, error handling). However, it doesn't describe the return value on success or clarify what 'translator' refers to, and it omits ctx/node_path semantics. Still, it is largely complete for invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides detailed semantics for format (accepted values), output_path (extension matching), and overwrite (behavior when target exists). However, it leaves ctx and node_path undocumented, which are required parameters. Still, the meaningful detail for three parameters is strong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is an atomic geometry export tool, with specific verb '导出' (export) and resource 'geometry'. It provides detailed behavior including format specifics and atomic overwrite, distinguishing it from sibling tools like get_geometry_data or get_geo_summary which are read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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 (for geometry export) and implies it should be used when file output with atomicity is needed, but it does not explicitly mention alternatives or exclusions. The error conditions are helpful but no direct comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility and does an excellent job. It discloses key behaviors: path-based visited set prevents diamond/cycle revisits, max_nodes is a hard HOM access budget that triggers truncated=True, and responses pass through server-side apply_response_cap. This goes well beyond basic read-only labeling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, dense and information-packed, front-loaded with the core purpose and read-only hint. Every sentence contributes value: traversal method, deduplication behavior, budget semantics, and response handling. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key behavioral contract (bounded DFS, dedup, truncation, response cap) but does not describe the return format. Since there is no output schema, the agent must guess the structure of the returned chain. Still, for a simple chain retrieval tool, the behavioral context is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It clearly explains node_path (starting point) and max_nodes (HOM budget, hard constraint), but does not explain ctx or max_depth. max_depth is only present in the schema with a default value, leaving its meaning unclear. This is partial coverage, insufficient for fully disambiguating all four parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it performs a bounded DFS upstream cook chain traversal along inputs() relationships from a given node_path. The verb 'get' is implied and it is distinguished from siblings like cook_node by being explicitly READ_ONLY and focused on dependency traversal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear the tool is for tracing upstream dependencies (cook chain) and explicitly marks it as READ_ONLY, giving context for when it's appropriate. However, it does not explicitly name alternatives or say when not to use it, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses error handling (degrades to status=error), read-only nature, return fields, and response payload truncation. This is rich behavioral context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the primary function, followed by return fields, error behavior, and read-only guarantee. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description is complete: it lists all return fields, explains error behavior, confirms read-only semantics, and mentions response handling. No output schema exists, so the description adequately fills that need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 'ctx' parameter. Since the description should compensate for low schema coverage, the lack of any parameter semantics is a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads current frame, time, fps, ranges, and increment, with a specific verb and resource. It distinguishes from siblings like set_frame and get_keyframes by explicitly focusing on timeline state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'only reads timeline state, does not modify scene or parameters', providing clear context for when to use it. However, it does not explicitly name alternative tools or exclusion scenarios, so not a perfect 5.
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 key behavioral traits: pagination with a 500 limit, default behavior for points (attribute P), and the need to page using start. This goes beyond the schema and provides actionable operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary purpose, followed by concise yet informative details on pagination, element, attributes, and prerequisite call. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema or annotations, the description covers essential aspects: what it reads, how to handle large data, what to supply, and a recommended pre-step. It doesn't detail return format, but that is not mandatory without an output schema, and the context is sufficient for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description adds meaning to most parameters: element specifies 'points' or 'primitives', attributes names with default P, limit capped at 500, and start for paging. Path is the only unmentioned parameter, but is self-evident from the tool's context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Read actual attribute values from geometry.' It distinguishes itself from siblings like get_geometry_info by focusing on actual values rather than metadata, and explicitly references that tool as a prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: pagination instructions for large geometry, clear guidance on elements and attributes, and explicitly advises calling get_geometry_info first to discover available attributes. It doesn't explicitly exclude alternatives but the reference to the sibling tool implies the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the transparency burden and does so admirably. It discloses that HTML parsing uses only stdlib html.parser with zero new pip dependencies, HTTP errors and timeouts degrade to status=error without raising exceptions, and the response passes through apply_response_cap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, with a clear purpose followed by compact parameter and behavior details. Each sentence adds meaningful information; the only minor distraction is the unexplained '(PR 15)' token, which does not materially hurt usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 covers the core usage scenario, return dict fields, error behavior, and dependency footprint. The main gaps are the undocumented ctx parameter and the lack of a concrete example invocation, but overall it is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameter descriptions, so the prose must explain each parameter. It explains help_type (with all 11 values), item_name, and timeout, but completely omits the required ctx parameter, leaving a significant semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: querying SideFX online documentation for Houdini nodes, VEX functions, or hou methods. It clearly distinguishes the tool from broader doc/search siblings by enumerating the exact supported help_type categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The supported help types (sop, obj, vex_function, python_hou, etc.) and the definition of item_name make the intended usage context clear. However, it does not explicitly state when to prefer this tool over alternatives like search_docs or get_doc, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the output content (names, labels, types, tuple sizes, current values, defaults, numeric ranges, menu options), filtering behavior, and pagination. It doesn't mention potential side effects or failure modes, but as a read-only discovery tool, this is adequately 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose, followed by usage and filtering/pagination details. 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/5Given 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 covers purpose, usage, output fields, filtering, and pagination. It doesn't describe return format or error handling, but for this tool's complexity, the description is sufficiently complete for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains pattern matching semantics (glob against name and label) and pagination via offset/limit. Path is implied as the node to describe, though not explicitly tied to the 'path' parameter. Overall, it adds meaningful parameter context beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to describe a node's parameters with a specific list of details (names, labels, types, etc.). It distinguishes itself from siblings like get_parameter and set_parameters by explicitly positioning this as a discovery tool before calling set_parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use this to discover valid parameter names/values before calling set_parameters.' Also explains filtering with glob patterns and pagination with offset/limit. It doesn't explicitly compare to alternatives like get_parameter, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the underlying call (cmn.invalidate_all_caches), the server-side relay, and error behavior (ValueError as error dict with origin='houdini'). Side-effect details for warmup are not specified, but the core behaviors are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized as a scannable action list with a clear opening line. The 'PR 6' note is slightly out-of-place and may distract, but the structure is otherwise efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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, the description covers the key behaviors, side effects, and error handling. It does not detail return formats for invalidate/warmup, but the essential context for correct invocation is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'action' is fully documented in the description, explaining each possible value and its meaning. Since schema coverage is 0%, this rich explanation is essential and completely compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages the Houdini-side NodeTypeCache and enumerates three distinct actions (stats, invalidate, warmup) with their specific effects. This distinguishes it from sibling cache tools like clear_cache and 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The action list effectively defines when to use each behavior, but it does not explicitly compare against sibling tools or state when not to use this tool. The context is clear, though alternatives are not excluded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does so well: it explains the single-call allSubChildren() collection, the dual return lists, truncation behavior for max_warnings, and default semantics for include_warnings and max_errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose, followed by implementation details and a use case. The reference to 'PR 11' adds some internal jargon but does not significantly detract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only scanning tool with no output schema, the description covers the return structure and key behaviors. It does not specify the format of individual error/warning entries, but otherwise is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to root_path, include_warnings, max_warnings, and max_errors, including defaults and truncation flags, despite zero schema coverage. However, the required ctx parameter is not explained, leaving a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it scans error and warning nodes in the scene, which is a specific verb+resource. It distinguishes itself from siblings like find_nodes and cook_node by focusing on errors/warnings and returning categorized lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear use case: 'suitable for one-time health check after scene construction' and compares to cook_node as slower. However, it does not explicitly state when not to use it, such as for targeted per-node debugging.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it does not persist a new connection, calls hou.version() once, returns a dict with pong/elapsed_ms/within_timeout/hou_version, and handles exceptions by setting pong=False and including an error field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient and front-loaded with the core purpose. The parameter section and behavioral note are compact and valuable. It is slightly dense but every sentence adds meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers return values, exception handling, connection semantics, timeout behavior, and usage context, making it fairly complete for a simple ping tool. However, it fails to explain the 'ctx' parameter and the schema types timeout as string while the description implies numeric seconds, causing minor ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 thoroughly explains timeout, including default and behavior when exceeded, but completely omits any explanation of the required 'ctx' parameter, leaving its meaning and usage unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is a lightweight Houdini-side ping that verifies response time. It distinguishes itself from the bridge protocol's 'ping' command, which only validates socket/frame protocol, while this tool measures actual Houdini response time via hou.version().
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it is suitable for health checks and quick probes in network jitter scenarios. It also warns against confusing it with the bridge protocol's 'ping' command, providing an exclusion and clarification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool does not establish a Houdini TCP connection, loads a local RAG index, returns a specific envelope, and handles error cases (rag_index_missing, rag_index_unavailable, _index_warning). This is high-value transparency beyond simple read/write hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (main purpose, connection detail, usage contrast, parameter details, return envelope) and front-loads the core functionality. It is somewhat verbose, including implementation details like 'apply_response_cap' and tokenizer internals, but these earn their place given the lack of annotations and output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, no annotations, and no output schema, the description covers the return envelope, error states, and parameter behavior adequately. The missing ctx parameter and lack of environment prerequisites (e.g., prebuilt index location) are notable gaps, but the overall details are sufficient for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description richly explains the query parameter (tokenizer preserves hou.xxx() and /obj/geo1 semantics, underscore compound handling) and limit (clamp to [1,50], default 10), adding meaning absent from the schema. However, it completely omits the required ctx parameter, leaving its purpose unclear. This gap prevents a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs BM25 retrieval across Houdini documentation ('跨 Houdini 文档做 BM25 检索'), specifying the bridge-local mode and explicitly contrasting with get_houdini_help/verify_hou_api. This distinguishes it from sibling tools and identifies the specific resource and operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: for cross-document thematic searches ('跨文档主题检索') such as examples given, and when NOT to use it (single API/node structured queries better served by get_houdini_help/verify_hou_api). This clearly delineates usage against 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?
With no annotations, the description carries the transparency burden. It discloses that the operation is undoable, per-parameter failure with did-you-mean suggestions, and the presence of a 'failed' list in the result. This goes beyond a basic statement of intent, though it could mention node-path requirements or success signaling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, immediately front-loaded with the main action. Examples are compact and illustrative. Every sentence earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with nested objects and no output schema, the description covers input formats, error handling, and a prerequisite. It could explicitly state that 'path' refers to a node path, but this is implied strongly. Overall complete enough for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It does so thoroughly: explains scalar vs list vs menu token/label values with concrete examples, and mentions that unknown names fail per-parameter. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Set one or more parameters on a node' with a specific verb and resource. It distinguishes itself from sibling tools like 'set_parameter' (singular) by emphasizing 'one or more' and 'single undoable call.' The examples further clarify the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to use get_parameter_schema first when unsure, which is a clear prerequisite. It implies usage for setting parameters versus other tools, but does not explicitly contrast with the singular set_parameter. Context about value formats helps usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly mentions NO_UNDO, error cases for invalid context and renderer, and that responses pass through apply_response_cap. This gives the agent a strong understanding of side effects and 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with clear lines for context, renderer constraint, and response handling. It could be slightly more streamlined, but every sentence adds useful information without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple switch tool with no output schema, the description covers the key behavioral aspects: scope, prerequisites, and error conditions. It does not explicitly state return values, but the response cap hint and simplicity of the tool make this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no parameter descriptions, so the description must add meaning. It explains that renderer must be an identifier from sceneViewer.hydraRenderers() and implies ctx is the LOP context. This partially compensates for the 0% schema coverage, though ctx is not fully detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool switches the Hydra renderer for the LOP SceneViewer. It uses a specific verb ('switch') and resource ('LOP SceneViewer Hydra renderer'), distinguishing it from sibling viewport tools that adjust camera, display, or direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating it is only available in LOP context and that non-LOP usage returns a viewport_unavailable warning. However, it does not explicitly name alternative tools or provide when-not-to-use guidance beyond the context restriction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses multiple traits: TCP relay, per-item result reporting, no rollback, undo merging on mutating segments, and a default max of 50 items with environment-variable clamp. This is comprehensive and adds significant context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact, well-structured paragraph where each sentence adds unique value. It avoids redundancy and is 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.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description fully covers execution order, network behavior, undo integration, error reporting, and limits. It is complete enough for an agent to use the tool correctly without needing external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the operations array structure or the continue_on_error flag. It mentions 'existing Houdini commands' and 'results item by item', which loosely implies error handling, but it does not clarify what each operation object should contain or how continue_on_error affects behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '按顺序执行一批既有 Houdini command' (execute a batch of existing Houdini commands in order), specifying the verb (execute), resource (Houdini commands), and scope (batch). It distinguishes itself from sibling tools by focusing on batch execution and even contrasts with 'bridge' to clarify 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly contrasts with 'bridge' by saying batch does simple TCP relay while bridge pre-checks render policy, giving clear when-to-use guidance. It also notes the lack of transaction rollback, implying that batch is for non-atomic operations where per-item reporting is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that no Houdini TCP connection is made, that path matches exactly against normalized POSIX relative paths, that it never concatenates source filesystem paths or reads files outside the index (including .. traversals), and it details the return envelope and error codes (rag_doc_not_found, rag_index_missing, rag_index_unavailable). This is far more than typical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clearly separated sections for purpose, safety behavior, sibling distinction, parameter details, and return envelope. It is long but every sentence provides valuable information; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's behavior, return format, and error conditions thoroughly. The only notable gap is the unexplained `ctx` parameter, which prevents it from being fully complete. Overall it's nearly comprehensive for a retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description thoroughly explains the `path` parameter with format, example, and how to obtain it. However, the required `ctx` parameter is not described at all. Since schema has 0% parameter descriptions, the description only partially compensates, leaving the agent guessing about `ctx`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '按相对路径取回已索引文档的全文' (retrieve full text of indexed document by relative path), giving a specific verb, resource, and scope. It explicitly distinguishes itself from get_houdini_help and verify_hou_api as complementary tools, making sibling differentiation strong.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly explains when to use this tool vs alternatives: states that get_houdini_help / verify_hou_api target online structured field queries, while this tool is for offline indexed documents. It also notes that search_docs can be used to obtain the path, guiding the agent to the prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: best-effort nature, use of stdlib subprocess with PowerShell CIM or ps, executable basename filtering, no arbitrary command-line substring matching, handling of unavailable CPU/memory with null and _warning tags, returning status=success with warnings on failures, not throwing exceptions, and applying response cap. This is exemplary 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, with the purpose stated first, followed by implementation details, failure behavior, and scope. Every sentence provides essential information without redundancy, making it appropriately sized for a tool with no other documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description covers return behavior extensively: success status, empty/partial results, warnings, no exceptions, and response cap. It also mentions specific warning tags and field availability. The only minor gap is the lack of a complete JSON structure example, but for a monitoring tool this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters in the schema, so the baseline is 4. The description adds meaning by describing output fields (PID, name, CPU, memory, _warning) and clarifies that PID/name are always present while CPU/memory may be null. Although this is output rather than input semantics, it compensates for the lack of an output schema and adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: best-effort observation of husk/mantra OS processes in the bridge process. It specifies the resource (husk/mantra processes) and the action (observe), distinguishing it from sibling tools that operate on Houdini scene data or rendering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context: it is bridge-only, not in the server registry, and uses subprocess instead of hou or TCP. It implies when to use (when OS-level process monitoring is needed) but does not explicitly name alternatives or exclusions, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 key behaviors: omitted file_path falls back to the current hip path, untitled sessions return an error instead of popping a modal dialog, and the return format is JSON or error string. This is solid transparency, though it doesn't mention overwrite behavior 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet complete, covering purpose, fallback behavior, edge case, and return format in four sentences. Every sentence adds value, and the structure is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the main action, all relevant edge cases, and the return value. It is fully adequate 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, but the description fully explains the only parameter (file_path): when omitted or empty/null, it saves to the current hip path; if the session is untitled, it returns an error. This completely compensates for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Save the current Houdini scene to file_path.' It specifies the resource (current Houdini scene) and the target (file_path), distinguishing it from siblings like load_scene and new_scene. The additional context about omitted paths and error handling adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (saving a scene, including to the current hip path when no path is given). It does not explicitly name alternatives or exclude cases, but the context is sufficient given the tool’s name and sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It reveals that rendering is synchronous, that there's a four-layer defense (though specifics are referenced to an internal function), and describes blocked behavior (redirect/interrupt/error dict) and success return fields (state/elapsed/frame_range). This is strong behavioral transparency for a tool of this complexity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args/Returns sections and front-loads the core purpose. It is appropriately sized for a 4-parameter tool with caveats. However, the reference to `_render_jobs.start_render` is internal and adds mild noise, keeping it from being maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 covers all parameters, return behavior, and blocking semantics. It is largely complete, but the 'four-layer defense' is referenced rather than explained, leaving some operational context unspecified. This is a minor gap for an agent making decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description thoroughly explains each parameter: node_path (real ROP path with example), policy_renderer (required, screening role, allowed values), frame_range (optional format), and consent_token (purpose). This fully compensates for the lack of schema descriptions and adds semantics beyond mere type information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '同步启动一次 ROP 渲染' (synchronously start a ROP render), identifying the action (start) and resource (ROP render). It distinguishes from sibling render tools like render_single_view by explicitly mentioning ROP, making it clear this is for render nodes, not view renders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on usage: it's synchronous, involves a four-layer defense, and policy_renderer is required for screening. However, it doesn't explicitly state when to use this tool over alternatives or when not to use it. The context is clear enough that an agent can infer appropriate usage, but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels. It discloses the no-undo behavior, the internal path for step actions (via hou.setFrame with clamping), error conditions (non-finite increment or unavailable range), and the batch dispatcher's handling of undo segments. This goes beyond basic 'reads/writes' and provides operational nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear hierarchical breakdown of actions. Every sentence contributes technical value, such as the distinction between direct HOM calls and the step path, and the undo behavior. There is no padding or redundancy, and the content is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description is complete. It covers all action variants, error handling, clamping behavior, and undo interaction. Given the lack of annotations, it provides sufficient context for an agent to invoke the tool correctly without needing external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the input schema having no descriptions for parameters, the description thoroughly explains the possible values of the 'action' parameter, including the exact semantics for each. However, it does not explain the 'ctx' parameter, leaving that to the schema's empty structure. The compensation is strong for the primary param but incomplete for the other.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: playbar control for play/step/jump operations. It enumerates specific actions (play, reverse, stop, step_forward, step_backward, goto_start, goto_end) and distinguishes itself from sibling tools by emphasizing '运行态时间线写' (runtime timeline write) and 'no-undo' behavior, which is a unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it is for playback control, not for generic frame setting or DOP stepping as seen in siblings like set_frame or step_simulation. It specifies exact behavior for each action, effectively guiding when to use this tool, but it does not explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does an excellent job. It discloses bridge-local operation, no Houdini TCP connection, loading of BEST_PRACTICES.md, advisory nature, and detailed response envelope including error behavior, counts, and truncation flag. This is far beyond 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections: purpose, exclusions, parameter details, and return envelope. Every sentence adds meaningful information with no fluff. The use of formatting aids readability without unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description comprehensively covers behavior, parameter semantics (except ctx), error responses, and response fields, which is especially important with no output schema. The only gap is the unexplained required ctx parameter, so it falls just short of complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 0%, the description adds rich semantics for query (casefold substring match), category (exact match), and id (exact match), and explains AND combination. However, the required ctx parameter is entirely undocumented, which prevents a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries fork-reviewed BEST_PRACTICES advisory recipes locally in the bridge. It explicitly says it does not establish a Houdini TCP connection and distinguishes it from verify_hou_api/get_houdini_help, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-not guidance: recipes are advisory and do not replace verify_hou_api/get_houdini_help or live verification. This names alternatives and clarifies the tool's scope, which is exactly the kind of usage guidance required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It fully discloses key behaviors: writes to draft state, does not immediately enter the retrieval index, strength accumulates without overwriting, team root is read-only, and errors (ls_write_error, root_not_writable) and return formats are described. The advisory workflow with SHALL steps also sets clear expectations for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded with the purpose and each section (trigger, workflow, methodology, parameters, return) is information-dense. Every sentence adds value, though some workflow details could be trimmed, but they are contextually important. It is structured with clear delineations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex write-the-lesson tool with no output schema and no annotations. The description is remarkably complete: it covers purpose, trigger, lifecycle, team root permission, advisory workflow, prohibition of duplicate knowledge, parameter defaults, return shapes for success/error, and exclusions. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 lists required parameters, required severity values (low/medium/high/critical), optional verified_versions defaulting to 'unknown', and root defaulting to 'personal'. However, it does not specify formats for affected_versions or category, and parameter names are self-explanatory but not deeply annotated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource statement: '把解决一个 Houdini 问题的经验沉淀为 lesson（写入个人库 draft 状态）', which specifies the action, target, and state. It also distinguishes this tool from save_recipe by explicitly stating that recipes go to the recipe channel while lessons go through this tool, and from read_lesson/search_lessons by focusing on writing new lessons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit trigger timing ('agent 在解决一个 Houdini 问题后主动沉淀经验'), states when not to use it ('不替代 verify_hou_api / get_houdini_help / get_best_practices'), and gives a concrete alternative workflow: recipes go through save_recipe, and deepening existing lessons uses search_lessons + save_recipe instead of this tool. This is thorough guidance on when to use vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so extensively. It details readOnly semantics, that it does not include geometry data, avoids LLM/embedding calls, handles truncation via max_nodes, and implements strict privacy measures (no library_path, only basename of hip_file). It even explains HDA expansion rules and error codes, going far beyond basic 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-organized into sections (purpose, trigger, parameters, return structure, methodology protocol). Every sentence carries relevant information for an agent to use the tool safely and effectively. While not as terse as possible, the density of crucial operational details (privacy, truncation, HDA rules) justifies the length; a slightly more condensed version might earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, no annotations), the description is exceptionally complete. It explains the return structure (status, root, node_count, truncated, hip_file, nodes, sticky_notes, connections), error codes, HDA expansion logic, privacy constraints, and even advisory methodology for downstream recipe/lesson creation. No critical aspect of behavior or usage is left ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage (no property descriptions), but the description's '参数说明' section thoroughly explains each parameter: node_path optional with no_selection error, include_vex default True, max_nodes default 50 with truncation behavior, and include_hda_internals with detailed expansion criteria. This richly compensates for the schema's lack of semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific statement: it captures the user-selected or node_path-specified node subnetwork as a structured workflow snapshot. It explicitly notes that it is a readOnly relay and does not modify the scene, distinguishing it from mutation tools. It also contrasts with sibling tools like get_selection, save_recipe, and verify_hou_api, confirming its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The '触发时机' section provides concrete trigger conditions: after a user completes an HDA/node flow/VEX workflow and says '沉淀这些知识', the agent should first call get_selection, then this tool, then organize results into save_recipe or save_lesson. It explicitly states what the tool does NOT replace (verify_hou_api, get_houdini_help, get_best_practices, live verification), giving clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it states it does not establish a TCP connection or import hou, streams using legacy cpio/odc entry format, applies five hard limits for untrusted input, only clips output tree with max_depth, and includes caveats like '不求值、不比较默认、不保证动画/表达式完整'. It also explains partial error responses and the apply_response_cap behavior, far exceeding baseline expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but highly structured: first the core behavior and safety, then the differentiation from siblings, followed by parameter notes and the return envelope with error codes. Each sentence carries substantive information with no filler, and the front-loaded opening makes the tool's purpose immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (4+ parameters, no output schema, no annotations), the description covers all necessary aspects: operation mode, extraction targets, limits, parameter semantics, return envelope fields, error codes, and partial-result behavior. It is self-sufficient for an agent to understand, invoke, and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions (0% coverage), so the description compensates by explaining file_path (extension restriction, unsupported_extension error), include_params (raw parm text, no evaluation), and max_depth (clamped to [1,64], affects only structure tree). However, the required 'ctx' parameter is not explained at all, which is a minor gap given the detailed coverage of the other three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+scope: '离线 best-effort 解析 .hip/.hiplc/.hipnc（bridge-local，无 Houdini 连接）' clearly stating it parses offline Houdini archive files without a Houdini connection. It also distinguishes itself from siblings by explicitly naming serialize_scene/get_node_info as online alternatives, 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance: '与 serialize_scene / get_node_info 互补：那两个面向在线 Houdini 连接的实时节点树查询；本工具面向离线文件审计' — directly contrasting with online tools and prescribing offline file auditing as the intended use case. This provides clear alternatives and 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 carries full burden. It explicitly states the tool is read-only ('只读 advisory 内容'), details the return fields, explains error behavior for missing ids, and mentions the apply_response_cap transformation. No side effects are hidden, and the read-only nature is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections (purpose, trigger, parameter, return) and front-loads the main action. It is slightly longer than strictly necessary, but every sentence adds useful detail, and the formatting aids scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explains the full return shape and error code. It covers usage context, alternatives, parameter source, and behavioral constraints. For a simple read tool with one parameter, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides zero description coverage, so the description must fully explain the 'id' parameter. It gives a concrete format example and instructs that the id comes from search_lessons. This completely compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: '按 id 拉取单条 lesson 的完整 markdown 全文' (fetch complete markdown by id). It explicitly distinguishes this from search_lessons (which finds lessons) and from other advisory tools, making its scope clear and unique among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It states when to use: 'search_lessons 命中后按需拉全文' (after search_lessons hits, fetch as needed) and notes drafts are readable. It also names what it does NOT replace (verify_hou_api, get_houdini_help, get_best_practices) and cautions against replacing live verification. This is 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it performs a write, has no draft threshold, is immediately searchable, auto-generates recipe_id, conditionally replaces blocks, attaches @username for team roots, and details error codes. It also warns against storing local paths and notes advisory limitations relative to live verification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place: core purpose, trigger context, parameter semantics, return format, error handling, and methodology protocol. It is well-structured with clear subsections, front-loading the primary function, and avoids fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, no output schema, and no annotations, the description is remarkably complete. It specifies return values ({status, recipe_id, root, severity, source, immediately_searchable, action}), every error scenario and code, and the methodology protocol. The only omission is ctx, but overall it fully compensates for missing structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It does so thoroughly for title/problem/symptom/fix/category/severity/affected_versions, severity value domain, verified_versions default, recipe_id format and replacement behavior, and root default. However, the required 'ctx' parameter is never mentioned in the 参数说明, leaving a small but real gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool writes a usage/workflow knowledge entry to a specified root's recipes file. It explicitly distinguishes itself from save_lesson ('用法/流程文档走本工具 save_recipe', '错误经验走 save_lesson'), demonstrating a specific verb+resource+scope and 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit trigger timing ('用户完成工作流后说"沉淀这些知识"时'), a prescribed sequence (get_selection → capture_workflow_snapshot → save_recipe), and clear alternatives (save_lesson for error experiences; verify_hou_api / get_houdini_help / get_best_practices as non-substitutes). Also explains when to update existing recipes via recipe_id instead of creating duplicates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states the tool is 'advisory', describes the return envelope (status/query/top_k/matched/returned_count/truncated/results/draft_suggestions), error format (status=error + error={code,message,details}), and special behavior for unknown scopes. It also includes detailed workflow annotations, exceeding what annotations would typically provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, trigger, workflows, parameters, return envelope) and front-loaded with the main purpose. It is long, but most content earns its place. The inclusion of the knowledge deposition workflow is arguably tangential to the search tool itself, adding some extra length, but still provides useful context for the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description is remarkably complete. It covers purpose, trigger conditions, alternatives, parameter semantics, output envelope, error handling, and workflow integration. An agent has everything needed 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description compensates fully. It explains each of the 6 parameters: query (can be empty for baseline browsing), category/severity (exact filters with severity enum), node_type (substring filter with examples), houdini_version (substring filter), and scope (optional root name or 'all' with default). This adds substantial meaning beyond the schema's bare type declarations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '跨全部可用知识库 root 检索既往经验（published lessons + root recipes）', specifying a concrete verb (search) and resource (all knowledge base roots). It further distinguishes itself from siblings by explicitly naming related tools (read_lesson, verify_hou_api, get_houdini_help, get_best_practices) and explaining its advisory role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit trigger conditions: '遇到报错、重试第 2 次仍未解决、或遇到不认识的 API/参数时，先调用本工具'. It also states when not to use it, saying it does not replace live verification or the help tools. This is a model of 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.
- Behavior5/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 arbitrary-execution nature, safety policy levels, per-call override flags, and scene snapshot behavior via capture_diff, implying risks compared to validated dedicated tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured intro with warning, followed by a concise Args list; every line adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, high-risk tool, the description covers purpose, safety policy, parameter semantics, and return envelope (status/stdout/stderr/audit block) while an output schema handles precise return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description explains every parameter's meaning and constraints (policy values, privileged-only for allow_dangerous, heavy-geometry override, capture_diff usage), greatly exceeding schema-only info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action ('Execute arbitrary Python code in Houdini's environment') and explicitly distinguishes itself from dedicated siblings by labeling itself 'LAST RESORT' and naming alternatives (connect_nodes, set_parameters, 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use ('only for operations no dedicated tool covers') and when not to use ('prefer the dedicated tools'), even naming the specific advantages of alternatives (validation, structured errors, undoability).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the read-only nature, status values (ok/unconfigured/unavailable), behavior for unconfigured roots (silent), warning suffix for unavailable roots, and error handling for unknown scope. It also notes it does not replace live verification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: core purpose first, then trigger conditions, details, parameter explanation, and return format. Every sentence adds value with no redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description provides the complete return structure, status semantics, and error code. Combined with the parameter explanation, it is fully self-contained for a one-parameter, read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only lists 'scope' with no description. The description explains scope is optional, with default/'all' returning all roots, and defines the special value 'all'. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it views knowledge base root statuses and counts (read-only status report). It explicitly names the resource and differentiates itself from sibling tools like verify_hou_api, get_houdini_help, and get_best_practices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit trigger conditions (e.g., when you need to check knowledge base status, confirm writes, or troubleshoot retrieval scope) and explicitly lists what it does not replace, offering clear context for when to use this tool over alternatives.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ChengZiiii/opera-houdini-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server