fxhoudinimcp

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 states the operation ('Assign a material') but does not disclose side effects, such as whether the Material SOP is created/modified, whether existing material assignments are overwritten, or whether the scene is modified irreversibly. For a mutation tool with zero annotation coverage, this is a significant gap.

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

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

The description is compact and front-loaded with the main action, followed by a concise parameter list. It earns its place with no filler, though the parameter list is somewhat redundant with the schema.

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 mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It does not explain what happens after assignment, how to verify success, or what errors might occur. An agent would need to infer prerequisites and side effects from the tool name and sibling context.

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 add minimal meaning by naming the parameters ('geo_path: Target geometry node path', 'material_path: Material to assign'), which clarifies their roles beyond the bare schema titles. However, it does not explain expected path formats (e.g., '/obj/geo' vs relative paths) or whether the material path must point to a specific node type.

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 ('Assign') and resource ('material to a geometry node via a Material SOP'), which clearly identifies the operation. It does not explicitly distinguish it from sibling tools like create_material or list_materials, but the action is specific enough that an agent can infer 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 provides no guidance on when to use this tool versus alternatives such as create_material, list_materials, or set_parameter. It does not mention prerequisites (e.g., the geometry node must exist, the material must already be created) or context for when this is the right choice.

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

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses atomicity (all-or-nothing), pre-validation against the running Houdini, did-you-mean error suggestions, cooked evidence in the result (per-node errors and display node geometry counts), and the layout behavior (created nodes positioned relative to inputs, existing nodes keep positions). This is rich, honest 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 long but every section earns its place: the atomicity pitch, the validation behavior, the dry_run tip, the layout caveat, and the spec format. It is front-loaded with the most important usage guidance. It loses one point only because the node-spec enumeration is dense and could be slightly tightened, but it is not bloated or redundant.

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 4-parameter tool with no annotations and no output schema, the description is remarkably complete. It covers what the tool does, when to use it, how parameters behave, what the result contains, and edge-case behavior (layout with existing nodes). An agent has everything needed to invoke it 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, and it does thoroughly. It explains parent_path ('Network to build inside'), nodes (ordered specs with a full breakdown of the spec dict format, including type, name, parms, inputs with multiple wiring forms, flags, color, comment), dry_run (validate without creating), and layout (default True, honored only when auto-layout is enabled, with precise positioning semantics). This far exceeds what the bare schema provides.

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 ('Build'), a precise resource ('a whole node network in ONE atomic call'), and the key differentiator from node-by-node construction. It also names the preferred use case (3+ nodes) and contrasts with the slower alternative, making the tool's identity unmistakable.

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 says when to use this tool ('the PREFERRED way to construct anything of 3+ nodes') and why (massively faster, atomic). It also gives a concrete usage tip: use dry_run=True to prove a plan with unfamiliar node types. This is strong, actionable 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 behavioral burden, and it does disclose key behaviors: nodes are created in order, automatically connected to the previous node, and all done in one call. It does not mention return values or handle edge cases like invalid node types, but it is substantially transparent about what the operation does.

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 opens with a one-sentence purpose statement, immediately adds usage guidance, gives a compact schema for the step dict, and includes a concrete example and Args section. There is no filler; every section earns 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?

For a two-parameter tool with no output schema and no annotations, the description covers the essential invocation details: parent path, step format, ordering behavior, and automatic wiring. The only notable gap is no mention of the return value or how the created nodes are identified afterward, which is a minor omission given the otherwise strong guidance.

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 compensates well by defining the step dict structure with its fields ('type', optional 'name', optional 'params'), explaining parent_path as the parent SOP network path, and providing a concrete example. It does not enumerate all possible node type strings, but the example clarifies enough for correct invocation.

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 and resource: 'Build a sequential chain of SOP nodes wired together in a single call.' It also distinguishes itself from the relevant sibling create_node by explicitly stating it is preferred for linear SOP chains, making its purpose unmistakable.

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 states when to use this tool: 'PREFERRED over individual create_node calls for linear SOP chains.' It names the alternative, gives the condition, and gives the rationale (single round-trip, significantly faster). The word 'linear' also implicitly excludes branching/non-linear networks from its intended use.

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 responsibility. It says 'Cancel active cooking' but does not disclose that this stops all cooking on the network, whether it clears the work item states, or how it affects the PDG graph. This opacity is a gap for a cancellation action that can have significant side effects.

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

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

The description is short and direct, with two sentences and a simple Args list. It is not verbose or padded. However, it is under-specified for the complexity of the action, sacrificing completeness for brevity. Still, it earns a 4 for front-loading the core statement.

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 cancellation tool with no annotations and no output schema, the description is missing key context: prerequisites, side effects (e.g., does it delete cooked results?), and how to verify cancellation. Given the complexity of PDG cooking and the existence of pause_top_cook, the definition is incomplete for an agent to use it safely.

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 node_path. It merely restates 'TOP node or TOPnet path' without adding context like whether it accepts a string that can be a root path or how to specify a node inside a network. This is minimal and does not compensate for the schema's lack of description.

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

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

The description states a specific action (cancel active cooking) on a TOP network, but it is terse and lacks detail about what this means in practice. It distinguishes from siblings like pause_top_cook and cook_top_node, but does not explicitly differentiate behavior. A 3 reflects the clear verb and resource without deeper explanation.

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?

There is no guidance on when to use this tool versus alternatives like pause_top_cook or dirty_work_items. It does not state prerequisites (e.g., node must be cooking) or typical use cases. The only hint is the name and description, which imply it cancels cooking, but an agent cannot determine when to prefer it over pause_top_cook.

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 disclosure burden. It transparently states the side effect: 'The image is written to disk only; open output_path with your file reader to look at it,' clarifying the output is not returned but persisted. It does not mention failure conditions or file format, hence the slight deduction.

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. The purpose is stated first, followed by behavior, usage guidance, and parameter details. Every sentence adds information without redundancy. The structure is ideal for quick scanning by an 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?

The tool is simple (two params, no output schema, no annotations), and the description covers all essential dimensions: purpose, side effects, file usage, alternatives, and parameter meaning. Nothing needed to invoke it correctly is missing.

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 the parameters. It provides concise but meaningful semantics for both: 'output_path: Image file path' and 'node_path: Node path to navigate to before capture.' These go well beyond the schema's bare titles, making invocation unambiguous.

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 verb and resource: 'Capture a screenshot of the network editor.' It also distinguishes itself from siblings by explicitly steering away from get_node_info/list_children for inspection, making its unique purpose (visual wiring confirmation) clear.

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 explicit guidance: 'Prefer get_node_info or list_children for inspecting node connections unless visual confirmation of wiring is genuinely needed.' This tells the agent exactly when this tool is the right choice and names the preferred alternatives.

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 of behavioral disclosure. It states the side effect (file written to disk only), how to inspect it (open output_path), and the non-blocking wait behavior of settle_seconds. It could mention overwrite behavior or return value, but the disclosed traits are genuinely useful and accurate.

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?

Every sentence earns its place: capability, disk-only behavior, alternative guidance, and per-parameter clarifications. It is tight, front-loaded, and free of 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 no annotations and no output schema, this description covers what the tool captures, where the output goes, how to view it, when to avoid it, and all three parameters. Nothing essential is missing 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%, so the description must carry the parameter meaning, and it does: each arg is explained with purpose, behavior, and the 120 cap on settle_seconds. This is far beyond what the bare schema names provide.

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?

States a specific verb ('Capture') and resource ('screenshot of the viewport or a specific pane tab'). The phrase 'written to disk only' differentiates it from rendering or network-capture siblings, so an agent can distinguish it without opening the schema.

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 directs the agent to prefer text-based tools (get_geometry_info, get_node_info, get_scene_summary) unless visual confirmation is genuinely needed. Also tells the agent to use settle_seconds instead of a shell sleep, which is concrete and unambiguous.

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 disclosure burden. It explains what is preserved, what happens to dropped/reset parameters, that unversioned names map to the preferred version, and that keep_network_contents=False resets an asset to its definition's contents even if already of the new type. It does not mention failure modes, permissions, or return behavior, so it is not a 5.

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

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

