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 non-obvious behavior: the source-mode differences, that map_joints remaps Mixamo-like names onto the capture skeleton, and that proof hashes deform geometry at clip start vs end and must differ. It omits scene-mutation/idempotency and error behavior, but adds substantial context beyond the schema.

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

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

Front-loaded with the core transformation, then four tightly packed lines that each add distinct information. The telegraphic arrow/fragment style is efficient but occasionally cryptic, costing a little readability without wasting space.

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?

An output schema exists so return values need not be explained. For a 9-parameter, zero-coverage tool the description covers the key mode selection and behavioral flags well, though it lacks prerequisites (e.g. an existing capture/skin) and full parameter mapping.

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

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

Schema description coverage is 0%, so the description must compensate. It explains source, map_joints, and proof semantics, and ties rest_path/capture_path/anim_path to the source='nodes' mode, plus 'under mcp_*' hints at name/parent_path. It leaves clip and parent_path largely unaddressed, but covers most of the 9 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?

States a specific verb and composite resource: 'Skin + capture pose + clip → kinefx::jointdeform'. An agent can tell this builds a deform node from three inputs, distinct from siblings like import_fbx_animation or map_kinefx_joints. The arrow notation is jargon-dense but still conveys the 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?

Gives conditional guidance on the two operating modes via source ('capybara' uses a testgeometry pipeline; 'nodes' wires explicit paths), which tells the agent which path to take. It stops short of naming sibling alternatives or stating exclusions, so it is clear context without explicit when-not guidance.

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

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

