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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

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

The schema has 0% description coverage, so the description must compensate. It explains 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

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

Schema description coverage is 0%, so the description must compensate. It explains 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It 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.

Does 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.

Does 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.

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.

Is 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.

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

Given the tool's complexity (5 parameters, 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

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

The tool has no output schema and no 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.

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

Schema description coverage is 0%, so the description must compensate. It explains the 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

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

The description gives clear context for when to use 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

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

Schema description coverage is 0%, so the description must compensate by explaining parameter meanings. It 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.

Does 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.

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

No guidance is provided on when to use this tool versus alternatives such as create_node or 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.

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.

Is 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.

Given 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.

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

Schema description coverage is 0%, so the description must compensate. It partially does: 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.

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

The description states a specific verb ('create') and resource ('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.

Does 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.

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.

Is 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.

Given 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.

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

Schema description coverage is 0%, so the description must compensate. It adds 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

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

The description provides no guidance on when to use this tool versus alternatives like create_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.

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.

Is 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.

Given 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.

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

Schema coverage is 0%, so the description must compensate. It 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.

Does 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.

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

The description provides no explicit guidance on when to use this tool versus alternatives 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

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

No usage guidance is provided. The description does not 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.

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.

Is 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.

Given 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.

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

Schema description coverage is 0%, so the description needed to 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

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

Schema description coverage is 0%, so the description must compensate. It adds meaning 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

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

No guidance is provided on when to use this tool versus alternatives. The description only 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.

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.

Is 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.

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

Given that there is no output schema 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.

Does 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.

Does 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.

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

No explicit guidance on when to use this tool versus alternatives 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

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

Schema description coverage is 0%, so the description must compensate. It adds 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.

Does 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.

Does 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.

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.

Is 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.

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

Given the simplicity of the tool (one 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.

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

Schema description coverage is 0%, so the description must compensate. The 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.

Does 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.

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

The description provides no guidance on when to use this tool, 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.

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.

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

The description is a single concise sentence that is front-loaded with the action. 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.

Given 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.

Does 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.

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

The description clearly states the action with a specific verb ('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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

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

Schema coverage is 0%, so the description must compensate. It 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.

Does 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.

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

No guidance is given on when to use this tool versus alternatives. 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.

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.

Is 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.

Given 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.

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

Schema description coverage is 0%, so the description must compensate. It 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.

Does 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.

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

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

Given the absence of an output schema, 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

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

No guidance is provided on when to use this tool versus alternatives such as list_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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

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

For a tool with no annotations, no output schema, and an 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

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

Schema coverage is 0%, so the description must compensate. It provides detailed 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.

Does 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.

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

The description gives clear context for when to use this tool (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.

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.

Is 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.

Given 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.

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

Schema description coverage is 0%, so the description must compensate. It 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.

Does 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.

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

No guidance is provided about when to use this tool versus alternatives like 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

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

The schema has 0% description coverage, so the description must 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

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

Schema description coverage is 0%, so the description must compensate. It adds meaning 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

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

Schema coverage is 0%, so the description must compensate. It 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.

Does 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.

Does 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.

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.

Is 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.

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

The tool has no output schema and no 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.

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

Schema description coverage is 0%, so the description must compensate. It does 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.

Does 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.

Does 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.

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.

Is 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.

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

Given no annotations, no output schema, and 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.