The description is well-structured: a compact behavioral summary, contextual examples, and a clear Args list. The prose is detailed but every sentence contributes meaningful information, so it earns its length without being bloated.

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 five parameters, no annotations, and no output schema, the description covers the core semantics well: what the tool does, when to use it, and the behavior of key flags. Missing return-value or error-condition details are minor for this kind of in-place 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 description coverage is 0%, so the Args section must compensate. It documents all five parameters, with useful additions for new_type ('in the node's own category'), keep_parms ('by name'), and keep_network_contents ('False resets an asset to its definition's contents'). However, node_path and keep_name are essentially restatements of their names and add minimal semantic value.

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, resource, and behavior: 'Change a node's type in place' while preserving wires, name, position, flags, parameter values, and network contents. This clearly distinguishes it from sibling operations like create_node, delete_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 gives concrete use cases: moving an HDA instance to a newer installed version and swapping a placeholder for a real node. It also references create_node for version-name behavior, but it does not explicitly state when not to use this tool or compare it with a direct alternative.

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 does clearly disclose the destructive nature of the operation by specifying that cached files on disk are deleted, and it adds useful context by noting frame_range can limit deletion. However, with no annotations provided, the description carries the full burden and does not mention whether the operation is reversible, what happens to the cache node itself, or how missing paths are handled.

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

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

The primary behavior is front-loaded in the first sentence, and the parameter explanations are compact and directly useful. The 'Args:' block is mostly efficient, though including the non-schema ctx argument adds slight noise.

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?

This is a simple destructive tool with no annotations and no output schema, and the description covers the required node_path and the optional frame_range semantics. It is minimally viable, but it lacks any statement about return behavior, failed lookups, or whether deletion is permanent, which would make the tool safer for an agent to invoke.

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?

Since schema description coverage is 0%, the description compensates by explaining node_path as 'Path to the cache node' and explaining frame_range as a '[start, end] range that limits deletion. It adds meaning beyond the bare schema property names, though it also lists a ctx param that does not appear in the input schema, which is a minor distraction.

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 immediately states the operation: 'Delete cached files on disk for a cache node.' This is a specific verb plus resource that clearly differentiates it from siblings like list_caches, get_cache_status, and write_cache. No ambiguity remains about what the tool does.

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

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

There is no guidance about when to choose clear_cache over related cache-management tools such as write_cache, list_caches, or get_cache_status. The usage context is only implied by the verb 'Delete' and the tool name. No explicit prerequisites, exclusions, or alternative tools 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?

No annotations are provided, so the description carries the full behavioral burden, but it only discloses the operation and parameter names. It does not say whether taking a snapshot mutates the scene, whether compare returns output, or what side effects occur, leaving significant behavioral ambiguity.

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

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

The description is short and front-loaded with the core purpose, and the Args block is compact. It is efficient, though the snapshot_name line is redundant with the schema's property title and adds little information.

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 though the tool is simple, there is no output schema and no annotation safety information, so the description should explain what taking or comparing snapshots does, how results are returned, and what happens to existing snapshots. That context is absent. An agent cannot confidently predict the tool's observable 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?

With 0% schema description coverage, the description does contribute meaning by listing the allowed values 'take' or 'compare' for action, which is useful since the schema has no enum. However, 'snapshot_name: Snapshot name' just restates the parameter title and adds no deeper semantics about scope, format, or 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 states a clear operation: 'Take or compare scene state snapshots,' and the action argument enumerates the two supported modes. It is understandable on its own, though it does not explicitly differentiate itself from similar sibling tools such as create_take or list_takes.

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?

There is no guidance about when to use this tool rather than snapshot- or take-related siblings, and no mention of alternatives or exclusions. The intended use cases are only implied by the phrase 'take or compare,' so an agent gets little routing help.

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 burden. It discloses parameter precedence ('input_name ... wins over input_index') and special subnet behavior, but does not state side effects such as whether existing connections are replaced or error/validation behavior. This is a meaningful gap for a mutation tool.

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

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

Front-loaded with the core action, followed by a focused special-case note and a compact Args list. No filler; every line adds useful information.

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 all six parameters and the tricky subnet case despite no output schema and no annotations. Minor gap: it does not mention what the tool returns or how it handles invalid inputs, but the calling semantics are clear.

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 Args section documents every parameter with meaningful semantics, including path roles, index meaning, the input_name precedence, and indirect_input constraint ('dest_path must live inside that subnet'). Fully compensates for 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?

States a specific verb and resource, 'Connect two nodes together,' and clarifies the special subnet indirect-input case, making it distinguishable from sibling tools like connect_nodes_batch and disconnect_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?