With no annotations, the description carries the full burden and largely succeeds: it discloses validation ordering ('unknown command types are rejected before anything runs'), non-atomic behavior ('Not a transaction'), partial-application semantics, and the exact error fields to check before retrying. This is rich failure-mode disclosure; it only lacks details on undo-group scope and any return format beyond the error fields, which the output schema covers.

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 scope-defining sentence is front-loaded, the example is compact, and the caveat paragraph is dense with no filler. Every sentence carries distinct information (purpose, payload shape, failure semantics) and 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 batch tool with a free-form schema, an output schema (so return format needn't be described), and no annotations, the description covers purpose, payload shape, and error semantics well. The one notable gap is that the set of valid operation types is never listed or referenced, leaving the agent to guess which 'types' will be accepted.

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

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

Schema coverage is 0% and the single 'operations' parameter is a free-form array, so the description is the only source of structure. It supplies the critical per-item shape ({"type": ..., "params": {...}}) but does not enumerate the valid operation types, which is the key semantic question raised by 'Unknown command types are rejected'.

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 ('Execute'), resource ('multiple operations'), and an unusual scope modifier ('in one undo group') that clearly distinguishes it from the single-operation siblings like create_node, delete_node, and modify_node. The name 'batch' plus this scope leaves no ambiguity about what the tool does.

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

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

Usage is implied by the batch semantics and the 'Not a transaction' note, so an agent can infer this is for grouping many mutations under one undo step. However, it never explicitly says when to prefer this over calling create_node/connect_nodes individually, nor does it state any prerequisite or precondition for batching.

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 does disclose a meaningful behavioral trait — that the capture happens at the OS level and does not run inside houdini-bin — but says nothing about resolution, output format, or where the file lands when output_path is omitted.

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

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

Two compact sentences with the scoping and alternative front-loaded; minimal waste. The parenthetical 'does not run inside houdini-bin' is a bit awkwardly placed but informative.

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?

An output schema exists, so return values need not be explained, and the when-to-use/alternative guidance is present. However, the sole parameter (output_path) is undocumented and the description omits output location/format details an agent needs to call 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% and the description never mentions output_path, so it adds no meaning beyond the bare parameter name. For a single param at 0% coverage, the description should compensate and 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?

States a specific verb+resource (grab the Houdini window from the OS) and explicitly differentiates from the sibling capture_screenshot, which an agent could otherwise confuse it with. Slightly ambiguous whether 'desktop' means the full screen or just the window, but the intent is 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?

Gives an explicit use case ('verify network editor / UI') and names the alternative with the condition that selects it ('viewport beauty should use capture_screenshot instead'), so the agent knows when to route elsewhere. No exclusions beyond that binary split, but the primary routing decision is covered.

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 well: it discloses that 'viewport' does not wait for Karma XPU to converge and restores renderer pause, that 'opengl' is OBJ-centric beauty, and that capture_desktop runs outside houdini-bin. It does not state permission requirements or what happens when output_path is omitted or unwritable, so it stops short of 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?

Front-loads the core action, then uses short line-per-mode structure with zero filler. Every sentence either describes a mode, an alternative, or the return shape.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

No output schema exists, and the description compensates by stating the return contract ('JSON metadata plus an MCP image of the PNG. Path is still in the JSON'). Combined with the mode semantics and the desktop alternative, an agent has enough to call it, though the unaddressed 'viewer' and 'output_path' parameters leave a small gap.

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

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

Schema coverage is 0%, so the description must compensate, and it only partially does: 'source' values are explained, but 'viewer' is never mentioned and 'output_path' is only hinted at ('Path is still in the JSON') without saying whether it writes a file or where defaults land. Two of three parameters remain semantically opaque.

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 ('Capture the current Scene Viewer and return the pixels in-band') and immediately differentiates its two operating modes. It also names the sibling it is not (capture_desktop) for desktop/UI grabs, so an agent can route correctly without opening schemas.

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?

Gives explicit selection criteria for each source value ('viewport' = flipbook snapshot of current Hydra buffer, 'opengl' = OpenGL ROP OBJ-centric beauty) and an explicit alternative with its own precondition for the desktop case. The when-to-use branching is fully spelled out.

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 behavioral burden for a mutation operation. It does not say whether connecting overwrites an existing input connection, whether the operation is idempotent or errors on invalid paths, or anything about permissions/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?

A single front-loaded sentence with no filler; the arrow notation packs the data-flow meaning efficiently. It is not padded, though the extreme brevity leaves content gaps addressed under other dimensions.

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?

An output schema exists so return values need not be explained, and the core operation is stated. However, for a mutation tool with zero annotations and zero parameter documentation, the description omits connection-replacement semantics, error behavior, and any usage context, leaving material gaps.

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

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

Schema description coverage is 0%, so all four parameters are undocumented in structured fields. The description partially compensates by establishing direction semantics (src output -> dst input), hinting at the role of src_path/dst_path and the two index parameters, but adds no detail on path format, index bounds, or defaults.

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 concrete verb (connect) and resource (two nodes), with an arrow diagram clarifying directionality of the data flow. It is distinguishable from the sibling disconnect_node_input, though it does not name or contrast with it explicitly.

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 disconnect_node_input, create_node, or modify_node, and no prerequisites (e.g., whether both nodes must already exist or be in the same network).

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 — and it discloses nothing about permissions, side effects on the scene, whether the node is created inside the currently selected network, or what is returned. 'Create' at least implies a mutation, but no trait beyond that is conveyed.

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 single sentence is short and front-loaded, but its brevity reflects under-specification rather than economy — there is no content to be concise about. Nothing here earns its place beyond the 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 three-parameter mutation tool with no annotations and 0% schema description coverage, the description is far too thin. The presence of an output schema excuses it from explaining return values, but it still leaves the agent without the path format, valid node types, or creation semantics needed to call 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% and the description mentions none of the three parameters (parent_path, node_type, name). With two required parameters whose formats (path syntax, valid node type strings) are entirely undocumented anywhere, the description fails to compensate.

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 'Create a LOP node' essentially restates the tool name and title, adding only the acronym expansion (LOP). It gives a verb and a resource but offers no scope, no distinction from siblings like create_node or modify_node, and no indication of what a LOP node is in this context.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as create_node, even though that sibling likely overlaps heavily. An agent has no basis for choosing between them.

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

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

With no annotations, the description must disclose behavioral implications. The single sentence only says 'Create a new node' and gives no information about side effects, required permissions, or how the node is positioned or connected. Only the input schema suggests parent_path, but the description does not elaborate.

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

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

The description is concise in the sense of being short, but it is under-specified and omits essential context. It is more of a placeholder than a well-structured description, and the single sentence does not earn its place as a useful guide.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

Given the tool's multiple parameters and lack of annotations, the description is highly incomplete. It does not explain the role of parent_path or name, nor how node_type works. An output schema exists, but the description still leaves significant gaps in understanding the tool's behavior.

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

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

The schema defines name, node_type, and parent_path, but the description does not mention any of them. Since schema description coverage is 0%, the description fails to add semantic meaning beyond the raw field names.

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

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

The description clearly states the tool's function: creating a node in Houdini. It uses a specific verb and resource. However, it does not distinguish itself from other creation tools such as create_wrangle or create_cop_node, which also create nodes.

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

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

No usage guidance is provided. The description does not explain when to use create_node versus other tools, nor does it mention any prerequisites or alternatives. This leaves the agent without direction for tool selection.

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

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

No annotations are provided, so the description carries the full burden for a destructive mutation. It does not say whether deletion is permanent/undoable, whether child nodes are deleted with the parent, what happens on an invalid path, or what the response contains. Only the implicit 'delete' semantics signal destructiveness.

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?

A single short sentence with the resource and identifier front-loaded and no wasted words. Its brevity is efficient, though it borders on under-specification rather than true conciseness.

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?

An output schema exists, so return values need not be explained, but for a destructive tool with zero annotation coverage the description omits critical context: path format, child-node handling, and failure behavior. Given the rich sibling set, it does too little to help an agent call 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 for the single 'path' parameter. 'By path' merely restates the parameter name and adds no format or syntax detail (e.g. whether it is an absolute Houdini node path like /obj/geo1/box1), leaving the gap largely unfilled.

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 ('Delete a node') plus the domain ('Houdini scene'), which clearly separates it from siblings like create_node and modify_node. It stops short of explicitly naming those alternatives, so it is clear but not fully sibling-differentiating.

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 no when-to-use context, no prerequisites, and does not point to any alternative or related tool. An agent must infer entirely from the name that this is the counterpart to create_node.

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, and it does little: it does not say whether the disconnect is reversible, whether it errors when nothing is connected, whether the node must be cooked or locked, or if any permissions/state constraints apply. An output schema exists, so return values need not be described, but the mutation semantics are unexplained.

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?

A single front-loaded sentence with no filler or redundancy. It is efficient, though the brevity borders on under-specification for a mutation tool rather than being a model of conciseness.

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 zero annotation coverage, no parameter descriptions, and no usage guidance, the description is too thin. The presence of an output schema removes the need to document returns, but preconditions and mutation effects remain unstated.

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% for two parameters. The description implies 'specific input' maps to input_index and 'node' maps to node_path, but it never explains path format, indexing base, or the meaning of the default of 0. It adds only marginal meaning beyond the 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 gives a specific verb ('Disconnect') and resource ('a specific input on a node'), so the agent knows exactly what operation is performed. It is clearly distinct from siblings like connect_nodes, but it never names or contrasts them explicitly, which keeps it short of a 5.

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

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

There is no guidance on when to use this versus connect_nodes or modify_node, no prerequisites, and no note about error conditions (e.g. what happens if the input index is not currently connected). Usage must be inferred entirely 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?

No annotations are provided, so the description carries the full behavioral burden, and it says almost nothing. It does not disclose which expression languages work, whether evaluation has side effects on the scene, or any security/permission constraints beyond the bare 'return the result'.

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?

One efficient, front-loaded sentence with no filler. It is arguably under-specified rather than overly verbose, but structure-wise it wastes nothing.

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 an output schema present, return values needn't be explained, but the two undocumented parameters and lack of any language/context information leave the definition too thin for an agent to call this correctly alongside several script-execution siblings.

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 not. The 'language' parameter (defaulting to hscript) is never explained, and the accepted format or alternatives for 'expression' are left unspecified.

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+resource: 'Evaluate a Houdini expression and return the result.' An agent can tell it evaluates expressions rather than executing raw code, but the description does nothing to distinguish it from the close sibling execute_hscript.

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 guidance at all. With execute_hscript, execute_houdini_code, and batch in the sibling set, the description never says when evaluating an expression is preferred over running a script.

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 does well: it discloses that returns include status plus stdout/stderr, and that dangerous patterns (hou.exit, os.remove, subprocess) are blocked unless allow_dangerous=True. This is meaningful safety-mechanism disclosure. It omits permission/auth requirements, but overall it covers more than most code-execution tools.

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

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

Three tight sentences, front-loaded with the core action, then return behavior, then the safety constraint. Every sentence earns its place with 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?

An output schema exists, so return-value detail is largely optional, yet the description still summarizes stdout/stderr/status. For an arbitrary-code-execution tool with zero annotations, the safety disclosure plus param explanation makes it essentially usable; only the missing alternative routing and permission context keep it from a 5.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain allow_dangerous precisely (unlocks blocked dangerous patterns), which is its main value. The 'code' parameter is self-evident by name, but the description adds no syntax or format guidance for it. Adequate but not complete against a 0% coverage baseline.

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: 'Execute arbitrary Python code in Houdini's environment.' An agent knows exactly what this does. However, it does not differentiate from the sibling execute_hscript or evaluate_expression, which are the closest alternatives, so it falls short of a 5.

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

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

No when-to-use guidance, no exclusions, and no routing to alternatives. With siblings like execute_hscript and evaluate_expression present, the description gives no signal about when Python execution is the right choice over Hscript or expression evaluation.

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, and it only says stdout/stderr is returned. It omits that HScript commands can mutate scene state, whether there are safety or timing constraints, and how failures surface, all of which matter for an arbitrary command runner.

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?

One sentence, front-loaded with the action and resource, with zero filler. It is efficient, though the terseness shades into under-specification rather than disciplined conciseness.

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?

An output schema exists so return values need no elaboration, and only one required parameter is present. Still, for an arbitrary-code execution tool with no annotations, the description omits mutation risk, environment context, and sibling differentiation, leaving real 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% and the single 'command' parameter has no description anywhere. The description does not clarify expected syntax (HScript vs Python vs MEL), escaping rules, or multi-line support, so it adds no meaning beyond the bare property name.

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 (Execute) and resource (HScript command) plus the output channel (stdout/stderr). However, it offers no differentiation from the sibling execute_houdini_code, so an agent cannot tell from the text alone which of the two execution tools to pick.

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 when-to-use guidance, no prerequisites, and no mention of the obvious alternative execute_houdini_code (or batch). The agent gets no basis for choosing this tool over its near-identical sibling.

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 implies a read-only inspection and discloses a meaningful behavior (only non-default parameters are reported), but never explicitly states it is read-only, nor does it mention permissions or any side effects. Some behavioral value, but gaps remain.

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?

A single tight sentence that front-loads the verb and enumerates the returned content with zero filler. Every clause 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?

An output schema exists, so return values need no explanation, and the description names the three content categories returned. For a simple one-parameter read tool this is nearly complete; only the undocumented 'path' parameter keeps it from a 5.

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 single required 'path' parameter has 0% schema description coverage and the description never mentions or defines it. The agent can infer 'path' is a node path from 'a node', but no format, scope, or example is provided to compensate for the schema 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?

States a specific verb ('Get... explanation') and resource ('a node'), and enumerates what the explanation contains: type, non-default parms, connections. It does not differentiate from the closely related sibling get_node_info, so an agent cannot tell them apart from the description alone.

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 when-to-use guidance, no exclusions, and no mention of the obvious alternative get_node_info or get_parameter. Usage is only implied by the listed content, leaving the agent to guess when this is preferable to other node-inspection tools.

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. It implies a read-only diagnostic but does not state whether it recurses the whole hierarchy or only under root_path, whether it triggers cooking, or whether it is expensive on large scenes.

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?

A single front-loaded sentence with no filler; the purpose is stated immediately. It is arguably too terse for the gaps it leaves, but there is no wasted language.

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?

An output schema exists, so return values need not be described. However, for a scene-scanning tool the missing recursion/scope semantics around root_path and the absence of any behavioral context leave the definition only minimally complete.

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

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

The single parameter root_path has 0% schema description coverage, and the description adds nothing about it - it never explains that root_path scopes the scan or whether the scan includes descendants. With one undocumented parameter, the description must compensate and 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?

States a specific verb ('Scan') and resource ('node hierarchy') with a clear target ('cook errors and warnings'), which distinguishes it from the name-based find_nodes sibling. It does not explicitly name a sibling, but the diagnostic 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 description gives no when-to-use guidance, no exclusions, and no reference to alternatives such as find_nodes, get_cook_chain, or explain_node, which are the obvious adjacent debugging tools. An agent must infer that this is a debugging tool from purpose 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 never discloses pattern syntax (glob, regex, wildcard?), whether the search recurses below root_path, case sensitivity, or result limits — all critical for a search tool with no structured safety hints.

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

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

A single tight sentence with the core action front-loaded and zero filler. It is efficient, though the brevity borders on under-specification rather than true economy.

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?

An output schema exists, so return-value explanation is not required. However, with 3 undocumented parameters, no annotations, and no pattern-syntax or scope details, the definition is only minimally sufficient 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 coverage is 0%, so all three parameters rely on the description. It maps loosely to 'pattern' and 'node_type' but says nothing about root_path (default '/'), which is the scoping parameter that determines search breadth; neither does it explain accepted pattern syntax.

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?

Clear verb+resource: find nodes matching a name pattern, with an optional type filter. This distinguishes it reasonably from list_children and list_joints, though it never explicitly contrasts itself with those 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?

The description states what it does but gives no when-to-use guidance, no alternatives, and no exclusions. An agent cannot tell from this text whether find_nodes is preferred over list_children or find_error_nodes for a given search task.

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. It does disclose a useful edge-case behavior (refusal when isolate matches no OBJ, which leaves the infinite grid framed), but says nothing about whether this mutates scene state or what the viewport changes affect.

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

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

Three short lines, front-loaded with the action, followed immediately by the caveat and the routing hint. 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?

A parameterless, output-schema-backed viewport tool is well covered by the action statement, the refusal caveat, and the sibling pointer. Only a note on what the viewport change affects (state mutation) would make it fully rounded.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description neither needs nor provides parameter detail.

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?

"Frame the viewport on all geometry" gives a specific verb and resource, and the note routing character/hero framing to frame_bbox distinguishes it from a key sibling. It does not distinguish itself from frame_selection, but the core 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?

It explicitly names the alternative (frame_bbox for a character/hero), which is real routing guidance. There is no explicit when-not beyond that, and frame_selection is never mentioned, so it stops short of the full 5.

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

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

With no annotations, the description carries the full behavioral burden. It does not say this moves the viewport camera, what happens when both min_vec/max_vec and node_path are supplied (which wins?), whether the viewer param is optional, or what occurs when all optional params are omitted — significant gaps for an action 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?

Two short sentences, front-loaded with the core action. Little waste, though the 'Does not home the grid' clause is cryptic without context and could be traded for more 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?

An output schema exists so return values need not be explained, but with four undocumented parameters, zero annotations, and no usage routing, the description is too thin for an agent to invoke this confidently. Missing details include viewer selection and bbox-vs-node precedence.

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 all four parameters. It loosely maps 'world-space bbox' to min_vec/max_vec and "node's geometry" to node_path, but gives no format, units, or precedence rules, and the 'viewer' parameter is never mentioned at all.

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 ('Frame') and the two resource variants it accepts (a world-space bbox or a node's geometry), which sets it apart from frame_selection and frame_all. However, it never names those siblings explicitly, so the agent must infer the distinction from the input types alone.

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 only guidance is the negative 'Does not home the grid,' which clarifies one non-behavior but offers no positive when-to-use instruction. Nothing tells the agent when to pick this over frame_selection, frame_all, or frame_usd_prim.

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 supplied, so the description carries the full burden. It does disclose a state dependency (it acts on the 'current selection'), which is useful, but says nothing about what happens with an empty selection, whether the camera move persists, or whether the operation requires a specific viewport context. Adequate but thin for a tool with zero annotation coverage.

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

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

A single front-loaded sentence with no wasted words. For a zero-argument viewport action this is the right size.

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?

An output schema exists, so return values need not be described, and the action itself is simple. However, with no annotations and no mention of empty-selection behavior or viewport prerequisites, the definition is only minimally sufficient given the absence of all structured behavioral hints.

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 tool takes zero parameters, so the schema has nothing for the description to explain. The baseline of 4 applies; the description cannot add parameter meaning where none exists.

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 (frame) and target (viewport on the current selection), which is clear enough for an agent to distinguish it from the sibling frame_all, frame_bbox, and frame_usd_prim. It stops short of naming those siblings, so it earns a 4 rather than a 5.

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

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

No when-to-use guidance and no explicit alternatives. With frame_all, frame_bbox, and frame_usd_prim in the sibling list, the description should say when to frame the selection instead of the whole scene or a bounding box, but it leaves that entirely to inference.

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

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

No annotations are provided, so the description carries the full burden. It reveals that the framing targets the prim's bbox rather than the infinite grid, which is a useful behavioral hint, but it omits whether the operation moves the camera, which viewer it defaults to, or what happens when the prim cannot be resolved.

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?

One tightly written sentence with the action front-loaded and no filler. The trailing parenthetical is compact, though 'hero' is jargon that some agents may not resolve.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

For a tool with no annotations, three undocumented parameters (two required), and no parameter explanations, the description is too thin. The output schema is present so return values need not be covered, but the invocation contract remains ambiguous.

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

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

Schema description coverage is 0% for three parameters. The description implies 'prim_path' via 'USD prim bbox' and gestures at 'viewer', but never explains the role of 'path', how it differs from 'prim_path', or how 'viewer' selects a target. It does not 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?

States a specific verb (frame) and resource (LOP viewer on a USD prim bbox), which an agent can distinguish from generic siblings like frame_all. It stops short of explicitly contrasting with frame_selection or frame_bbox, both of which could plausibly be confused with it.

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 parenthetical '(hero, not the infinite grid)' hints at the framing behavior but does not say when this tool should be chosen over frame_selection, frame_all, or frame_bbox. No prerequisites or conditions are given.

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

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

No annotations are provided, so the description carries the full behavioral burden. It clearly states the operation is a read-only query returning connection status fields (whether connected, port, command count, timing). This sufficiently discloses behavior for a non-mutating getter, though it does not explicitly label itself read-only.

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?

A single, focused sentence with no filler. It front-loads the primary purpose and then enumerates the salient return fields efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

The tool is low-complexity, has an output schema (so return values are covered elsewhere), and has no parameters. The description gives the core purpose and return fields, making it complete enough for an agent to select and invoke it.

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 tool has 0 parameters, so the baseline is 4. Schema description coverage is 100% (empty object), and the description correctly does not need to document parameters. No additional parameter semantics can be added.

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 ('Returns') and resource ('current connection status to Houdini') and lists the salient returned fields. It does not explicitly differentiate itself from sibling tools such as ping or get_scene_info, so it is clear but not maximally 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 explicit when-to-use, when-not-to-use, or alternative guidance. The implied usage is to check the connection to Houdini, but the agent receives no direction on when this is preferable to ping or other status tools.

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. 'Inputs all the way up' usefully discloses the traversal direction and that it is transitive/upstream, but nothing is said about permission requirements, cycles, or performance on deep chains.

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?

A single sentence with the scoping detail parenthesized and front-loaded. Nothing is wasted and the core action comes first.

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?

An output schema exists, so return values need no explanation, and for a single-param read tool the description is nearly sufficient. The main gap is the meaning of the path parameter, which is left ambiguous.

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

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

Schema description coverage is 0% for the single path parameter, so the description must compensate. 'For a node' loosely maps path to a node identifier, but neither the schema nor the description states whether it is a node path, name, or network-qualified identifier.

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 (Get) and resource (cook dependency chain) and clarifies the traversal with 'inputs all the way up.' An agent can tell what it returns, but the description does not differentiate it from siblings like get_node_info or explain_node.

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

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

There is no when-to-use guidance, no prerequisites, and no alternative named despite many related node-inspection siblings. The agent must infer usage entirely 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?

No annotations are provided, so the description carries the burden: 'Get' clearly signals a read-only operation, and 'Does NOT require a Houdini connection' is genuinely useful context since nearly every sibling tool needs a live session. It does not cover failure behavior for an invalid/nonexistent path or any rate/size limits.

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

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

Two short sentences, front-loaded with the core action, and every clause carries information: what it returns, the path format, its origin, and the connection independence.

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?

An output schema exists, so return values need not be described. For a single-parameter read tool this is nearly complete; the only minor gap is behavior on an invalid path, which the description omits.

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% for the single 'path' parameter, so the description must compensate, and it does: it specifies the value is a 'relative path' (not absolute) and that it comes from search_docs. That is meaningful semantics beyond the bare string 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?

States a specific verb and resource ('Get the full content of a Houdini documentation page') and pins down the input ('by its relative path'), which cleanly separates it from the sibling search_docs that produces those paths.

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 parenthetical '(as returned by search_docs)' establishes the intended workflow and names the upstream sibling, which is strong implied usage guidance. It stops short of stating when not to use it or spelling out prerequisites beyond the connection note.

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 states that errors are included, which is a useful behavioral note, but it does not cover permissions, rate limits, whether the log is cleared after reading, or the format of the return. With an output schema present, some return details may be covered there, but the description is minimal for a tool with no annotations.

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

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

The description is a single, front-loaded sentence that is concise and free of filler. It could be slightly clearer by specifying what 'payload' means, but it is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

Given that the tool has an output schema (so return values need not be explained) and no parameters, the description is mostly complete. However, with no annotations and sparse behavioral detail, an agent lacks context on when to call this tool versus others, and whether the log is persistent. It is minimally adequate but leaves gaps.

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

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

The tool takes zero parameters, so there is no parameter semantics to document. Per the rubric, zero params gives a baseline of 4. The description does not need to explain parameters, and it correctly omits them.

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 says it retrieves the last execute_code payload from the Houdini session, which is a specific verb+resource. However, it does not clearly distinguish itself from siblings like get_network_overview or list_panes, and the phrasing 'Last execute_code payload' is slightly ambiguous without context on whether it returns stdout, return values, or errors. It's adequate but not sharp.

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 explicit guidance on when to use this tool versus alternatives. An agent might confuse it with find_error_nodes, get_network_overview, or execute_hscript. The description implies it's for debugging execute_code, but no when/when-not rules are provided.

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. It discloses the scoping behavior ('from the edit target layer'), which is useful, but says nothing about how 'recently' is defined, ordering, or result limits beyond the count parameter. For a read tool with zero annotation coverage, this leaves meaningful 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?

A single front-loaded sentence with no waste, but it is under-specified rather than genuinely concise. Brevity here comes at the cost of the parameter and usage detail the agent needs.

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?

An output schema exists, so return-format detail is not required. However, for a two-parameter read tool with no annotations and 0% schema coverage, the description should at minimum clarify what 'path' and 'count' mean and when to prefer this over other prim-listing tools. That detail is absent.

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 adds no parameter meaning at all: 'path' is never explained (path to what?), and 'count' (default 10) is never mentioned. The description does not compensate for the schema's total lack of documentation.

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

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

States a specific verb (get) plus resource (recently modified prims) and a scope qualifier (edit target layer), so the agent understands what it returns without opening the schema. It does not explicitly differentiate itself from the closely-named sibling list_usd_prims, which keeps it out of 5 territory.

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 when-to-use or when-not-to-use guidance and no reference to alternatives such as list_usd_prims or lop_prim_search. The agent is left 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?

No annotations are provided, so the description carries the full burden. It does not disclose what the 'overview' contains (summary vs full data), whether it traverses recursively, the scale/cost of the traversal, or any permission requirements. An output schema exists, which partially covers the return shape, but the behavioral profile is largely undisclosed.

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

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

A single efficient sentence with the key content front-loaded. No padding, though there is room to add routing and parameter context without bloat.

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 an output schema present, return values need not be re-explained, so the gap is narrower than it appears. However, the lone parameter is undocumented and there is no routing guidance against several similarly named sibling tools.

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

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

There is one parameter (path, default '/obj') with 0% schema description coverage, and the description never mentions it. It says only 'a network' without explaining that path selects which network, nor the format or default 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?

States a clear verb (get) and resource (network overview), and specifies the content: all nodes plus their connections. This distinguishes it naturally from list_children (immediate children only) and find_nodes (search), though it does not explicitly name those 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 guidance, no prerequisites, and no indication of how it differs from siblings like list_children, list_nodes, find_nodes, or get_node_info. The agent must infer the intended 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 disclosure burden. 'Get' strongly implies a non-mutating read, and the output schema covers return structure, but the description says nothing about side effects, permissions, or whether the node must be cooked/loaded, leaving behavioral characteristics implied rather than 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?

A single compact sentence with the verb and resource front-loaded and zero filler. It is efficient, though the terseness is partly what leaves the parameter and usage gaps.

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?

Because an output schema exists, the return shape need not be explained, and the field list covers the essentials. However, for a node-inspection tool sitting among many similar siblings, the missing path semantics and lack of routing guidance leave the definition only minimally 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% for the single 'path' parameter, and the description does not compensate at all. It never explains whether 'path' is a node path (e.g. /obj/geo1), a file path, or something else, which is the one piece of information an agent most needs to call this correctly.

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

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

States a specific verb ('Get') and resource ('node info') and enumerates the four returned facets (type, parameters, inputs, outputs), so the agent knows what it retrieves. It does not distinguish itself from close siblings such as explain_node, get_parameter, or get_parameter_schema, so it falls short of a 5.

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

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

There is no when-to-use guidance and no mention of alternatives, despite several overlapping siblings (explain_node for narrative explanation, get_parameter/get_parameter_schema for individual parameters, find_nodes/list_node_types for discovery). The agent must infer the choice entirely 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?

With no annotations, the description carries the full behavioral burden. 'Get' implies a safe read and the enumeration of returned fields adds some context, but it says nothing about error behavior for a nonexistent node_path/parm_name, permissions, or whether the read triggers a cook.

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

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

A single front-loaded sentence with no wasted words. It is efficient, though the terseness contributes to the underspecification noted elsewhere.

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?

An output schema exists, so return-value explanation is not needed. But with 0% parameter coverage, no annotations, and no usage guidance, the definition is only minimally sufficient for invoking this two-parameter tool correctly.

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

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

Schema description coverage is 0%, so neither parameter is documented in the schema. The description gives no format hints for node_path (e.g., a scene path) or parm_name, leaving the agent to guess the expected syntax for both required 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 names a specific verb and resource ('Get a single parameter') and enumerates what it returns (value, type, expression, metadata), which is clearer than a bare tautology. However, it does not differentiate itself from the close sibling get_parameter_schema or clarify its relationship to set_parameter.

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 when-to-use guidance, no mention of when to prefer get_parameter_schema or set_parameter, and no stated preconditions. The agent must infer context entirely from the name and sibling list.

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 alone; 'Get' implies a safe read and 'all parm templates' clarifies the scope of the result, which is useful. However, it says nothing about permissions, failure modes, or cost, leaving the behavioral profile thin for an annotation-free 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?

One tight sentence with the operation front-loaded and zero filler. It is perhaps slightly too terse for a tool with an undocumented parameter, but structurally efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

An output schema exists, so return values need not be explained, and the tool is a simple single-parameter read. Still, the undefined node_path semantics leave an agent without enough to call it confidently.

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 single required parameter node_path has 0% schema description coverage, so the description must compensate for the gap. It never explains the node path format or syntax, adding no meaning beyond the bare parameter name.

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 (Get) and resource (full parameter schema / all parm templates) scoped to a node, which an agent can distinguish from get_parameter. It does not explicitly name or contrast with sibling tools, so it falls short of a 5.

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

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

There is no when-to-use guidance, no mention of alternatives such as get_parameter or list_file_parms, and no prerequisites described. The implied context ('for a node') is the only hint.

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

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

With no annotations, the description carries the full burden. It discloses that the return is a JSON string, but it does not state what the JSON contains, whether it is a snapshot or live data, or if there are any performance implications. Minimal behavioral context beyond the return type.

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

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

The description is two short sentences, with no filler or redundant information. It clearly communicates the action and return format in an efficient manner.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

An output schema exists, so return format details are likely structured. However, the meaning of 'scene info' remains ambiguous, and the description does not clarify the scope of data returned. For a zero-param tool, this is adequate but incomplete for an agent deciding between this and similar scene-related tools.

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

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

The tool has zero parameters, and the schema trivially covers 100% of the (empty) parameter space. Per the baseline for 0-param tools, the description does not need to add parameter semantics, and any addition would be redundant.

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

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

The description states it 'Ask(s) Houdini for scene info' and returns JSON, giving a verb and resource. However, 'scene info' is vague and does not distinguish it from siblings like get_scene_summary or get_network_overview, which likely cover similar ground.

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

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

No guidance is given on when to use this tool versus alternatives. The description implies it is for getting general scene information but does not mention when it should be preferred over specific scene-related tools.

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

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

With no annotations, the description carries the full burden, and 'Get' does convey a read-only, non-mutating operation. However it says nothing about session/connection requirements or whether the selection is network-scoped, so the disclosure is minimal rather than rich.

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?

A single front-loaded sentence with no waste. It is appropriately sized for a zero-parameter getter, though it is too terse to earn a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

An output schema exists, so return values need not be described, and there are no parameters to document. The definition is close to complete for a simple getter; only the selection's scope/context is unstated.

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 tool takes zero parameters, so the baseline is 4. The empty schema means there is no parameter semantics for the description to compensate for.

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 (Get) and resource (the currently selected nodes) with a clear scope qualifier ('currently selected'). It is distinguishable from the apposite sibling set_selection, though the description never names or contrasts that sibling explicitly.

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 when-to-use guidance, no mention of the complementary set_selection tool, and no note about whether this reflects a live scene state or a cached one. Usage is only implied by the tool 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?

No annotations are provided, so the description must carry the behavioral burden. 'Get' implies a read-only operation, but the description does not state error behavior for missing paths or attributes, permission requirements, or whether any side effects exist.

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

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

The description is a single front-loaded sentence with no filler. It is appropriately concise for a short statement, though arguably too terse given the three required parameters and lack of supporting 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?

An output schema exists, so return values need not be explained. However, with no annotations and 0% input schema description coverage, the description is incomplete: it omits all parameter semantics and any usage context needed to call the tool reliably.

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% across three required parameters: path, prim_path, and attr_name. The description adds no explanation of any parameter's meaning, format, or expected value, which is a severe gap for correctly invoking the tool.

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

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

The description states a specific verb and resource: 'Get a specific USD attribute value.' It is clear enough to distinguish from the sibling set_usd_attribute, though it does not explicitly name alternatives or scope like prim path.

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 guidance, prerequisites, or alternatives are provided. The agent can infer it is for reading rather than writing, but nothing routes it between this tool and list_usd_prims, get_usd_composition, or inspect_usd_layer.

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. It discloses the category of returned data (composition arc types) and 'Get' implies a read, but it says nothing about error behavior for a missing prim, permissions, or cost.

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?

A single front-loaded sentence with no filler; the verb, resource, and returned arc types are all packed in without waste.

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?

Although an output schema exists (so return values need not be restated), the tool has two undocumented parameters, no annotations, and no usage guidance. For a 2-required-param USD tool, the description is too thin to be 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% and neither of the two parameters (path, prim_path) is explained. The description's phrase 'for a prim' loosely implies prim_path, but the role of 'path' versus 'prim_path' is left entirely to inference, so the description fails to 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?

States a specific verb ('Get') and resource ('composition arcs') and even enumerates the arc kinds (references, payloads, inherits, specializes) returned for a prim. It is clear what the tool does, though it never distinguishes itself from nearby siblings like lop_prim_get or inspect_usd_layer.

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

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

There is no when-to-use, when-not-to-use, or alternative mentioned. The description implies a read on a prim's composition but leaves the agent to guess whether it should call this versus lop_prim_get, list_usd_prims, or inspect_usd_layer.

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 supplied, so the description carries the full behavioral burden. 'Get' implies a read, and the listed fields hint at the output, but nothing is said about permissions, failure behavior when the prim path is invalid, or whether the prim must be loaded/active.

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?

A single front-loaded sentence with no filler; the key content (verb, resource, returned fields) comes first. It is efficient, though the terseness comes partly at the cost of the missing parameter and usage 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?

An output schema exists, so return values need not be described, but for a two-parameter tool with 0% schema coverage, ambiguous parameter names, and no annotations, the description leaves too much for the agent to guess about 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 both required parameters are undocumented. Worse, the two names ('path' and 'prim_path') are near-synonymous, so the description needed to disambiguate which is the stage/file path and which is the prim path — and it 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?

Names a specific verb and resource ('Get stats about a USD prim') and enumerates the returned fields (child count, attr count, active, payload), so the agent knows exactly what it yields. It does not, however, distinguish itself from closely related siblings such as get_usd_composition, get_usd_attribute, or lop_prim_get.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives despite many overlapping siblings (get_usd_composition, get_usd_variants, inspect_usd_layer, get_usd_attribute). The agent must infer selection entirely from the tool name.

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

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

No annotations are provided, so the description carries the burden. 'Get' clearly signals a non-mutating read operation, and the output schema covers return values, but there is no mention of permission needs, whether it requires a live stage, or any other operational context.

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

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

A single, front-loaded sentence with no wasted words. It is appropriately sized, though the brevity comes at the cost of the missing detail noted in other dimensions.

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 an output schema the return values are covered, but the absence of annotations and the two undocumented path parameters mean the definition is not complete enough for reliable invocation. Nothing explains how 'path' and 'prim_path' differ or when the tool applies.

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?

Both parameters ('path' and 'prim_path') have 0% schema description coverage, and the description adds no clarification. The two path-like parameters are ambiguous and their distinction is never explained, leaving a real gap for the agent to fill.

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 ('Get') and resource ('variant sets and selections for a USD prim'), which is clearly distinct from attribute/composition siblings. However, it does not explicitly name or distinguish itself from related tools like get_usd_composition or get_usd_attribute.

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

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_usd_composition or get_usd_attribute. The agent is left to infer usage entirely from the tool name and siblings.

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

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 discloses almost nothing: it does not confirm the read-only nature explicitly, nor mention side effects, permissions, or scope of the returned state. The 'get_' prefix is the only behavioral cue.

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?

It is compact and front-loads the content domain first, then the parameter note. Nothing is wasteful, though the telegraphic two-fragment style is terse enough to be slightly cryptic.

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?

An output schema exists, so return values need not be explained, but for an annotion-free read tool the description still omits what happens when 'viewer' is unset (does it default to the active pane?) and gives no indication of the state being reported. Coverage is too thin for the tool's role.

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 partially does by defining 'viewer' as the pane name and marking it optional. That is meaningful beyond the bare schema, but it adds no format, default behavior, or examples for resolving a pane name.

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 fragment 'Viewport camera, shading, Hydra delegate' signals the resource domain and enumerates the aspects covered, which helps distinguish it from the set_viewport_* writers. However, it is a noun phrase with no verb, so it never plainly states that it retrieves/reports viewport info; the agent infers the action from the name alone.

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 when-to-use guidance and no named alternative. Siblings such as set_viewport_camera, set_viewport_display and set_viewport_renderer form an obvious read/write pair, but the description never establishes this tool as the read-only counterpart, leaving routing entirely to inference.

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

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

With no annotations, the description carries the full behavioral burden, but it only states the output attachment target. It does not disclose whether the operation creates nodes, requires an existing parent, overwrites data, or what errors to expect.

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 extremely short but fragmentary, using namespace notation and two clipped phrases rather than front-loaded prose. Under-specification rather than conciseness is the issue.

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 three undocumented parameters, no annotations, and an output schema, the description is too thin. It leaves both the parameter roles and the behavioral side effects largely unexplained.

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 the parameters, but it never mentions file_path, name, or parent_path. The vague mention of an attach target is insufficient to clarify even parent_path semantics.

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

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

The description identifies a specific action (import an FBX animation, Mixamo clip) and resource (kinefx::fbxanimimport), and distinguishes it from the sibling import_fbx_character by focusing on animation rather than character import. The cryptic namespace notation and fragmentary phrasing keep it from being a fully clear 5.

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

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

It gives one usage prerequisite — attach to a character SOP geo — but provides no guidance on when to choose this tool over import_fbx_character or other animation-related siblings. There are no explicit exclusions or alternative-routing rules.

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 disclosure burden, yet it discloses almost nothing behavioral: no mention of side effects (what nodes it creates), error modes on bad paths, or how the rest-pose handling affects the rig. The only hint ('under mcp_* geo') is about placement, not 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?

It is very short, which is good, but the telegraphic fragment style front-loads an internal node identifier rather than the user-facing action. Brevity here trades against comprehension instead of earning 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?

With an output schema present, return values need not be explained, but the description still leaves key gaps: undocumented parameters, no annotation coverage, and no statement of what gets created or where. For an import tool with a required file path, this is under-specified.

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

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

All three parameters have 0% schema description coverage, so the description must compensate and largely doesn't. It loosely implies a target network (relevant to parent_path) and an FBX source (relevant to file_path), but the name parameter and default values are never explained.

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 name gives a clear verb+resource, and the description adds the underlying Houdini node type (kinefx::fbxcharacterimport) and network scope (mcp_* geo). However, it never plainly states that it imports a skeletal/character FBX into the scene, and the phrase 'Mixamo/character rest pose' is cryptic rather than explanatory. An agent can roughly infer intent but not confidently.

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 when-to-use guidance and no routing among obvious siblings such as import_fbx_animation, attach_kinefx_deform, or map_kinefx_joints. The agent is left to guess whether this is the entry point for rigged character import versus animation import.

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 discloses almost nothing. 'Inspect' implies a read, but the description never confirms read-only behavior, permission needs, or how the layer_index default resolves against the stack. The output schema exists, so return format needn't be covered, but the operational context is still thin.

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?

A single tight sentence with the resource and scope front-loaded and no wasted words. It is efficient, though the brevity contributes to the under-specification rather than being a flaw of structure itself.

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?

An output schema is present, so return values need not be explained, but with 0% parameter coverage and no annotations, the description should do far more. It omits what 'path' means, how layer_index behaves, and when this tool is the right choice, leaving an agent under-equipped for a two-parameter tool.

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

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

Schema coverage is 0%, so the schema has no field descriptions at all. The description only touches on 'by index' (layer_index) and says nothing about what 'path' represents or how it relates to the index, nor what the default 0 implies. The description does not compensate for the total documentation 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 clear verb (inspect) and resource (USD layer) and notes the index-in-stack scope, which is more than a tautology. However, it gives no differentiation from the many related USD tools in the sibling list (e.g. lop_layer_info, get_usd_composition), so an agent cannot easily tell which to pick.

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 lop_layer_info or the other USD inspection tools. No prerequisites, no exclusions, and no named sibling are provided; the agent must infer usage entirely.

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 doesn't state whether the operation is read-only or mutates the scene, what permissions are needed, whether it's reversible, or what the output looks like (despite an output schema existing). The description adds no behavioral context beyond the name.

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

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

The single sentence is concise and front-loaded, but it is too terse for a tool with an output schema and an undocumented parameter. It doesn't waste words, but it also doesn't earn its place by adding value.

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, 0% schema coverage, and a complex sibling set (Houdini network editing), the description is far too sparse. It should explain the effect on the scene, the role of node_path, and expected outcome. The presence of an output schema doesn't excuse the lack of basic 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% for the single parameter 'node_path'. The description does not mention this parameter or clarify its default value '/obj', its format, or whether it represents a node path in Houdini. The description fails to compensate for the schema 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 verb ('layout') and resource ('child nodes'), but it's essentially a restatement of the tool name. It does not distinguish from siblings like frame_all, frame_bbox, or frame_selection, which also arrange/view nodes. No detail on what 'auto-layout' means (grid, force-directed, etc.).

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. It doesn't say it operates on the selected node's children, nor does it reference siblings like list_children or frame_all. Use case is only implied by 'network editor'.

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, yet it only implies a read-only listing. It does not state ordering, depth behavior, permissions, or what happens when the node has no children; the recursion option is mentioned but its cost or limits are not.

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?

A single front-loaded sentence with no wasted words; the verb and resource come first. It is efficient, though its brevity reflects under-specification rather than disciplined pruning.

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?

An output schema exists, so return values need not be explained, and the tool is structurally simple (2 params, no nesting). Still, with zero schema coverage and no annotations, the description leaves the semantics of 'path' and recursion depth entirely to 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?

Schema description coverage is 0%, so both parameters are undocumented in structured data. The description only gestures at 'recursive' via 'optionally recursive' and says nothing about the required 'path' parameter (format, relative vs absolute, node addressing).

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 ('List all children of a node'), so the core operation is unambiguous. However, it does not distinguish itself from adjacent listing tools such as find_nodes or layout_children, and 'node' is left undefined in a toolkit with many node-like resources.

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 explicit when-to-use guidance and no mention of alternatives in a large sibling set that includes find_nodes and list_node_types. The 'optionally recursive' clause hints at a usage mode but does not say when recursion is appropriate or costly.

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. It never states that the operation is read-only, whether it requires a cooked/valid node, or what it returns, and 'No new importer' is ambiguous about what side effects (if any) 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?

It is short and front-loaded, which is appropriate for a simple list tool. But the trailing 'No new importer' is cryptic filler that neither guides usage nor explains behavior, so not every phrase 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?

An output schema exists, so return values need not be explained, and the tool has only one parameter. Still, with zero annotations and zero schema descriptions, the definition leaves the agent without confirmation of read-only behavior or node prerequisites for a Houdini-style parameter query.

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

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

Schema coverage is 0% and the single parameter node_path is undocumented in the schema. The description's 'on a node' loosely implies node_path identifies the target node, but adds no syntax, format, or path-type detail to 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 verb 'list' and resource 'file/path parms on a node' are identifiable, and the parenthetical examples (alembic, usd, texture, fbx, vdb) clarify the kind of parameters. However, the phrasing is terse and abbreviations like 'parms' plus the cryptic trailing clause 'No new importer' muddy the purpose, and it does not clearly distinguish itself from siblings like get_parameter or set_file.

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 new importer' hints at a scope boundary but is too opaque to function as when-to-use guidance. There is no explicit statement of when to use this versus get_parameter, set_file, or get_parameter_schema, leaving the agent to infer selection.

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

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

No annotations are provided, so the description carries the full behavioral burden. It reveals only that a 'current' delegate is included, saying nothing about whether the operation is read-only, what requires the viewer to be open, or how multiple delegates are returned.

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?

One tight sentence with no filler, front-loading the verb and resource. Slightly terse given the unexplained viewer parameter, but structurally clean.

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?

An output schema exists, so the return format need not be described. However, the undocumented viewer parameter and the absence of any behavioral or usage context leave gaps for correctly 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?

The single 'viewer' parameter has 0% schema description coverage and is not mentioned in the description at all, so the agent cannot tell what value it expects (name, path, index?) or what omitting it defaults to.

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 'List' plus resource 'Hydra delegates' scoped to the LOP Scene Viewer, and notes it also returns the current delegate. Implicitly contrasted with the sibling set_hydra_renderer, but that alternative is never named.

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 call this versus set_hydra_renderer, restart_renderer, or set_viewport_renderer. The agent is left to infer that this is the read counterpart to the setters.

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. It discloses the return content (joint point name and P position), which is genuinely useful, but says nothing about read-only/non-destructive nature, error behavior, or limits. A list tool's safety profile is inferable 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?

Two terse fragments with no filler, and the core resource is front-loaded. The telegraphic style is efficient but borders on under-specification rather than clean 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?

An output schema exists so return values needn't be restated, but with zero annotation coverage and 0% parameter documentation, the description is too thin for a two-parameter tool. An agent gets no guidance on node_path format or the meaning/effect of max_joints.

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% across two parameters, so the description must compensate and largely does not. 'On a SOP' weakly implies node_path refers to a SOP node, but max_joints (default 256) is never mentioned, leaving half the parameters undocumented in both schema and 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?

States a specific resource (KineFX skeleton joints) and its content (point name + P) on a SOP node, which distinguishes it from generic sibling tools like get_parameter or list_children. The verb 'list' is only implied by the tool name rather than the description text, so it falls just short of a clean 5.

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

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

'Mixamo/character inspect' hints at a context (inspecting Mixamo/character rigs) but gives no explicit when-to-use, when-not-to-use, or alternatives. Relevant siblings such as map_kinefx_joints and attach_kinefx_deform are never referenced, so routing is left entirely to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing about traversal scope (recursive vs direct children), what happens on an invalid path, or permissions. It is read-only in effect but that is only implied by the verb 'List', 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?

A single front-loaded sentence with zero wasted words. It is efficiently structured, though so minimal that it borders on under-specification rather than optimal conciseness.

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?

An output schema exists so return values need not be explained, but the description still omits the meaning of the sole parameter and the scope of the listing, leaving meaningful gaps for a tool with many overlapping siblings.

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 single required parameter 'path' has 0% schema description coverage, and the description does not explain whether it is a stage path, prim path, or file path. With one undocumented parameter the description should compensate, and it 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?

States a specific verb (List) and a narrow resource (light prims in a USD stage), which is more precise than the generic sibling list_usd_prims. However it never names an alternative or clarifies scope relative to list_usd_prims / lop_prim_search, so sibling differentiation is left to inference.

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 when-to-use guidance, no exclusions, and no mention of the several overlapping prim-listing siblings (list_usd_prims, lop_prim_search, lop_prim_get). The agent can only infer usage from the tool name.

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

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, yet it discloses almost nothing beyond the parameters: no read-only confirmation, no mention of the default limit of 200 or any pagination/truncation behavior, and no ordering guarantees. An output schema exists (so return shape is covered), but the operational traits of the call remain undisclosed.

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

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

Two tight sentences that front-load the core action and then attach parameter meaning with illustrative examples. There is no filler and every clause carries 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?

With an output schema present, return values need not be explained, and the parameter semantics for pattern/category are covered. However, the limit parameter's effect and any usage routing remain unaddressed, leaving the definition adequate but with clear gaps for a discovery 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, and it does for two of three parameters with concrete, non-obvious semantics: category values ('Sop'/'Lop'/'Object') and pattern as a glob matched against type name or label. Only 'limit' is left undocumented, so it falls just short of full compensation.

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+resource ('List node types'), which is unambiguous and distinguishable from mutating siblings like create_node or modify_node. It does not, however, explicitly contrast itself with related discovery tools such as find_nodes or list_usd_prims, so the differentiation is implicit.

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?

Usage is only implied: the parameter examples ('Sop'/'Lop'/'Object', '*intersect*') hint at the discovery/filtering scenario but there is no explicit when-to-use or when-not-to-use guidance against alternatives like find_nodes. An agent can infer the intent but is not routed deliberately.

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. 'List' strongly implies a safe read-only enumeration, but the description says nothing about the Houdini session requirement, whether it works headless, or what the returned pane entries contain. The presence of an output schema offsets some of the return-value gap, keeping this at a minimum-viable 3.

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?

A single front-loaded sentence with no filler; every word earns its place for a trivial enumeration tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

With an output schema present, the description need not explain return values, and the zero-parameter signature is fully covered. Only the session/prerequisite context is absent, which is a minor gap for a simple read.

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 tool takes zero parameters, which is the baseline-4 case under the rubric. The description correctly implies no filtering or scoping arguments exist.

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 ('List all pane tabs in the Houdini desktop'), so an agent immediately knows it enumerates UI panes rather than scene nodes. It is not confused with siblings like list_children or list_lights, though it does not explicitly contrast itself with 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?

There is no statement of when to use this tool versus alternatives, nor any preconditions. For a zero-argument listing tool the usage is fairly obvious, but the description offers nothing beyond the bare 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 of behavioral disclosure. It does not state that the operation is read-only, whether it has side effects, or any performance or permission characteristics; only the bare action is given.

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

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

The description is a single front-loaded sentence with no wasted words. However, its extreme terseness leaves essential parameter and usage context unstated, which is a completeness issue rather than a conciseness issue.

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?

An output schema exists, so return values need not be explained, but the description still omits parameter meaning, usage guidance, and any behavioral attributes. With no annotations and 0% schema description coverage, it is insufficient for a three-parameter USD listing 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 for the three undocumented parameters. It hints at the depth parameter ('up to a given depth') but gives no meaning for the required 'path' parameter or the 'root_prim' parameter, nor does it explain defaults.

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 verb and resource (list USD prims) plus a scope qualifier (up to a given depth). It is understandable without opening the schema, but it does not distinguish the tool from sibling USD prim-listing tools such as lop_prim_search or get_usd_prim_stats.

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

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

The description provides no guidance on when this tool should be used instead of alternatives, even though many sibling tools operate on USD prims. There are no exclusions, prerequisites, or routing hints for the agent.

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 disclosure burden. It does not say whether loading replaces the current scene (and destroys unsaved work), what happens on a missing/invalid path, or whether it blocks. For a scene-level mutation, 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?

One short, front-loaded sentence with zero filler. It is efficient, though the brevity comes at the cost of substance rather than being a virtue of concision.

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?

An output schema exists so return values need no explanation, but with no annotations, no parameter documentation, and no mention of side effects on the current scene, the definition is not complete enough for an agent to call this destructive operation confidently.

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 single file_path parameter has 0% schema description coverage and no explanation in the description. The phrase '.hip file' only vaguely implies the expected path/extension, leaving format (absolute vs relative) and default behavior unstated.

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 (Load) and resource (.hip file) with the host application named, so the agent knows this opens a Houdini scene. It does not distinguish itself from siblings like lop_import, save_scene, or execute_houdini_code, but the core action 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?

There is no guidance on when to load a .hip versus importing via lop_import or running code, and no prerequisites noted. The agent must infer usage entirely 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?

No annotations are provided, so the description carries the full burden. It implies scene mutation (placing a camera) but says nothing about side effects, permissions, whether an existing camera is replaced, or how the bbox/aiming is computed.

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

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

Two short sentences, front-loaded with the core action, so it is not bloated. The second sentence, however, is unclear enough that it reads as noise rather than earning 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?

An output schema exists, so return values need not be explained, but for a 6-parameter mutation tool with zero annotation and zero schema-description coverage, the two-line description leaves the agent without enough 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% across 6 parameters (name, look_at, lop_path, input_path, parent_path, distance_scale), yet the description names none of them. 'looking at a prim bbox' loosely hints at look_at and the USD prim reference at input_path, but defaults, formats, and path semantics are entirely undocumented.

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

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

The first sentence gives a recognizable verb+resource ('Place a LOP Camera looking at a prim bbox'), so an agent can tell it creates a camera aimed at a prim. However, the second sentence ('Look through the USD prim string') is garbled and does not clarify the action or differentiate it from siblings like lookdev_dome or set_viewport_camera.

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 statement of when to use this tool versus alternatives such as frame_usd_prim, set_viewport_camera, or the other lookdev_* tools. The agent must infer context from the name alone.

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

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

No annotations, so the description carries full burden. It does disclose the exact attribute written (primvars:displayColor) and that it is not a material assignment, which is genuinely useful behavioral scope. However it omits permission needs, reversibility, and whether the prim must already exist — a meaningful gap for a mutation with zero annotation coverage.

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

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

A single front-loaded sentence with no filler; the key constraint is parenthesized right where it matters. Efficient, if extremely terse.

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?

An output schema exists so return values are covered, but with no annotations, 0% parameter documentation, and an ambiguous path/prim_path pair, an agent lacks what it needs to call this reliably. The description should at minimum clarify the two path parameters and the color format.

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% across three parameters and the description adds nothing to disambiguate them. Critically, 'path' and 'prim_path' are both undocumented strings with no stated distinction, and the 'color' array's expected length/format (e.g., RGB floats) is never given.

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 (Set), a precise target attribute (primvars:displayColor), and a resource (USD mesh). The parenthetical '(not a full material)' scopes it away from material tools like lookdev_preview_surface, giving real differentiation, though it doesn't name a sibling explicitly.

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 '(not a full material)' clause implies when this lightweight override is appropriate versus a real material, but there is no explicit when-to-use, prerequisites, or named alternative. Usage is inferable but not spelled out.

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 and fails to meet it. It does not say what 'edit' does to existing values, whether creation is idempotent, what 'mcp_* isolation' protects against, or what permissions are needed 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?

It is a single front-loaded sentence with zero filler, which is good structure, but at this length it omits necessary information rather than being appropriately sized for a 7-parameter mutation tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

Given 7 undocumented parameters, zero annotations, and a create/edit mutation surface, the definition is far too thin. The output schema exists, so return values need not be explained, but nearly everything else an agent needs to call it correctly is absent.

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% across 7 parameters, and the description names none of them (color, texture, exposure, primpath, parent_path, etc.). With no annotations and no schema text, an agent has no guidance on parameter meaning or interaction between them.

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 gives a specific verb+resource ('Create/edit a Dome Light LOP') that clearly separates it from sibling lookdev tools like lookdev_camera and lookdev_preview_surface. It stops short of full sibling differentiation, and 'mcp_* isolation' is jargon that an agent cannot interpret without external knowledge.

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 statement of when to use this tool versus alternatives, no prerequisites, and no conditions for choosing it over create_lop_node or list_lights. The only contextual hint is the 'mcp_* isolation' naming convention, which is unexplained.

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 does not state what happens to existing materials, whether the operation is destructive, what permissions or path constraints apply, or how the 'mcp_*' prefix behaves.

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 cryptic fragment. Although brief, it is under-specified rather than concise: the sentence does not earn its place because it fails to convey a clear operation or scope.

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 7 undocumented parameters, no annotations, and no usage guidance, the definition is completely inadequate for an agent to invoke the tool correctly. The presence of an output schema does not compensate for the missing input and behavioral 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 tool has 7 parameters and schema description coverage is 0%. The description adds no meaning for any parameter (name, color, metallic, roughness, input_path, parent_path, prim_pattern), so an agent receives no guidance beyond bare titles and defaults.

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 fragment 'USD Preview Surface + assignmaterial under mcp_*' names a resource type and an action, but no clear verb or scope. It does not distinguish this tool from siblings like lookdev_dome or lookdev_camera, leaving the agent to guess whether it creates, modifies, or applies materials.

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 guidance is given. There is no mention of alternatives, preconditions, or contexts that select this tool over the many other lookdev and USD-related siblings.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a stage mutation but does not state whether a stage must exist, whether the import is reversible, what path/prim_path refer to, or what the side effects are. This is a significant gap for a write 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?

A single front-loaded sentence with no filler or redundancy. It is efficient, though arguably under-specified rather than genuinely well-scoped.

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?

Although an output schema exists so return values need not be explained, the combination of 4 undocumented parameters, zero annotations, and an unclear mutation context leaves the definition inadequate. An agent cannot confidently invoke this with the given information.

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

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

Schema description coverage is 0% with 4 parameters, and the description only loosely gestures at 'file' and the 'method' (reference/sublayer). The required 'path' and optional 'prim_path' are left entirely undefined in both schema and description, so the description does not 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 names a specific verb (import) and resource (USD file) plus the mechanism (reference or sublayer), so the core action is clear. It does not differentiate from sibling USD/LOP importers like import_fbx_character, but the purpose itself 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?

There is no when-to-use guidance, no mention of prerequisites (e.g. an existing stage or LOP node context), and no routing to alternatives such as import_fbx_character or lop_layer_info. The choice between 'reference' and 'sublayer' methods is never explained.

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, and it says nothing beyond 'Get ... info'. It does not state that the operation is read-only, whether it requires an open USD stage or an existing LOP node, or what happens if the path is invalid.

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?

A single, front-loaded sentence with no filler or redundancy. It is efficient, though its brevity contributes to the missing detail noted elsewhere.

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?

An output schema exists, so return values need not be explained. However, with no annotations and an unspecified 'path' parameter, the definition leaves the agent guessing about both the input's meaning and how this tool differs from the other USD-inspection siblings.

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% for the single 'path' parameter, and the description does not compensate: it is ambiguous whether 'path' is a Houdini node path (e.g. /stage/lop) or a USD primitive path. This ambiguity matters 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?

States a specific verb ('Get') and resource ('USD layer stack info') scoped to a LOP node, so the agent knows it is a read of layer-stack data rather than stage or prim data. It does not, however, distinguish itself from close siblings such as lop_stage_info, get_usd_composition, or inspect_usd_layer, which plausibly overlap.

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 when-to-use guidance, no exclusions, and no named alternative. Given several siblings that surface USD information (lop_stage_info, get_usd_composition, inspect_usd_layer, list_usd_prims), the absence of routing guidance is a real gap.

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