Describes when to use the indirect_input form ('To feed a node INSIDE a subnet from one of the subnet's own input connectors...') and explains path semantics. Does not explicitly name alternatives or when-not conditions, so not 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the input mechanics well, but it does not state side effects, whether existing connections are replaced, failure behavior, or whether the operation is atomic, leaving important behavioral ambiguity for a mutation tool.

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

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

The description front-loads the single-sentence purpose and then provides a compact, structured parameter breakdown. It is dense but each line adds necessary information; the only cost is that the explanation is technical and requires careful reading.

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 and no output schema, the description adequately documents the complex connections parameter but omits expected returns, error/partial-failure semantics, and any limits on batch size. This leaves agents uncertain about what to expect after invocation, beyond the operation itself.

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%, and the schema only declares an untyped array of objects. The description compensates thoroughly by documenting every expected key, its type, defaults for output_index and input_index, precedence of input_name over input_index, and the nuanced behavior of indirect_input.

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 'Connect multiple node pairs in a single call,' which names a specific verb, resource (node pairs), and batch scope. This clearly distinguishes it from sibling connect_nodes and other network 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 batch intent is explicit in 'multiple node pairs in a single call,' giving clear context for when this tool is appropriate. It does not explicitly name connect_nodes as the alternative for single connections, but that exclusion is strongly implied by the sibling name and the phrase 'in a single call.'

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 behavioral disclosure: frames are cooked in order so solvers accumulate correctly, results come in one round trip, per-frame errors and aggregates are reported, and the frame is left at the end for screenshots. It also warns that skipping frames produces discontinuous time steps and invalid results.

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 core operation, then gives usage rationale, and ends with a compact parameter walkthrough. Each sentence adds information—even the repeated 'one call vs. one per frame' point is used to reinforce the alternative comparison.

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 or annotations, the description covers the key invocation facts: what it does, when to use it, parameter semantics, side effects, and the shape of returned information (per-frame cook time, errors, counts, attribute aggregates, volume details). A precise JSON return layout is not specified, but the description provides enough for an agent to select and call 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?

The schema provides types, defaults, and required status but no descriptions, so the Args section must and does compensate. It explains node_path as the measured output, start/end defaults to the playbar, step's solver-specific warning, the aggregate math for attribs, and exactly what volumes adds.

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 opening sentence states a specific verb ('cook'), a resource ('a node'), and the output ('report what changed on each frame'), which clearly distinguishes it from sibling tools like set_frame and get_cook_status. The usage note that this is how you advance a sequential solver further reinforces 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 description explicitly says to prefer this over set_frame in a loop or stepping by hand, and explains the advantage in a single call for a 100-frame check. It also gives a strong condition for when not to set step above 1.0 (any solver), making selection guidance actionable.

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 disclosure burden. It does disclose the blocking behavior and the generate_only mode, which is useful, but it does not mention side effects, failure modes, or that cooking can be a long-running operation. This is partial but not comprehensive 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 compact and front-loaded with the core action, followed by a clean parameter list. The only minor waste is 'ctx: MCP context,' which is generic and adds little, but overall the structure is efficient and easy to scan.

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 does not explain what the tool returns, what happens when block is false, or what errors/prerequisites exist. For a cooking action with many related TOP tools, an agent still lacks important operational context.

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, and it does. Each parameter receives a meaningful one-line explanation, especially generate_only ('Only generate work items, do not cook') and block ('Wait for cooking to complete'), which add real semantics beyond the raw 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 ('Cook a TOP node') and the effect ('execute its work items'), which goes beyond the bare tool name. However, it does not explicitly differentiate from related siblings like cook_frame_range or get_cook_status, so it stops short of full sibling distinction.

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 such as cancel_top_cook, get_cook_status, or cook_frame_range. The intended context is only implied by the verb 'cook' and the parameter names, with no explicit when-to-use or when-not-to-use information.

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 disclosing behavior. It states that it copies a node but does not mention whether the copy is deep, what happens to connections, dependencies, or how name conflicts are handled. It also does not disclose any side effects or required permissions, making it incomplete for a mutating operation.

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

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

The description is concise: a single sentence summarizing the purpose plus a structured Args docstring. It is front-loaded with the primary action and avoids unnecessary verbosity, though the docstring format is somewhat redundant with the schema.

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 must fully equip an agent to use the tool correctly. It lacks critical details such as error handling, naming conflict behavior, whether the copy is recursive, and how the tool relates to sibling operations like move_node or create_node. This is insufficient for a tool that manipulates scene graph nodes.

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 zero description coverage, so the description must compensate. The docstring provides brief explanations for each parameter (source node path, destination parent path, name for the copy), which adds some meaning beyond the bare titles. However, it does not clarify optionality, defaults, or the behavior when dest_parent or new_name are omitted, leaving 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 states the action (copy) and the resource (node), with an optional variation (into a different parent network). It is specific enough to distinguish from move_node and create_node, though it does not explicitly mention the new_name parameter, which is implied but not highlighted.

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 like move_node, rename_node, or create_node. It does not state when copying is appropriate or when a different tool should be used instead, leaving the agent to infer the context from the name alone.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states "Create a new CHOP node," implying mutation but offering no details about potential errors, behavior on duplicate names, whether the tool validates chop_type, or what happens if parent_path is invalid. This leaves the agent with insufficient knowledge of side effects or failure modes.

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

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

The description is well-structured: a one-sentence purpose, a focused usage note, and an args list. The list of CHOP node types is a bit lengthy but serves the usage guidance by illustrating alternatives. Overall, no redundant sentences are present, and the key information is front-loaded.

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 three-parameter creation tool with no output schema or annotations, the description covers the purpose, pre-call validation, and parameter meanings. However, it does not explain what the tool returns (e.g., node path) or error behavior, which is important for an agent to confirm successful creation. The pre-call guidance helps but the description remains incomplete 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 description coverage is 0%, so the description must compensate. It does provide concise definitions for all three parameters: parent_path (parent network path), chop_type (CHOP node type to create), and name (node name override). This adds meaning beyond the raw schema, but the definitions are terse and lack constraints, examples, or format details, so compensation is only partial.

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 and resource: "Create a new CHOP node." This clearly differentiates it from siblings like create_cop_node, create_lop_node, and the generic create_node, because the CHOP context is explicit. The additional list of dedicated CHOP node types reinforces the tool's scope without ambiguity.

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 instructs the agent to call list_node_types(context='Chop', filter='<keyword>') before using this tool to verify the correct node type, and warns that many dedicated nodes already exist that may do what is needed. This provides clear when-to-use and when-not-to-use guidance, effectively steering the agent away from unnecessary creation.

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 burden of behavioral disclosure. It does explain the Copernicus vs COP2 distinction and notes that Copernicus is preferred over deprecated COP2. However, it doesn't disclose what happens on failure, whether the node is created with default parameters, or whether the operation is destructive to existing nodes. The description adds some context but not comprehensive behavioral detail.

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

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

The description is well-structured with a clear opening sentence, a usage note, and an Args section. It's moderately sized but every sentence earns its place. The front-loaded purpose statement and the practical pre-call instruction are valuable. The list of example node types is somewhat long but serves a real purpose in guiding tool selection.

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 3 parameters and no output schema, the description covers the essential context: what the tool does, how to determine the correct cop_type, and the meaning of each parameter. It doesn't explain return values or error behavior, but given the tool's simplicity and the absence of an output schema, the description 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. The description lists the three parameters (parent_path, cop_type, name) in an Args section, but only provides minimal context: parent_path is 'Path to the parent COP network', cop_type is 'COP node type to create', and name is 'Override node name'. This adds some meaning beyond the schema's bare titles, but doesn't explain formats, defaults, or constraints beyond what the schema already shows.

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 purpose: 'Create a COP node in the specified network.' It identifies the resource (COP node), the action (create), and the target context (specified network). It also distinguishes between Copernicus (Houdini 20+) and legacy COP2 contexts, which helps differentiate it from sibling tools like create_chop_node, create_lop_node, and create_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 explicit usage guidance: it instructs the agent to call list_node_types(context='Cop', filter='<keyword>') before using this tool, and explains when to use Cop vs Cop2. It also lists many dedicated COP node types that may cover the operation without needing a VEX COP or Python, which helps the agent decide when this tool is appropriate versus alternatives.

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 reveals only that the tool creates an HDA from a subnet node. It doesn't state whether the source subnet is modified, whether the destination file is overwritten or errors if it exists, whether a cook is triggered, or any side effects. For a creation tool this is a meaningful gap.

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 purpose sentence is front-loaded, followed by a compact structured args list. It is reasonably efficient with no obvious filler. Minor waste: the 'ctx: MCP context.' line references a non-schema parameter, but overall the structure is clean and scannable.

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 no output schema and no annotations, the description is incomplete. It doesn't explain the return value, preconditions (e.g., what makes a node a valid 'subnet node'), error behavior if the destination file exists, or side effects on the scene. An agent would have to guess at these details.

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 args section does add one-line meaning to each parameter ('Subnet node path', 'Destination HDA file path', 'Operator type name', 'Human-readable label', 'Version string') beyond the bare schema titles. However, these are minimal glosses, and the description lists 'ctx' as an arg even though it isn't in the schema, which is slightly confusing. It helps but doesn't fully compensate for the coverage 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 (HDA) with the source material ('from an existing subnet node'). This distinguishes it from siblings like install_hda, update_hda, reload_hda, and uninstall_hda, which are different lifecycle operations. It's clear but doesn't explicitly name the siblings it differs from.

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 on when to use this tool versus alternatives such as update_hda (for existing HDAs) or install_hda. No exclusions, preconditions, or contextual cues are given. The args listing describes what each parameter is, not when the operation 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?

No annotations provided, so the description carries full burden. It states it creates a light but doesn't disclose side effects, permissions, failure behavior, or whether it modifies existing lights. For a mutation tool, this is a significant gap.

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

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

Concise, front-loaded with purpose, and efficiently lists parameters without fluff. The format is clean and scannable.

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?

Incomplete for a creation tool with 6 parameters: no mention of return value, prerequisites (like LOP network existence), edge cases, or assumptions. Assumes familiarity with USD/LOP concepts and doesn't explain optionality.

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 lists all parameters with brief descriptions (e.g., light_type options), adding meaning beyond the schema. However, lacks ranges/units for intensity, color, and position, and doesn't indicate defaults, so compensation is partial.

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?

States a specific action (create) and resource (USD light in LOP network), clearly distinguishing from list_lights and set_light_properties. The verb+resource is precise and unambiguous.

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

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

No guidance on when to use this tool vs. alternatives like create_light_rig or set_light_properties. The description is silent on selection criteria, prerequisites, or when not to use it.

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

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

With no annotations, the description must disclose behavioral traits, but it only says 'create' and lists parameters. It does not explain whether existing lights are replaced or added, if the parent LOP network must already exist, or what side effects occur. This is insufficient for a creation 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 compact, front-loaded with the main purpose, and uses a simple Args list without fluff. It could be slightly more structured, but every sentence earns 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?

The tool is simple (3 flat params) and all params are described, but there is no mention of return values or side effects, and no output schema exists to clarify what the agent should expect. Prerequisites and failure behavior are also omitted, leaving moderate 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%, yet the description fully compensates by defining all three parameters: parent_path, preset with an explicit list of allowed strings, and intensity_mult as a multiplier. This is exactly the information an agent needs to call the tool correctly and goes well beyond the bare parameter 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 states a specific verb ('create') and resource ('preset lighting rig in a LOP network'), clearly distinguishing it from siblings like create_light (single light) and set_light_properties. The preset keyword reinforces that this is a higher-level, packaged 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?

No guidance on when to choose this tool over alternatives such as create_light or create_lop_node. The 'preset' phrasing implies a convenient higher-level tool, but there is no explicit when/when-not or alternative mention.

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 of behavioral disclosure. It states the creation action and lists examples, but does not disclose side effects such as whether creating the node triggers a cook, what happens with null name or prim_path, whether the parent must already exist, or what the tool returns on success.

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 a short intro, a focused prerequisite, and a compact Args list. The list of specialized LOP types is long but earns its place because it prevents incorrect tool usage.

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 main workflow and parameter meanings, which is more than minimal. However, with no output schema and no annotations, it omits return behavior, error conditions, and mutation side effects, leaving the agent with an incomplete picture after 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?

With 0% schema description coverage, the Args section compensates by documenting all four parameters and giving clarifying examples for lop_type and prim_path. It does not fully explain default behavior for name and prim_path, but the added semantics are genuinely useful.

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 (create) and the resource (a LOP node), and the LOP qualifier distinguishes it from similar create_chop_node and create_cop_node tools. It does not explicitly contrast with the generic create_node tool, so it misses the strongest form of sibling differentiation.

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 precondition: call list_node_types(context='Lop', filter='<keyword>') to verify the correct node type, and it names many specialized LOP types the agent might not guess. It does not state when to prefer create_node over this tool, but the usage context is clear.

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

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

With no annotations, the description carries the transparency burden. It discloses that this is a write operation that creates a material in /mat, which is core behavior. It does not mention collision/overwrite behavior, whether a material network is required, or what the tool returns, leaving some behavioral ambiguity.

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

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

The description is front-loaded with a one-line summary and follows with a compact Args block. Every line adds needed value, and there is no filler or repetition of schema defaults beyond useful constraints.

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 no-annotation tool with no output schema, the description is sufficient to invoke correctly, but it is not fully complete: it omits usage alternatives, side effects, and any expected return/confirmation. Missing context is not severe because the parameter semantics are fully covered.

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 compensates fully by documenting all six parameters: name semantics, valid mat_type values ('principled', 'materialx'), base_color format and range, and roughness/metallic/opacity ranges. This goes well beyond the bare input 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 names a specific action ('Create'), resource ('material'), and location ('/mat'), and adds that surface properties are configurable. It is clear enough to separate creation from read-only material tools like list_materials/get_material_info, though it does not explicitly distinguish itself from the sibling create_material_network or assign_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 context is implied: use this when you need to create a new material node in /mat. However, it does not state when to prefer assign_material, create_material_network, or list_material_types, and there are no explicit exclusions or alternative routing.

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 burden of behavioral disclosure, and it does so well: it explains mapping of common keys to shader-specific names, that arbitrary keys must be real parameter names, that lists set the whole parm tuple, and that the reply reports skipped keys with reasons. It does not cover all possible side effects or permissions, but for a create tool the key mutation and failure behavior are disclosed.

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

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

The description is dense but every sentence adds value: scope, parameter mapping behavior, unknown-key handling, and response shape. The Args list is cleanly structured 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?

For a create tool with no annotations and no output schema, the description covers the input semantics and the response enough to call it correctly. Minor gaps such as name-uniqueness expectations or what happens with a null params object are not material to successful 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 coverage is 0%, so the description must compensate; the Args section fully explains name, shader_type (including valid values), and params (name-value pairs, accepted keys, and list semantics). It adds substantial meaning beyond the bare schema types.

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 and target: 'Create a new material network in /mat.' This is a specific verb+resource, and the name/behavior differentiates it from merely assigning materials. However, it does not explicitly distinguish itself from sibling tools like create_material or assign_material, so it misses the full top score.

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 when to use the tool (when creating a material network in /mat) and details accepted parameters, but it does not state when not to use it or mention alternatives. Compared to the calibration example that explicitly routes to a sibling, this leaves the choice to the agent's 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?

With no annotations, the description carries the behavioral disclosure burden. It states that the box is drawn, titled, and fits around the given sibling nodes, implying a visual, non-destructive operation, but it does not mention what is returned, whether the box is a created node, or any side effects on the existing graph.

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, followed by a clean bulleted argument list. Every line adds value, with no filler or redundant restatement of the schema.

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 and all parameters are explained, but there is no output schema and the description omits return behavior, default behavior when node_paths is null, and any constraints or prerequisites. This leaves some uncertainty for an agent trying to confirm successful execution.

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%, and the description compensates by explaining each real parameter: parent_path, node_paths, comment, and color with 'RGB in 0..1.' The inclusion of 'ctx: MCP context' is slightly confusing because ctx is not in the input schema, but the other parameters are meaningfully documented.

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 lead sentence is specific: 'Draw a titled network box around nodes, to document a graph you built.' It names the verb, the object, and the purpose, and clearly distinguishes this from sibling tools like create_sticky_note or set_node_color.

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 phrase 'to document a graph you built' provides a clear context for when the tool is appropriate. It does not explicitly name alternatives or exclusions, but the intended use case is evident from the description.

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 reveals that the tool can create any node type, implying significant flexibility and potential side effects (dependencies on parent path, etc.), but it doesn't explicitly state whether this is destructive or requires specific permissions. It doesn't discuss error cases (e.g., if node_type is invalid) or confirm whether the node is created immediately or requires cooking. Given the lack of annotations, this is a moderate gap, not severe.

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 starts with a clear one-sentence purpose, then provides a context paragraph explaining the importance of checking dedicated nodes, and ends with a parameter list. It is concise with no wasted words; every sentence earns its place, though the parameter list could be a little more compact. Overall, it's efficient and front-loaded with the key guidance.

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 a creation operation with moderate complexity (4 parameters, no enums, no output schema). The description covers the purpose, usage guidance, and parameter semantics, which is sufficient for an agent to call it correctly. It doesn't discuss error handling or return values, but those are not critical given the lack of output schema. The guidance to check list_node_types adds important context that ensures correct usage. This is nearly complete, missing only edge-case 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 coverage is 0%, so the description must compensate. It does, by listing each parameter with a brief explanation: 'parent_path: Parent network path', 'node_type: Node type (e.g. 'geo', 'box', 'grid')', 'name: Node name', 'position: [x, y] network editor position'. This adds meaning beyond what the schema provides (which only has type and default), giving the agent concrete information on how to use each parameter. The examples for node_type are particularly helpful.

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 creates a node inside a parent network, with a specific verb ('Create') and resource ('node'). It also distinguishes itself by referencing the need to check for dedicated node types, which is unique and differentiates it from siblings like create_wrangle or create_vex_expression. The purpose is unambiguous and easy to understand.

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 explicit usage guidance: it instructs the agent to call list_node_types first to verify a dedicated node exists, and explains that Houdini has thousands of nodes with many common operations having dedicated nodes that are better than writing VEX/Python. This explicitly tells when to use this tool and when to prefer alternatives, which is well above average.

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 says the node is created in /out, but does not mention whether the renderer starts, whether name collisions are handled, what the tool returns, or any side effects beyond node creation.

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 purpose is front-loaded in one clear sentence, followed by a compact argument list. It is appropriately sized, though the 'name' line adds little value beyond the schema's parameter name.

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 four-parameter creation tool, the description covers the purpose, location, and input semantics adequately. However, with no annotations or output schema, it leaves gaps around expected return values, failure behavior, and whether the created node is automatically rendered or cooked.

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%, and the description compensates well by listing valid renderer values and clarifying semantic roles like 'Camera node path' and 'Output file path.' Only 'name: Node name' is largely redundant with 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 states a specific verb and resource: 'Create a new render (ROP) node in /out.' This clearly identifies what the tool does and where, and distinguishes it from generic node creation or render configuration siblings like create_node or setup_render.

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?

There is no guidance about when to use this tool versus alternatives. Siblings such as setup_render, start_render, and render_node_network suggest related workflows, but the description does not explain where create_render_node fits or when not to use it.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Add' without mentioning side effects, required permissions, reversibility, or what happens on success. It does not even state whether the tool returns anything or modifies the node in place, which is a significant gap for a mutation tool.

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

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

The description is a standard docstring with a one-line summary and a bulleted arg list. It is concise, front-loaded, and every line contributes. No redundant information, but it could be slightly more structured with parameter groupings or examples.

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 parameters well but omits behavioral context such as return values, error conditions, or side effects. There is no output schema and no annotations, so the agent is left without knowing what to expect after invocation. It also does not clarify when to use this tool versus the plural variant, leaving a gap in decision-making.

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 zero description coverage, so the description must compensate. It provides brief but meaningful explanations for all 7 parameters, including valid values for 'parm_type' and the type restriction for 'min_val'/'max_val' (float/int only). This adds value beyond the schema's bare titles, though it could be more detailed about 'default_value' and format expectations.

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 clear action and target: 'Add a spare parameter to a node.' It is specific and unambiguous. However, it does not explicitly differentiate from the sibling tool 'create_spare_parameters' (plural), leaving the distinction to the name rather than the description.

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_spare_parameters' or general node creation tools. The description lacks any context about scenarios, prerequisites, or constraints that would help an agent decide to use it.

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 discloses the creation behavior, batch nature, folder wrapping option, and parameter types. However, it does not reveal what happens on duplicate parameter names, whether existing parameters are replaced, or what side effects or errors may occur.

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, front-loaded with the core purpose, and uses a clean Args list with no filler. Each line adds necessary information about argument semantics.

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 sufficient to construct a call because all parameters and nested spec keys are documented. However, with no annotations and no output schema, it omits return behavior, error conditions, and prerequisites such as node_path validity or duplicate-name handling, leaving some gap 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, and it largely does. It explains parameters as a list of spec dicts with keys and types, clarifies folder_name behavior, and enumerates folder_type values. Node_path is thinly described as 'Node path', but the nested parameter spec detail is the main value.

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 clear action: 'Batch-create multiple spare parameters in one call', with an optional folder tab. The batch aspect distinguishes it from the sibling create_spare_parameter, so the tool's purpose is unambiguous.

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

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

The phrase 'Batch-create multiple spare parameters in one call' implies the tool is for multi-parameter creation, and a singular sibling exists. However, it never explicitly states when to prefer this over create_spare_parameter, nor does it mention exclusions or prerequisites beyond the arguments.

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 to lean on, so the description must disclose behavior. It only says 'Leave a sticky note' and lists parameters, with no mention of side effects, return behavior, persistence, or error conditions. For a mutating creation tool with zero annotation coverage, that is a clear gap.

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 lean: one purpose sentence followed by a terse, well-aligned arg list. Every line adds information about parameter semantics; there is no filler or repetition. The purpose is front-loaded, and the structure makes the parameter mapping easy to scan.

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 parameter semantics are well covered, and the tool is a simple create operation. However, with no annotations and no output schema, the description should also mention what successful creation looks like or whether parent_path must already exist. It is adequate for basic invocation but not fully contextual.

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 descriptions are entirely empty, so this arg list carries full weight. It explains each parameter: parent_path is 'Network the note lives in,' and it adds units for position and size ('network editor units') and the color range ('RGB in 0..1'). This fully compensates for the 0% schema 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 opens with a specific verb and resource: 'Leave a sticky note in a network.' This clearly identifies what the tool creates and where it acts. Among a large sibling set, this is the only sticky-note creation tool, and the wording distinguishes it from generic node-creation tools like create_node.

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

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

There is no guidance about when to use this tool versus alternatives such as create_node or set_node_color, and no mention of preconditions like parent_path needing to be a valid network. The description gives no when-to-use or when-not-to-use 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 provided, so the description carries the full burden. It fails to disclose whether creating a take modifies the current take, whether it can be undone, or any side effects. It does not state if the tool changes state or just creates a record.

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 a single purpose sentence and a compact Arg list. It is front-loaded with the main verb. However, it could be more structured with clear sections.

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 is incomplete for an agent to understand the result of the operationcars. It does not mention return value, error conditions, or how it interacts with the current take system, which is critical for proper usage.

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 'name' and 'parent_name' briefly, but omits details like the format of parent_name, whether 'current take' is required to exist, and any constraints on names. The description adds minimal value beyond the schema.

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

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

The description clearly states the action (create a take) and the optional parent relationship. It is distinguishable from sibling tools like get_current_take and set_current_take, though it doesn't explicitly name them.

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

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

The description does not specify when to use this tool versus alternatives. It lacks context on whether this is a one-time operation, how it relates to current take, or any prerequisites. No exclusions or alternatives 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?

No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. It only states the action (setting) without mentioning side effects, prerequisites (e.g., whether the parameter must exist), reversibility, or potential errors. For a mutation tool, this is insufficient 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 and well-structured: a one-sentence action statement followed by a clear parameter list. It is front-loaded with the core purpose and avoids unnecessary words, though it could be expanded with useful context without sacrificing brevity.

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 3 required parameters, no annotations, and no output schema, the description omits critical details such as value formats, error conditions, whether the parameter must already exist, and the effect on existing expressions. It is incomplete for an agent to call it correctly without additional inference.

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?

With 0% schema coverage, the description must compensate by explaining parameter semantics, but it merely restates the parameter names with minimal phrases (e.g., 'Path to the node', 'Parameter name', 'VEX expression code') that add little beyond the schema. It does not provide expected formats, examples, or relationships between 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 action: setting a VEX expression on a parameter. It specifies the resource (parameter) and the type of value (VEX expression), which distinguishes it from siblings like set_parameter (generic value) and set_expression (possibly generic expression). The parameter list further reinforces the specific 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 provides no guidance on when to use this tool versus alternatives such as set_expression, validate_vex, or set_parameter. It does not mention any exclusions or conditions for selection, leaving the agent to infer the appropriate context from the name and parameter list 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, the description carries the full behavioral burden and largely meets it by disclosing that this is a last-resort mutation with mandatory justification and clear prohibitions. It does not mention side effects such as existing node overwrite behavior or return values, but it does disclose the high-risk purpose and guardrails effectively.

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 core purpose and the most important constraint ('LAST RESORT), then gives compact, meaningful parameter documentation. The emphatic warnings are repetitive but purposeful and directly prevent misuse rather than padding.

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 no annotations and no output schema, the description covers the main call requirements: when to use, how to justify, and every parameter's meaning. It omits concrete return-value expectations and error behavior, but the usage contract is detailed enough that an agent can invoke and validate appropriately.

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, and it does by explaining all five parameters in the Args list. It adds real value by specifying run_over's allowed values and by detailing exactly what justification must contain, which goes beyond the schema's bare parameter 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 states the specific operation: creating an Attribute Wrangle node with VEX code and immediately scopes VEX to attribute math that no native node expresses. This clearly distinguishes it from generic node creation and from sibling tools like create_vex_expression or set_wrangle_code.

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

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

The description gives explicit when-to-use guidance ('VEX is for attribute math that no node expresses') and explicit when-not-to-use exclusions (never for modeling, scattering, copying, deforming, grouping, or randomizing). It also mandates a justification workflow via list_node_types, giving the agent a concrete decision procedure before invoking the tool.

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 carry behavioral disclosure, but it only restates the action. It does not warn that deletion is destructive/irreversible, state whether the frame must currently have a keyframe, or describe error/return behavior.

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

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

The description is compact and front-loaded, with the action stated before a clean Args block. No extraneous content, though the arg descriptions are so thin that brevity comes at the cost of useful semantics.

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 destructive 3-parameter operation with no annotations and no output schema, the description is too thin. It does not explain prerequisites (e.g., existing keyframe), side effects, or success/failure signals, and it offers no guidance relative to sibling keyframe 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?

The Args section provides one-line glosses ('Node path.', 'Parameter name.', 'Frame number to delete.') that essentially restate parameter names and add little beyond the input schema's types and titles. Since schema description coverage is 0%, the description should compensate with format or value-range details but does not.

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 verb and object: 'Delete a keyframe at a specific frame.' This clearly distinguishes it from the sibling get_keyframes and set_keyframe/set_keyframes tools by naming the delete action and the frame-targeted 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?

There is no guidance about when to choose this tool over siblings. It does not mention that it is for removing an existing keyframe, nor contrast it with set_keyframe or set_keyframes, so the agent is left to infer usage from the name.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Delete a node' and does not disclose side effects such as irreversibility, cascading deletion of children, connection impacts, or error behavior on invalid paths. This is a significant gap for a mutation/destructive tool.

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

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

The description is extremely short and front-loaded, with no filler, but it also includes an 'ctx: MCP context' argument that does not appear in the input schema. This is slightly confusing and reduces the efficiency of the structure.

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 destructive single-parameter operation with no annotations and no output schema, the description is too sparse. An agent is not told what happens after deletion, whether the action is undoable, how to reference nodes reliably, or what errors might arise. More context is needed for safe and 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%, and the description merely restates 'node_path: Node path,' which repeats the schema property name/title without adding format guidance, examples, or path syntax. With no schema descriptions, the description should compensate but does not.

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 and resource: 'Delete a node.' This clearly distinguishes it from sibling node helpers like create_node, rename_node, copy_node, and move_node. Even without an explicit target context, node deletion is 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?

No guidance is given about when to use this tool versus alternatives, or about preconditions/cautions. Given it is a destructive operation, the description should at least warn about irreversibility or mention that it is intended for removing existing nodes from the network, rather than other node operations.

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 carry the behavioral burden. It discloses that remove_outputs will delete files from disk and that the goal is regeneration, but it does not explain side effects such as whether dirtying alone triggers a cook, or what happens to existing cached outputs. The destructive potential of remove_outputs is mentioned but not emphasized.

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-loads the core purpose in a single sentence, followed by a compact parameter list. The ctx line is boilerplate and not exposed as a tool parameter, making it slightly nonessential, but overall the text is efficient with no 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?

For a two-parameter tool without an output schema, the description covers the main action and the optional destructive flag. However, it leaves unclear when regeneration happens, what the tool returns, and whether a subsequent cook step is required, which an agent might need to know for a TOP workflow.

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 is the only source of parameter meaning. It explains node_path as a TOP node path and remove_outputs as 'Also remove output files from disk', which adds real behavioral intent. The line about ctx is irrelevant to the exposed tool schema but does not harm the two actual 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 states a specific action ('Dirty work items') and resource ('on a TOP node'), and clarifies the purpose ('so they can be regenerated'). It is unambiguous among siblings because no other tool performs 'dirtying', though it does not explicitly name alternative 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 purpose implies usage: use this tool when you want to mark TOP work items for regeneration. However, it does not explicitly describe when to choose this over related tools like cook_top_node or generate_static_items, nor does it state any prerequisites 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 for disclosing behavior. It only states the action without mentioning whether disconnecting is destructive, reversible, requires node prerequisites, or has side effects on dependent nodes. This is a significant gap for a mutation tool.

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

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

The description is compact and front-loads the core action, but the 'Args' block mostly duplicates schema property names and includes an extraneous ctx parameter. It is not overly verbose, but has some filler that could be removed.

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 mutation tool with three parameters, no annotations, and no output schema, the description is under-specified. It does not explain the graph-level effect of disconnecting inputs, prerequisites, default handling when both input_index and disconnect_all are provided, or what a successful call returns.

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 lists node_path, input_index, and disconnect_all with terse labels, but does not clarify the relationship between input_index and disconnect_all (e.g., mutual exclusivity, behavior when both are set, meaning of null input_index). It also mentions 'ctx', which is not present in the input schema, adding 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 uses the specific verb 'Disconnect' and clearly identifies the resource as 'one or all inputs of a node', which distinguishes it from sibling tools like connect_nodes and reorder_inputs. The action is immediately understandable.

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

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 vs alternatives such as connect_nodes, reorder_inputs, or set_node_flags. An agent is left to infer the appropriate context from the tool name alone.

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

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

With no annotations, the description carries full behavioral burden, and it excels: it discloses the atomic write-once semantics, copy-and-collision-check, the reinstatement behavior for built-in parameters (including the `reinstated_by_houdini` reply), and the dry_run mode. This far exceeds what a typical descriptionsafe.

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?

Although long, the description is structured with a clear positional summary, a list of ops, and an Args block. Every segment earns its place: the atomic behavior, the alternatives comparison, the op syntax, edge cases like built-in parameters. It is front-loaded with purpose and semantics, then dives into necessary detail.

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?

There is no output schema, but the description explains the only output detail needed: the possibility of `reinstated_by_houdini` in the reply. It covers prerequisites, atomicity, naming conventions, folder addressing, and all known edge cases. Nothing essential is missing for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is 0%, but the description compensates completely. It explains node_path as 'an instance of the HDA whose definition is edited', ops as 'Operations, in order', and dry_run as 'Validate and report the plan without writing.' It then documents every operation structure in detail (insert, remove, hide/show, replace, modify, move) with nested fields and aliases.

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 verb-resource statement: 'Edit an HDA's EXISTING Type Properties interface' and enumerates the exact operations: insert, remove, hide/show, replace, modify, move. It explicitly contrasts itself with set_hda_interface ('only appends'), making sibling distinction immediate.

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 gives direct guidance: 'set_hda_interface only appends' implies this tool is for modifying existing interfaces. It also instructs the agent to 'Read the interface first with get_parm_template_tree', a concrete prerequisite. The description also clarifies atomic behavior, which directly informs when this is the right call.

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 fully disclose behavior. It only says 'evaluate an expression' and 'return its result,' but does not mention potential side effects, whether the expression can modify the scene, error handling, security implications, or the nature of the returned result. This is insufficient for a tool that likely executes arbitrary code.

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 concise: one sentence for the purpose and a short Args list. It is front-loaded with the core function and has no redundant information. Every word earns 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?

The tool lacks an output schema, so the description must explain what the result looks like, but it only says 'return its result.' It also does not address safety, error conditions, or how it relates to sibling execution tools. For a potentially powerful operation, this is incomplete.

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 beyond the schema by specifying that 'language' accepts 'hscript' or 'python' (the schema only has a string type and default). It also clarifies that 'expression' is a string to evaluate. This is useful, though it does not provide examples or edge-case details.

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: 'Evaluate an expression in Houdini and return its result.' It identifies the resource (expressions in Houdini) and the verb (evaluate). However, it does not differentiate from sibling tools like execute_python or execute_hscript, which also run code in Houdini, so it's clear but not fully distinguishing.

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

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

There is no guidance on when to use this tool versus alternatives. It does not mention the existence of execute_python, execute_hscript, or set_expression, nor does it explain how evaluation differs from execution or expression setting. An agent must infer the appropriate context without any explicit instructions.

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 must carry the full burden of behavioral disclosure. It does not mention any side effects, such as whether the command can modify the scene, require authentication, or how errors are handled. The description only states that it executes a command, offering minimal insight into its behavior.

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 concise, with only two short sentences. It is front-loaded with the core purpose and provides a parameter description. There is no fluff, but perhaps it is too brief to be helpful.

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 the tool having only one parameter and no output schema, the description lacks essential context. There is no mention of use cases, potential risks, or examples, making it hard for an agent to know how to use it effectively, especially given the large number of sibling tools with overlapping capabilities.

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%, and the description only provides a one-line summary of the 'command' parameter ('HScript command string to execute.'). This duplicates the schema's property name and type, adding no extra meaning about expected format, syntax, or examples. The agent receives no guidance on how to construct a valid HScript command.

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 it executes an HScript command in Houdini, which is a clear verb-resource pair. However, it does not differentiate from sibling tools like execute_python or evaluate_expression, which may be used for similar scripting purposes. The purpose is clear but not 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 lacks any guidance on when to use this tool versus alternatives like execute_python or evaluate_expression. There is no mention of typical use cases or reasons to prefer HScript over other scripting options, leaving the agent to infer the 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 provided, so the description must carry the full burden of behavioral disclosure. It clearly states that execution is arbitrary and implies full Houdini access, but it does not describe side effects, failure modes, or the scope of state changes (e.g., that it can permanently modify the scene). It sets expectations for when to use it but not what executing the code actually entails beyond 'execute arbitrary Python code.' A more explicit warning about potential destructive actions would raise this score.

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 a bolded opening statement, bullet-point exclusions, and a clear 'Args' section. Every sentence adds value – there is no filler. It front-loads the purpose and constraints, making it easy to scan. The length is justified by the complexity of the tool's usage rules.

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 purpose, exclusions, and parameter semantics thoroughly. It could add more on error handling or the execution environment (e.g., 'runs in the current Houdini session'), but for a generic escape-hatch tool, it provides sufficient context for correct invocation. The mandatory justification parameter reinforces the complete usage model.

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 explain all parameters. It does so comprehensively: 'code' is described as 'Python source code to execute,' 'justification' as 'Which dedicated tools you considered and why none covers this operation,' and 'return_expression' as 'Python expression to evaluate after execution.' Each parameter gets a clear, meaningful explanation beyond the schema's bare 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 opens with 'Execute arbitrary Python code inside Houdini' – a specific verb, resource, and scope. It clearly distinguishes itself from the many sibling tools by explicitly stating it is a last resort and listing what it is NOT for (creating nodes, setting parameters, etc.), which makes its unique purpose unmistakable.

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 'DO NOT use this to' list names the exact dedicated alternatives for common operations, and the 'ONLY use this when' clause states the condition for legitimate use. It also requires a justification parameter that forces the agent to explicitly consider alternatives, which is exemplary usage 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 responsibility for behavioral disclosure. It only mentions the action and the parameter, with no details about what 'explain' produces (e.g., a summary, a detailed report), whether it performs side effects, or performance implications. This is insufficient for a tool that likely executes complex logic.

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 and to the point, with no filler. It front-loads the main action and then lists the parameter. However, it is somewhat under-specified for the complexity of the tool, but it earns a 4 for conciseness and 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 has one parameter, no annotations, and no output schema, the description should provide more context about what the output looks like and any constraints. The current description is minimal, leaving the agent unsure about the return format and path requirements, making it incomplete for effective 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?

The schema has 0% description coverage and the parameter is only a bare string. The description merely repeats 'node_path' without adding any meaning about the expected format, such as absolute vs. relative paths, or whether it refers to a Houdini path. This is a serious shortfall.

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 clear action ('Explain a node in human-readable form') and names the resource (node). It is distinguishable from siblings like get_node_info and get_node_card, which presumably retrieve raw data, though it does not 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios where a human-readable explanation is preferable to raw node info, nor does it reference other tools for comparison. This is a clear gap.

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 hints that the target parameter receives a chop() expression but doesn't disclose that existing values/expressions are overwritten, that the CHOP path/channel must exist, or that the parameter is mutated. Critically important behavior is left out.

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: one intro line followed by a structured argument list. No redundant filler. It earns its place but omits additional needed context.

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 mutation tool with four string parameters and no annotations, the description is too shallow. It doesn't cover prerequisites, side effects, or failure modes, and with no output schema, the agent has to guess the result shape and error conditions.

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 argument list adds minimal meaning beyond the parameter names (e.g., 'channel_name: Channel to export' restates the name). Only 'target_parm_name' gets a slightly more informative note. This is not enough to truly explain inputs.

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?

States the operation clearly: exports a CHOP channel to a parameter via a chop() expression. The verb, resource, and mechanism are specific enough to identify the tool, though it doesn't explicitly contrast it with 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?

No usage guidance is provided. The description doesn't say when to use this tool over alternatives like set_parameter, set_expression, or link_parameters, and it gives no conditions, exclusions, or prerequisite 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?

With no annotations provided, the description fully carries the burden. It discloses side effects: writing files to disk, temporarily overriding a ROP output parameter and restoring it, writing per-frame files, leaving the playbar unchanged, and the meaning of success via 'wrote_files'. This is exemplary 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 front-loaded with the main purpose, then methodically covers node-type behavior, return semantics, frame behavior, and arguments. Every sentence contributes necessary information; nothing is redundant or filler. It is dense but 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 there is no output schema and no annotations, the description covers the critical operational details: what gets written, side effects, restoration behavior, per-frame output naming, and success semantics. An agent has everything needed to call the tool correctly and interpret its result.

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, and it does. It explains node_path as the node to export, file_path as the destination and ROP override, and frame_range as [start, end] or [start, end, step]. This adds real meaning beyond the bare schema types and 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 opens with a specific verb and resource: 'Export a node's output to a file on disk.' It then clarifies the three node-type variants (SOP, LOP, ROP), which clearly distinguishes this from file-import, save-scene, and cache-writing siblings. An agent can grasp exactly what this tool does without ambiguity.

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

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

The description gives clear situational context by explaining how behavior differs for SOPs, LOPs, and /out ROPs, and notes the effect of frame_range. It does not explicitly name alternative tools or state 'when not to use this,' but the contextual detail is strong enough to guide selection. A small deduction for not stating exclusions or calling out a sibling alternative.

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 only states the function and the root_path argument, but does not explain whether the search is recursive, whether the root itself is included, what the return format is (e.g., list of paths), or if there are side effects. This is minimal for a search 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 concise and directly front-loaded with the primary action. The Args section is clearly delineated and adds no fluff. Every sentence earns its place, though the brevity sacrifices useful detail.

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 simplicity (one optional parameter) and lack of output schema, the description is incomplete. It does not specify the return value structure (e.g., paths, names, error types), which is critical for an agent to use the result. It also omits whether the search is recursive or how warnings are differentiated from errors. More context is needed for reliable 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. The 'Args' section provides a brief explanation: 'root_path: Root node path to search from.' This adds semantic meaning beyond the schema's type and default, clarifying what the parameter does. However, it is minimal and does not discuss optionality or expected format nuances.

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 purpose: 'Find all nodes with errors or warnings in the scene.' This gives a specific verb, resource, and scope. It does not explicitly distinguish from siblings like get_node_errors_detailed or find_nodes, but the intent is unambiguous enough for an agent to understand what it 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?

There is no guidance on when to use this tool versus alternatives such as get_node_errors_detailed or find_nodes. The description lacks any 'when to use' or 'when not to use' context, leaving the agent to infer appropriateness based solely on the tool's name and generic description.

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 disclose important behavior: it 'Records a performance-monitor profile while force-cooking the display outputs' and clarifies that cook_ms includes parent+child times. This is valuable contextual information beyond the parameter schema, though it omits details like exact response shape or side effects on the scene.

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 and front-loaded with the core purpose, followed by behavioral detail and an Args list. Each sentence contributes useful information, though the analogy 'how a senior artist finds the slow node instead of guessing' is a slight flourish rather than strictly necessary.

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 there is no output schema, the description explains the tool's behavior, parameter meanings, and the key 'cook_ms is cumulative' interpretation rule. It is largely complete for an AI to call and use this tool, though it could provide a little more detail about the exact return structure beyond ranking.

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 compensates fully by explaining every parameter in the Args section: root_path, frame, and limit. It adds practical semantics such as 'a geo container, or "/" broadly' and 'Optionally jump to this frame before cooking,' which goes well beyond the bare 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 a specific action: 'Profile cooking and rank the most expensive nodes' with a concrete resource ('display outputs under root_path'). It is distinct from siblings like find_error_nodes and get_cook_chain because it focuses on cost profiling, though it never explicitly names or contrasts with any sibling tool.

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 communicates when to use the tool: when a senior artist needs to find the slow node instead of guessing, and it explains how to interpret results by comparing siblings because cook_ms is cumulative. However, it does not explicitly mention alternatives or when not to use this tool.

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 disclosure. It mentions the max_results parameter but does not explain behavior such as how points are ordered (by distance ascending?), whether ties are broken, or what happens if no points are found. It also does not state whether this is a read-only operation, which is critical given the tool's name suggests a query. There is no indication of computational cost or any side effects.

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

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

The description is concise and front-loads the core purpose. It uses a clear sentence followed by a parameter list in a structured format, which is easy to parse. There is no filler or redundant information, and it stays focused on the essential parameters. However, it could be slightly more informative within the same 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?

Given that the tool has 3 parameters, 2 required, and no output schema, the description is insufficient for an agent to correctly interpret the return value. The description does not specify whether the return is a list of point positions, indices, or distances. It also does not clarify whether the position parameter is in world space or local space, which is a common source of errors. The tool is relatively simple, but for a query that returns spatial data, the return type and units are essential context.

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, meaning the schema itself provides no additional documentation beyond types and default values. The description repeats the parameter names and types, but it adds minimal semantic meaning: 'position' is clarified as [x, y, z], and 'max_results' is described as max nearest points. However, it fails to explain the exact format of the output, such as whether it returns points or indices, which is crucial for an agent to use the result correctly. Since the schema is minimal, the description should compensate more, but it does not go beyond restating the obvious.

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 purpose: finding nearest points to a given position. It uses a specific verb ('find') and a clear resource ('point(s)'), and the title matches the function. Although there are many sibling tools with similar spatial querying functions (e.g., sample_geometry, get_points), this description distinguishes it enough, as it focuses on 'nearest' rather than general geometry access.

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?

There is no guidance on when to use this tool instead of alternatives like sample_geometry or get_points. The description does not mention any context, such as 'Use when you need to find points within a distance threshold' or 'alternative tools for other spatial queries.' This lack of comparative guidance leaves the agent to infer usage from the name alone.

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

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

With no annotations, the description must disclose behavior on its own. It explicitly warns about the performance/result-size consequences of unfiltered searches, which is the main behavioral risk. It also implicitly suggests this is a read-only search operation. A more detailed mention of output format would raise this further, but the key behavioral trap is covered.

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

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

The description is compact and efficiently structured: a one-sentence summary, a usage guideline with a warning, and a clear args list. The critical narrowing advice is front-loaded before parameter details alerting the agent to the main pitfall. No redundant or filler sentences.

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 four optional parameters and no output schema, the description covers all invocation requirements: filter semantics, scoping, and a warning about broad searches. It does not specify the return structure, but as a search tool that is presumed a list of nodes; this minor omission prevents 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?

Schema description coverage is 0%, so the description fully compensates. It explains each parameter in plain terms: pattern as a glob (with example 'box*'), node_type as a type filter (e.g., 'box', 'null'), context as a category filter (e.g., 'Sop'), and inside as the root path for scoping. This is far richer than the bare schema titles.

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 'Search' with a clear resource ('nodes') and explicit filter dimensions (name pattern, type, context). It clearly distinguishes itself from sibling search tools like find_error_nodes, find_expensive_nodes, and find_usd_prims by focusing on generic node discovery via structural filters.

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 concrete guidance: use 'inside' to scope searches, and supply at least one of three filters. It warns against unfiltered searches from '/' citing the risk of hundreds of results, giving the agent an implicit rule for safe invocation. It doesn't explicitly mention when to prefer alternative search tools, but the criteria are clear enough for correct use.

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, but it only states 'Search USD prims by path pattern' without disclosing return values, search scope, case sensitivity, handling of no matches, or whether results are prim paths or prim data. The read-only nature is implied but not 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 minimal and well-structured: a one-sentence summary followed by a concise Args list. Every sentence adds value, and the essential information is front-loaded.

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 with two required parameters, and the description covers both parameters adequately. However, without an output schema or annotations, the missing return behavior (list of paths vs prims, empty result behavior) leaves a notable gap for an agent 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%, but the description's Args section adds meaningful semantics: 'node_path' is clarified as 'LOP node path' and 'pattern' is expanded with 'Glob pattern (supports *, **) or substring'. This compensates well for the schema's lack of descriptions.

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

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

The description clearly states the tool searches USD prims by path pattern, with a specific verb ('Search'), resource ('USD prims'), and mechanism ('path pattern'). It distinguishes itself from siblings like list_usd_prims through the pattern-based scope, though it does not explicitly name alternatives.

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

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

No explicit guidance is given on when to use this tool versus siblings such as get_usd_prim or list_usd_prims. The usage context is only implied by the name and the short description; there are no when-not-to-use instructions or alternative recommendations.

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 disclose side effects itself, but it says nothing about whether the viewport camera is modified, whether the scene is changed, or what the operation's consequences are. It merely restates the action without behavioral detail.

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

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

The text is very short and front-loaded, with no filler words; the Args section is a conventional, structured addition. Its brevity is appropriate for the simple operation, though it leaves other dimensions under-specified.

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 1-parameter tool with no annotations and no output schema, the description gives only the action and a minimal parameter hint. It omits practical details such as what happens when pane_name is omitted, which pane is affected, and whether any return value is produced.

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's 'Args: pane_name: Pane tab name.' is the only explanation of the parameter. It adds a label but does not clarify valid values, formatting, or what null/default means.

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 verb ('Frame') and resource ('all geometry in the viewport'), which clearly distinguishes it from the sibling tool frame_selection. It does not explicitly name an alternative, but the scope ('all geometry') makes the contrast evident.

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 frame_selection or set_viewport_camera. The only additional line documents the pane_name argument, with no context on selection criteria 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 the full burden of behavioral disclosure. It only states the action without clarifying side effects, prerequisites (e.g., whether a selection must exist), or what happens in the viewport. The description does not contradict annotations (none exist), but it is too terse to be 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, focused sentence followed by a minimal argument spec. It is front-loaded and contains no fluff, earning high marks for conciseness and structure.

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 action, the description is incomplete. It does not explain what 'frame' does, whether it changes the camera, whether a selection is required, or the effect of omitting pane_name. The lack of output schema and annotations means the description alone must cover these details, and it does not.

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 provides a basic label for pane_name ('Pane tab name') but does not explain its role, valid values, or default behavior when omitted. This adds minimal meaning beyond the schema's type definition, falling short of full compensation for the coverage 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 (frame), resource (current selection), and location (viewport). It clearly distinguishes from frame_all by specifying it operates on the current selection, so an agent can tell them apart.

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 on when to use this tool versus alternatives like frame_all or other viewport controls. The description does not mention exclusions or conditions under which this should be preferred, leaving the agent to infer 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?

No annotations are provided, so the description carries the full burden. It discloses that it generates static work items without cooking, but does not mention side effects, whether existing items are replaced, what happens to the node state, return values, or error conditions. This is minimal 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 very concise, with the main action front-loaded. The args section is redundant with the schema and includes 'ctx' which is not in the input schema, potentially confusing agents, but overall it is efficient and to the point.

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 no output schema and no annotations, the description is insufficient. It omits return value, side effects, prerequisites (e.g., node must exist and be a TOP node), and any error handling. For a mutation-like tool, this is a significant gap in completeness.

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?

With only one parameter and schema coverage at 0%, the description adds a small amount of specificity by stating 'TOP node path,' which is slightly more informative than the schema's generic 'Node Path' title. However, it does not add meaningful depth beyond the schema and leaves the parameter semantics mostly implicit.

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 (generate static work items) and the resource (TOP node), and explicitly notes 'without cooking,' which differentiates it from cooking-related siblings like cook_top_node. It is not a tautology and provides a specific verb-resource pair.

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 phrase 'without cooking' implies a use case (pre-generating items without triggering a cook), but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The guidance is only implied, not 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 provided, the description carries the behavioral disclosure burden. It clearly discloses that the tool aggregates numeric statistics, and it adds a non-obvious behavioral nuance: vector attributes report per-component ranges. It could also mention handling of non-numeric attributes or failure cases, but the provided behavioral context is strong.

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, well-structured, and every sentence adds value: the operation, the usage rationale, sibling differentiation, vector behavior, and parameter documentation. The 60k-cache example is vivid but earns its place by illustrating the tool's 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?

Given the simple parameter set and no output schema, the description covers the core outcome—statistics values and vector per-component behavior—as well as the full parameter semantics and usage context. It does not specify the exact return format, but for a stats tool this is a minor gap, not a completeness failure.

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 fully compensates by documenting all three parameters: node_path, attribs, and attrib_class. It clarifies that attribs can be omitted to select every attribute of the class and enumerates valid attrib_class values. This is complete parameter-level guidance beyond the bare 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 opens with a specific verb and resource: 'Aggregate statistics for numeric attributes: min, max, mean, sum.' It explicitly distinguishes itself from siblings like get_geometry_info and get_attrib_values, so an agent knows exactly what this tool does and how it differs.

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 when to use this tool ('Use this to prove something is happening') and contrasts it with alternatives, explaining why get_geometry_info and get_attrib_values are less appropriate, including a concrete cache-size example. This is explicit routing guidance rather than leaving the agent to infer.

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 of behavioral disclosure. It only states 'Get metadata' without describing what metadata is returned, whether the operation is read-only, what happens if the attribute does not exist, or what the response structure looks like. This is a minimal description with significant behavioral gaps.

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

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

The description is compact and front-loaded with the core purpose. The Args block is a clean, minimal list with no redundant prose. Every line is necessary, and there is no 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?

With no output schema and no annotations, an agent needs more context to invoke this correctly: what 'metadata' includes, the expected return shape, and whether the node path refers to a SOP node, OBJ node, or something else. The description provides only parameter labels and default class options, leaving key operational details undocumented.

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 all three parameters and adds the allowed values for attrib_class ('point', 'prim', 'vertex', or 'detail'), which the schema does not provide as an enum. However, node_path and attrib_name explanations merely repeat the schema titles and provide no additional semantics such as path format or naming rules.

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 and resource: 'Get metadata for a geometry attribute.' This clearly states the tool's function and differentiates it from tools that retrieve geometry itself (get_points, get_prims, get_geometry_info). However, 'metadata' is somewhat vague and no distinction is made from get_attrib_stats or get_attrib_values, so it does not fully stand apart from all siblings.

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 when-to-use or when-not-to-use guidance is given. There are no explicit alternatives or conditions for choosing this tool over get_attrib_stats, get_attrib_values, or get_prim_intrinsics. The usage context is only implied by the tool's name and one-line purpose.

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 discloses pagination behavior (check has_more, increment start), element-major ordering for float3 attributes, and the default page size. This goes beyond a simple 'read' statement and gives the agent actionable behavioral context. It doesn't mention error cases or performance characteristics, but the disclosed behaviors are substantial.

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: the core behavior is stated in the first sentence, the alternative is named immediately, and the pagination detail is explained before the Args block. Every sentence earns its place, and the Args list is cleanly formatted.

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 tool with 5 parameters and no output schema, the description covers the key operational details: pagination, element-major ordering, and the default count. It doesn't describe the exact return shape (e.g., JSON structure of has_more), but the description explicitly references has_more and start, which is enough for an agent to page through results. The main gap is not describing what the response object looks like, but the description's explicit mention of has_more and start mitigates that.

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: it explains start as 'First element index to return', count as 'Max elements per page (default 200)', and attrib_class with the valid values 'point', 'prim', 'vertex', or 'detail'. This adds meaning beyond the bare schema, though it doesn't elaborate on node_path or attrib_name beyond their 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 reads attribute values as a flat array with pagination, and explicitly contrasts it with sample_geometry for spot-checking. It names the specific resource (attribute values) and the operation (read), making it distinguishable from siblings like get_attrib_stats or sample_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 gives explicit guidance: prefer sample_geometry for spot-checking a few values, and use get_attrib_values when you need a specific slice of one attribute. This directly tells an agent when to use this tool versus an alternative, which is exactly what usage guidelines should do.

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 bears the full burden of disclosing behavior. It implies a read-only operation via 'Get' and clarifies the data source, but it does not disclose coordinate space, units, whether cooking occurs, failure behavior for invalid paths, or whether the node must be cooked beforehand.

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 purpose sentence is front-loaded and concise, but the Args section is redundant with the schema and adds no value. It is not bloated, yet the redundancy prevents a higher score.

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 output schema and no annotations, the description is too thin. It does not specify what the returned bounding box looks like (min/max, center/size), what units or space it uses, or how errors like missing geometry are handled, so an agent cannot fully predict the tool's behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.