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

Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds that the operation affects the graph layout and can be scoped to a selection, but does not say whether existing manual positions are overwritten, whether the result is deterministic, or whether it operates on the current comp 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?

Two sentences, front-loaded with the action, with no filler. The Args block is slightly redundant with the schema but is not verbose.

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

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

For a one-optional-parameter, no-output-schema tool whose annotations cover the mutation safety profile, the definition is nearly sufficient. A brief note on precedence over manual node positions would close the remaining 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 description coverage is 100% and the single parameter's description is identical to the text in the tool description, so no meaning is added beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 — 'auto-arrange the node graph layout' — which clearly distinguishes it from manual positioning siblings like set_node_position. It is clear on its own, though it does not explicitly contrast itself against any named alternative.

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 set_node_position or other layout-affecting tools. The selected_only flag hints at a scoping condition, but no when-to-use or when-not-to-use context is 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?

Annotations already cover idempotence and non-destructiveness, but the description adds useful behavioral detail: the knob value is preserved after the expression or animation is removed. It does not cover permissions or error behavior, but that is a minor gap for a simple non-destructive operation.

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

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

The description is front-loaded and brief, with the main effect stated first. The Args block redundantly repeats the input schema, but it does not bloat the definition significantly.

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

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

For a simple two-parameter mutation with annotations and no output schema, the description is mostly complete: it states the effect and value-preservation behavior. It could be strengthened by saying when to choose this over sibling set_expression or set_keyframe tools.

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

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

Schema description coverage is 100%, and the description's Args section simply repeats the schema descriptions for node and knob. It adds no syntax, format, or constraint information beyond what the schema already provides, so the baseline of 3 applies.

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: remove an expression or animation from a knob. It also distinguishes the operation from siblings like set_expression and set_keyframe by specifying removal and noting the knob is left at its current value.

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 explains what the tool does but gives no explicit guidance on when to use it versus alternatives like set_expression, set_keyframe, or other knob-modification siblings. There are no exclusions, prerequisites, or decision criteria.

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?

Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the Merge input default but omits what happens if the target input is already connected, whether existing connections are overwritten, or any permission requirements.

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

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

The description is short and front-loads the core action and the Merge exception. The Args block restates schema fields without adding value, a minor redundancy that keeps it from 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?

For a simple 3-parameter mutation with full schema coverage and two behavioral annotations, the description covers purpose and parameter defaults. It still omits edge-case behavior such as overwriting existing connections or error handling, but structured data fills most 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 100%, and the description's Args block mirrors the schema descriptions verbatim. It adds no new syntax, format, or constraint details, so the baseline of 3 applies.

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 resources: 'Connect two nodes.' The action is unambiguous, but the description does not explicitly differentiate this tool from siblings like disconnect_node_input or create_node, keeping it from 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?

Usage is implied by the action verb, and a Merge-specific default is provided. However, there is no explicit guidance on when to use this tool versus alternatives, nor any preconditions or exclusions.

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

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

Annotations only declare destructiveHint=false, so the description carries most of the burden. It does add a genuine behavioral nuance: for Merge nodes the connection goes to the B pipe rather than input 0. It does not cover side effects such as whether the node is created in the current script or what happens on naming collisions.

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

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

The first sentence is front-loaded and states the core action, and the Args block is compact. The Args block duplicates schema descriptions verbatim, which is minor waste but not damaging.

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

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

With no output schema, the description should say what comes back — e.g. the resulting node name, which matters because Nuke auto-names when 'name' is omitted and the caller may need that name for later wiring. That gap leaves the definition only partially complete for a creation 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 100%, so the schema already documents all three parameters in nearly identical wording. The description's Args block largely repeats that text, and the one useful addition (Merge B-pipe behavior) is also present in the schema. Baseline 3 is appropriate.

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 ('Create a node') and adds a distinctive capability ('optionally wire it to an existing node') that an agent can act on. It is not sharply differentiated from siblings like connect_nodes or setup_merge, but the create-plus-wire framing is clear enough to distinguish 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?

No guidance on when to use this versus connect_nodes (which wires existing nodes), setup_merge, or the many setup_* helpers. The 'optionally wire' phrase hints at a use case but never states the condition that selects this tool over the alternatives.

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

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

Annotations only declare destructiveHint=false, so the description must carry the rest. It does add one real behavioral fact: the new node is wired to the input. However it says nothing about what is returned, whether the node is auto-positioned, or any side effects on the existing comp.

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 plus a brief args block; the purpose is front-loaded in the first clause. The args restatement is mildly redundant but harmless.

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

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

For a two-parameter creation tool with no output schema, the description covers the essentials but leaves open what the tool returns (node name/handle) and how it relates to the generic create_node sibling. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema with the same wording the description repeats. The description adds no format, allowed-value, or defaulting detail beyond what the schema provides, which is the baseline-3 case.

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 ('Create a Roto or RotoPaint node') plus the key structural behavior (connected to the input), which distinguishes it from generic siblings like create_node or setup_precomp. It stops short of explicitly naming which sibling to prefer when a plain node would do.

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 mention of the alternative create_node, which also creates nodes. The agent must infer that this tool is the specialized path for roto/paint nodes.

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

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

Annotations already declare destructiveHint=true, and the description adds genuinely useful safety context beyond that: the two-step dry-run workflow via confirm=False to preview before committing. It does not mention side effects like whether attached connections are also removed, so not a 5.

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

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

The purpose sentence is front-loaded and the confirm workflow follows immediately. The Args block duplicates the input schema, which is mild waste, but overall it is short and readable.

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

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

For a two-parameter delete with no output schema, the definition covers the core action and the safety mechanism an agent most needs. It omits a few useful facts (prerequisites, whether the node's connections are affected), keeping it just short of complete.

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

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

Schema description coverage is 100%, and the description's Args block simply restates both schema descriptions verbatim, adding no syntax, format, or behavioral detail beyond the schema. Baseline 3 is correct when the schema does the full job.

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 from the script'), which is unambiguous and clearly distinct from siblings like create_node and modify_node by name. It does not explicitly name or contrast with any sibling, so it stops short of a 5.

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

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

The confirm parameter guidance ('call with False first to preview') gives a concrete workflow, but there is no guidance on when to reach for this tool versus related ones such as disconnect_node_input or modify_node, nor any stated prerequisite (e.g., a loaded script). Implied usage only.

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?

readOnlyHint=true already establishes this is a safe read, so the bar is lower. The description adds real value beyond the annotation by disclosing the prerequisite dependency and the exact nature of the output (added/removed nodes, changed knobs). It stops short of describing edge cases such as what happens with an invalid or stale snapshot_id.

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 purpose in one tight sentence, then the prerequisite, then the arg. Efficient overall, though the Args block restates what the schema already documents, which is mild redundancy.

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

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

With an output schema present, return values need not be explained, and the readOnly annotation covers the safety profile. The prerequisite and diff contents make it callable as-is; the only gap is not relating it to the other diff-like siblings in the toolset.

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 100% and the single parameter's description already reads 'ID from a previous snapshot_comp call'. The description repeats this verbatim, adding no syntax, format, or validity constraints beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 (compare/diff) and resource (current comp vs previous snapshot), and enumerates exactly what the diff surfaces (nodes added, removed, knobs changed). This distinguishes it clearly from sibling snapshot_comp, which creates rather than compares snapshots.

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

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

Explicitly gives the prerequisite 'Call snapshot_comp first', which tells the agent the correct ordering and which tool must precede it. It does not, however, mention when to prefer it over related siblings like scene_delta or scene_digest.

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?

Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that – it doesn't say what happens to the node after disconnect, whether downstream processing is affected, or what it returns.

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 definition is short and front-loads the purpose in the first sentence. The Args block is technically redundant with the schema but is compact and harmless.

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

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

For a simple two-parameter tool with full schema coverage and annotations covering safety, the description is adequate to invoke correctly. It omits any behavioral consequence of disconnecting an input, which would have rounded it out.

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 100%, and the description merely restates the schema's own param descriptions verbatim (node name, 0-based input_index). Baseline 3 is appropriate since the schema already carries full param 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 (disconnect) and resource (a specific input on a node), which cleanly separates it from the sibling connect_nodes. However, it does not explicitly name or contrast with any sibling, leaving that differentiation 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 guidance on when to use this versus connect_nodes, modify_node, or delete_node, and no prerequisites or context about the workflow state. The usage is only implied by the verb itself.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds nothing behavioral beyond what the schema states (case-insensitive matching is already in the schema), and gives no information about result ordering, limits, or what an empty result means.

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 opening sentence is well-formed and front-loaded, but the Args block duplicates the schema descriptions word-for-word, adding length without value. Trimming it would lose 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?

No output schema exists, so the description should say something about what a node result looks like or how results are shaped, and it does not. It is adequate for calling the tool but leaves result interpretation and the list_nodes/find_nodes choice unresolved.

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 100%, so the schema already documents all three parameters. The Args block restates those same descriptions verbatim, adding no new syntax, format, or combined-filter semantics. Baseline 3 applies.

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 names a specific verb (search) and resource (nodes) and enumerates the filter dimensions (type, name pattern, error state), which is clearer than a bare 'get nodes'. However it does not distinguish itself from the sibling list_nodes, leaving an agent unsure 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?

No when-to-use guidance is given, and no alternative is named. The sibling set contains both list_nodes and find_nodes, and the description offers no rule for choosing between them or any statement about when filtering is preferable.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered, and 'Read' is consistent with that. Beyond this, the description adds nothing behavioral: it does not say what happens if the node or knob is missing, nor that knob values vary in type (int, float, string, array), which is meaningful for a getter with no output schema.

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

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

The core sentence is short and correctly front-loaded, but the trailing 'Args' section is a verbatim copy of the input schema and therefore earns nothing. Roughly half the text is redundant, which dilutes rather than aids the description.

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

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

For a simple two-parameter read tool whose annotations already establish the safety profile, this is minimally adequate. With no output schema, the description could reasonably have stated the variability of knob return types; that omission is the main completeness 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 description coverage is 100%, so the schema fully documents both parameters. The 'Args' block in the description merely duplicates the schema text verbatim (including the same example knob names), adding no syntax or format detail beyond what structured data already provides. Baseline 3 applies.

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

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

The opening sentence 'Read a knob value from a node' gives a specific verb (read), resource (knob), and scope (from a node), which is clear and unambiguous. However, it does nothing to distinguish itself from the sibling set_knob (the write counterpart) or read_node_detail, leaving the agent to infer the boundary between reading one knob and reading full node data.

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

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

No when-to-use guidance is given. The description never mentions the natural alternative set_knob for writing, nor when to prefer get_knob over read_node_detail when the agent needs broader node data. Usage must be entirely inferred 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?

readOnlyHint=true already establishes this as a safe, side-effect-free read, so the description's main contribution is the field inventory. It does not disclose whether the values reflect saved or in-memory state, latency, or whether it is cheap enough to poll, which for a metadata probe would be genuinely useful.

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

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

One sentence, front-loaded with the verb and resource, then the field list. Nothing is padded and nothing extraneous is present.

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

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

With no parameters, no output schema, and only a readOnlyHint annotation, the description carries the burden of describing the return payload and does so explicitly. Only the absence of guidance against overlapping siblings like scene_digest leaves 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?

The tool takes zero parameters (schema coverage 100%), so the baseline is 4. The description correctly adds no parameter discussion and instead spends its words on the return contents, which is the right allocation.

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 ('current script metadata') and enumerates the returned fields, so the agent knows exactly what it retrieves. It does not, however, distinguish itself from adjacent metadata-flavored siblings such as read_comp or scene_digest.

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 indication of when to call this versus read_comp, scene_digest, or read_node_detail. No preconditions, no exclusions, no alternatives are named.

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?

Annotations declare readOnlyHint=true, so the safety profile is covered. The description adds that output is grouped by layer, which is useful behavioral context, but it does not describe return format details such as channel count, ordering, or edge cases (e.g., nodes with no channels). With annotations carrying the safety burden, a 3 is appropriate.

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 one efficient sentence plus an Args block that duplicates the schema. It is front-loaded and contains no filler, though the Args duplication is slightly redundant.

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

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

For a simple read-only single-parameter tool, the description is adequate. It lacks guidance on when to use it versus sibling inspection tools and does not clarify output structure beyond 'grouped by layer.' Without an output schema or usage guidance, it is minimally complete rather than rich.

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 100%, and the single parameter 'node' is fully documented in the schema. The description repeats the same parameter explanation, adding no new syntax or format details. Baseline 3 is correct when the schema does the heavy lifting.

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: 'List all channels/layers available at a node's output, grouped by layer.' This is clear and concrete. However, it does not differentiate itself from siblings like read_node_detail, which may also expose channel information, 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 or mention of alternatives. The description does not say when an agent should call list_channels versus read_node_detail or other node inspection tools, leaving routing 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?

readOnlyHint=true already signals a safe read, so the bar is lower. The description adds that the result is frame/value pairs, which is useful, but discloses nothing about ordering, empty results, or interpolation/curve context.

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

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

The leading sentence is front-loaded and efficient, but the Args section verbatim duplicates the input schema, adding length without adding 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?

For a two-parameter read-only listing tool with no output schema, the description covers purpose, inputs, and the shape of the returned data, which is adequate. Minor gaps remain around ordering of returned keyframes.

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 100%, so the schema already documents both parameters; the description's Args block merely restates the same text ('node: node name.', 'knob: knob name to inspect.') without adding format, naming convention, or lookup hints.

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 ('List all keyframes on a knob') and names the return shape. It is distinguishable from the sibling set_keyframe, though it does not explicitly contrast with it or with get_knob.

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 routing to alternatives such as set_keyframe (for writing keyframes) or get_knob. 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?

readOnlyHint=true already establishes this as a safe read, lowering the disclosure bar. The description adds the Group-scoping behavior, but says nothing about the return shape (flat list vs tree, ordering) or pagination. Useful context beyond annotations, but not rich.

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

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

The core purpose is front-loaded in one sentence, and the rest is short. The Args block is somewhat redundant with the schema, costing a little space, but nothing is padded or buried.

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 single-optional-param read tool with readOnlyHint annotations, this covers what is needed to call it correctly. The main omission is return format, which matters mildly for a listing tool with no output schema.

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 100%, so the single root parameter is already fully documented in the schema. The description's Args block restates the schema text verbatim, adding no format, default, or lookup semantics beyond it. Baseline 3 applies.

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 ('List all nodes in the script') and adds the conditional variant for Group children. However, it never distinguishes itself from the sibling find_nodes, so an agent cannot tell from the description alone which listing tool 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?

Usage is implied: pass a Group name via root to list children, omit it to list everything. There is no explicit when-not guidance and no named alternative (e.g. find_nodes for filtered lookup), so the agent must infer the choice.

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

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

readOnlyHint=true already establishes this as a safe, non-mutating call, so the description is not required to restate safety. Beyond that it adds almost nothing: it does not say whether disabled/muted precomps are included, what pairing means concretely, or what the result contains. The whole-script scope is the only marginal addition.

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 no filler and the action front-loaded, so it is appropriately sized for a trivial listing tool. It is arguably too terse in that terms like 'Write/Read pair' are never unpacked, but there is no wasted text to trim.

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

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

For a simple parameterless read tool this is minimally adequate: an agent knows it lists precomp pairs. Since there is no output schema, the description is the only place return shape could be described, and it leaves the result structure and ordering unspecified.

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 sets the baseline at 4 per the scoring rules; there are no arguments whose semantics could be clarified. No penalty is warranted since there is nothing 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?

The description gives a specific verb (find/list) and a specific resource (precomp Write/Read pairs) scoped to the script, so an agent knows this enumerates precomp wiring rather than node lists. It does not, however, contrast itself with the sibling setup_precomp, which is the nearest alternative. Clear but undifferentiated from 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?

There is no when-to-use, when-not-to-use, or alternative routing guidance. An agent must infer that this is a read-only discovery call and guess when setup_precomp or read_comp would be the better choice. No conditions or prerequisites are stated.

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

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

readOnlyHint=true already declares this is a safe read, so the bar is lower; the description still adds real behavioral context by explaining what the loaded flag means at runtime. It stops short of covering return ordering or any scale/pagination behavior, which is why it is not a 5.

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

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

Three short sentences, front-loaded with the action and its outputs, then the follow-up call, then the state semantics. No filler and nothing repeated from structured fields.

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

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

With no output schema, the description carries the burden of describing returns and does so explicitly (description, tool count, loaded state). An agent has everything needed to call it and act on the result.

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

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

The tool takes no parameters, so the baseline is 4. The description discusses the returned name field rather than inputs, which is appropriate since there is nothing to disambiguate on the input side.

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 ("List every skill profile") and enumerates the returned fields (description, tool count, loaded state). It is clearly separable from sibling listers like list_precomps, list_channels, and list_nodes, and it names load_profile as the downstream consumer.

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 second sentence gives explicit routing: take the returned name and pass it to load_profile, plus the condition that loaded=True profiles are already visible. There is no explicit when-not-to-use statement, but the discover-then-load workflow is unambiguous.

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

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

readOnlyHint=true already establishes this as a safe read, and the description adds that it returns shapes AND strokes, which is useful scope. However it says nothing about return format, ordering, or whether nested/grouped shape data is included, so it adds only modest context beyond the annotation.

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

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

The purpose sentence is front-loaded and efficient. The Args block is redundant with the schema but costs little and is a common convention.

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

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

For a simple one-param read tool this is nearly adequate, but there is no output schema, so the description should ideally sketch what a returned shape/stroke record looks like. That gap is the main thing missing.

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

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

Schema description coverage is 100% and the single parameter is fully documented there; the description's Args block merely repeats the schema text verbatim. No extra semantics (e.g. accepted node path formats) are contributed.

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 resource (shapes and strokes in a Roto/RotoPaint node), so the agent knows exactly what comes back. It does not name or differentiate itself from any sibling, 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 when-to-use guidance, no prerequisites, and no mention of alternatives such as read_node_detail or get_knob for inspecting a node. The agent must infer the context 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?

Annotations provide only destructiveHint=false, so the description carries most of the behavioral burden and does so well: it declares idempotency (already-loaded load is a no-op) and a concrete side effect (emitting notifications/tools/list_changed so the client refreshes). It stops short of describing failure behavior for an unknown profile 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 purpose is front-loaded in the first sentence, followed by the behavioral caveats and the argument note, with no filler. The multi-line wrapping is slightly awkward but every sentence contributes 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?

For a one-parameter activation tool with a minimal annotation set and no output schema, the description covers purpose, idempotency, and the side effect on the client tool surface. Error handling for an invalid profile name is the only notable omission.

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 100% and the single parameter is documented identically in the schema and the Args block. The description therefore adds nothing beyond the structured field, matching the baseline for full schema coverage.

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

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

States a specific action (surface every tool) targeted at a named resource (profile ``name``), which is unambiguous on its own. It does not explicitly contrast with the closely related siblings `unload_profile` and `list_profiles`, so the differentiation is inferable rather than stated.

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

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

It points the agent at `list_profiles` to obtain a valid profile name, which is useful routing guidance. However, it never states when to load vs. unload a profile or what precondition must hold, leaving usage context implied.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the agent knows this is a destructive, externally-resolving operation. The description's 'Replaces current script' partially aligns with that. However, it omits critical behavioral detail: whether unsaved changes are discarded, whether a confirmation prompt is required by the host, return format, and error conditions. With annotations covering safety, this rate sits below baseline.

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 opening sentence is front-loaded and concise, but the Args block duplicates the schema verbatim, wasting space. No extraneous prose, but no structural advantage over the schema either.

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

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

For a destructive, openWorld operation with no output schema and 100% schema coverage, the description is minimally adequate: it states the replace behavior and the confirm flow. It omits what happens to the current script's unsaved state and failure modes, which a caller needs before invoking a destructive load.

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 100%, so both parameters are already documented in the schema. The description repeats the exact schema text ('path: .nk file to open', 'confirm: must be True to proceed...'), adding no syntax or format detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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: 'Open a Nuke script.' The destructive caveat ('Replaces current script') distinguishes it from save_script, which writes rather than replaces. It does not explicitly name a sibling, but the replace semantics make the boundary clear.

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

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

The confirm pattern is described (call with False first to preview), which implies usage, but there is no explicit when-to-use/when-not-to-use guidance or routing to alternatives like load_profile. The two-step confirm flow is the only contextual 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?

Annotations cover idempotency and the non-destructive profile, lowering the bar, and the description adds real behavioral context: it discloses that the tool checks for expressions referencing the node and can auto-fix them. It doesn't clarify failure modes or what happens when expression updates are declined, keeping it 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?

The purpose is front-loaded in the first sentence, and the remaining text is compact. The Args block duplicates the schema descriptions, which is mildly redundant but keeps the definition readable.

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 rename mutation with no output schema, the description covers the essential behavior (expression checking/updating) and the parameters. An agent has enough to invoke it correctly, though return behavior and edge-case handling are left implicit.

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 100%, so the schema already documents all three parameters, and the description's Args block essentially restates those same descriptions verbatim. Baseline 3 is appropriate since the description adds no meaningful semantics beyond the schema.

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

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

States a specific verb and resource ('Rename a node') that clearly distinguishes it from create_node and delete_node in the sibling list. The description is unambiguous about what the tool does, though it does not explicitly name or contrast with any sibling tool.

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

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

There is no explicit when-to-use guidance or mention of alternatives like create_node, delete_node, or set_expression. The purpose implies the use case, but no conditions, prerequisites, or exclusions are stated.

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

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

Annotations only declare readOnlyHint=true, so the description carries extra weight and does add it: it discloses the exact return shape (name/type/connections vs. knobs), the performance trade-off of summary, and pagination semantics. It does not mention permissions, truncation defaults beyond limit=0, or ordering of returned nodes.

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 correctly with purpose then scaling guidance. However, the Args section duplicates the 100%-covered schema descriptions word-for-word, which is pure redundancy rather than earned content.

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

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

For a read-only tool with no output schema, the description adequately covers what is returned, how to control volume, and how to page. Only minor gaps remain (default depth of 999 vs. practical recursion limits, node ordering).

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 100%, so the baseline is 3. The Args block in the description is essentially a verbatim restatement of each schema description, adding no new semantics such as knob-value formatting, accepted type strings beyond one example, or depth interaction with root.

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 ('Read the node graph (or a subtree)') and enumerates the return payload (type, connections, knob values, error state). It does not, however, distinguish itself from close siblings like list_nodes, find_nodes, or read_node_detail, so an agent still has to infer which of the three node-reading 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?

Gives concrete usage conditions: use summary=True for comps of 200+ nodes, and use offset/limit to paginate. This is real when-to-use guidance for scaling. What's missing is any statement of when to prefer this tool over the sibling list/find/read_node_detail 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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds real behavioral context beyond that: it discloses the scope of returned data (all non-default knobs, input/output connections, expressions, animation state, error info) and that Groups/Gizmos recurse into internal structure. It does not mention cost, truncation, or missing-node 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?

Front-loaded with the core purpose, then a compact enumeration of return contents. The trailing 'Args:' block mostly duplicates the schema and the description body, which is slight waste, but the passage overall is tight and earns its 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 defined here, yet the description still summarizes them helpfully. Combined with the readOnly annotation and full param coverage, an agent has enough to invoke correctly; only the lack of guidance on when this beats sibling readers leaves a 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?

There is a single parameter and schema coverage is 100%, so the schema already documents 'name'. The description only restates it verbatim ('node name to inspect'), adding no format, path syntax, or scoping detail. Baseline 3 applies.

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: 'Deep inspection of a single node', and enumerates what is returned (knobs, connections, expressions, animation state, errors) plus the Group/Gizmo special case. It separates itself informally from lighter siblings like get_knob or view_node via the word 'deep', but never names an alternative, so it stops short of a 5.

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

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

Usage is implied by the words 'deep inspection', suggesting it is for thorough per-node dives rather than the narrower get_knob/view_node reads, but no explicit when-to-use or when-not-to-use rule is given. An agent must infer from sibling names 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?

Annotations only declare openWorldHint and destructiveHint; the description adds substantial behavior beyond them: default async execution returning a task_id, background rendering, a terminal-state notification, the blocking synchronous alternative and its return type, and the confirm-must-be-True safety gate. This is exactly the kind of operational detail annotations cannot convey.

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 and the async/sync distinction before the Args list, which is well ordered. The Args section largely re-states the schema and the mid-sentence back-compat parentheticals add slight bloat, but overall it reads 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?

An output schema exists, so return values need no explanation, and the description fully covers the async/sync execution models, polling/interruption path, and the confirm preview gate. Nothing essential to correct invocation is missing.

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

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

Schema coverage is 100% and the Args block essentially repeats the schema descriptions verbatim (write_node, first_frame, last_frame, confirm, synchronous). The confirm semantics and default ranges are clarified well but duplicated, so the description adds little beyond what the schema already provides.

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

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

States a specific verb ('Render') and resource ('frames through a Write node'), and the first sentence immediately establishes scope. An agent can distinguish it from configuration siblings like setup_write or traversal tools like find_nodes without opening the schema.

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

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

Explicitly explains the default async behavior and when to use the synchronous path (pre-B2 blocking shape, wire-compatible). It names the follow-up tools (tasks_get for polling, tasks_cancel to interrupt) and the confirm gate for preview vs. render, giving clear operational context, though it never compares itself to a sibling tool or states when not to render through this path.

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

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

The only annotation is openWorldHint: true, so the description must carry the behavioral load. It does not disclose whether saving requires specific permissions, whether it overwrites an existing file on save-as, whether the operation is destructive, or what the return value is. For a mutation tool with almost no annotation coverage, this is a significant gap.

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

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

Uses a clean two-sentence structure with the conditional behavior front-loaded, but then duplicates the parameter description in an Args block that adds no information. The duplication is not terrible but reduces 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 no output schema and only a permissive openWorldHint annotation, the description should explain what happens on save, whether the operation can fail, and its effect on existing files. It covers the path semantics but leaves the core behavioral context 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 100%, so the schema already fully documents the single 'path' parameter, including that it is optional and what it does. The description's Args block merely repeats the schema text verbatim; it adds no new semantics or format details.

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

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

States a specific verb+resource: saving the script, with a conditional distinction (path given → save-as, omitted → save in place). Siblings like load_script and get_script_info are clearly different operations, though the description doesn't explicitly name them, so it's clear without explicit sibling differentiation.

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

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

Gives a clear conditional on when the behavior changes based on the 'path' argument. However, it offers no guidance on when to use this tool vs. alternatives like setup_write or render_frames, which are the more common ways to persist output.

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 readOnlyHint=true already covering the safety profile, the description adds real value: the exact two-branch return shape and the notable fact that the unchanged path avoids leaking graph enumeration into the response. It does not address behavior on a stale or invalid hash, which keeps it below 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-loaded with the core purpose, then the two return branches, then args. The Args section merely restates the schema description, which is mild redundancy but not 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?

There is no output schema, so the description's return-value disclosure is doing necessary work and covers both branches well. It is nearly complete for a one-parameter read tool, with error/stale-hash behavior the only 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 100% and the single parameter's description is verbatim duplicated in the prose, so the description adds no meaning beyond the schema. Baseline 3 is correct.

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: comparing current scene state against a previous hash. It is clearly distinguishable from the digest-producing scene_digest, though it never names that sibling or diff_comp explicitly to route the agent.

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

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

Describes the intended workflow: prev_hash comes from a prior scene_digest or scene_delta call, implying this is used to check whether anything has changed since a known snapshot. No when-not guidance or explicit alternatives are given, so it stops short of a 5.

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

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

With readOnlyHint=true already covering the safety profile, the description adds a genuine behavioral trait: output is stable across no-op turns, which is exactly the property an agent needs for delta-based caching. It does not cover cost, rate limits, or error behavior, but the added determinism note is substantive.

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

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

Two short sentences with no filler; the payload contents come first and the scene_delta pairing second. The mid-sentence line break hurts readability slightly but wastes no words.

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

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

For a zero-parameter read tool with no output schema, the description effectively substitutes for a return-value spec by enumerating the fingerprint's fields. It leaves the exact shape (e.g., how counts are keyed) implicit, but an agent has enough to decide and invoke.

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

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

The tool takes zero parameters, so the schema carries nothing to document and the baseline of 4 applies. Nothing in the description contradicts or duplicates a parameter contract.

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 (the script's scene) and enumerates the exact contents of the fingerprint (counts by class, errors, warnings, selection, active viewer, display node, md5 hash), and it explicitly names the sibling scene_delta as the paired tool, so it is distinguishable without opening a schema.

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

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

"Pair with scene_delta to skip re-rendering large response payloads when nothing has changed" gives clear context for when this tool's output is useful, and the no-op stability property hints at the polling use case. It stops short of an explicit when-not-to-use statement or listing other alternatives among the many read_* 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?

Annotations already declare idempotentHint=true and destructiveHint=false, so the description need not cover repeatability or safety classification. It adds useful behavioral context beyond annotations: per-frame evaluation and a regex pre-flight rejecting forbidden Python/TCL calls.

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 purpose and behavior, then provides examples and restrictions. The Args section repeats the schema descriptions verbatim, which is slightly redundant, but the overall structure is efficient and readable.

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 setter tool with no output schema and full schema coverage, the description covers purpose, expression format, security behavior, and parameter meanings. It could mention clearing expressions via the sibling clear_expression, but otherwise an agent has enough 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 100%, so the baseline is 3. The description adds meaning beyond the schema by giving concrete TCL expression examples (frame, frame/24.0, sin(frame*0.1)) and noting security restrictions on expression content.

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: 'Set a TCL expression on a knob,' and clarifies per-frame evaluation. This clearly distinguishes it from sibling tools like set_knob and clear_expression.

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

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

Provides common expression examples and security restrictions, which imply usage context, but does not explicitly say when to use this tool versus set_knob or clear_expression. No exclusions or alternative routing 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?

Annotations declare idempotentHint=true and destructiveHint=false, so the agent knows this operation is safe and repeatable. The description adds that it sets the frame range and/or current frame, which clarifies scope but does not disclose additional behavioral traits beyond the annotations. It doesn't contradict them; it simply confirms the setting behavior.

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

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

The description is a single, front-loaded sentence that states the core action, followed by a concise parameter list. There is no wasted text, though the Args section slightly duplicates the schema descriptions. It is appropriately sized.

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

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

With annotations covering safety and idempotency, and the schema fully documenting parameters, the description is adequate for a simple setter tool. However, it lacks details on what happens if only some parameters are provided (e.g., setting just current leaves range unchanged) and doesn't explain the effect on the timeline state. No output schema exists, so return value explanation isn't needed, but completeness is only minimal.

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 100%, so all parameters are already documented in the schema with descriptions like 'last frame number.' The description repeats these parameter explanations without adding new semantics or format details. Baseline 3 is appropriate when the schema already covers the parameters.

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

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

The description clearly states a specific verb and resource: set the timeline frame range and/or current frame. It distinguishes itself from siblings like set_keyframe or set_knob, which operate on different objects. However, it does not explicitly differentiate from any similar sibling because none directly overlap, so it's clear but not exceptional.

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. Usage is implied by the purpose—setting timeline frame range or current frame—but no conditions or exclusions are provided. Since no direct sibling overlap exists, implied usage is minimally adequate.

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?

Annotations already declare idempotentHint=true and destructiveHint=false (safe, repeatable), and the description usefully adds that missing animation tracks are created automatically. However it is silent on what happens when a keyframe already exists at the frame (overwrite vs add) and on value units, which matters for a mutation tool.

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

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

The first sentence is well front-loaded and does real work, but it is followed by an Args block that duplicates the input schema word-for-word, adding length without 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?

For a 4-required-param mutation with no output schema and annotations covering the safety profile, the description is adequate but leaves out overwrite semantics, value units, and error behavior when node/knob are invalid.

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 100%, so the schema already documents all four parameters. The Args block merely restates those descriptions verbatim ('node: node name.', 'value: value at that frame.') with zero added meaning, so baseline 3 applies.

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 ('Set a keyframe on a knob') and adds the meaningful side effect that animation is created if absent. It is implicitly distinguishable from siblings like set_knob and list_keyframes, though it never names the alternative it supersedes.

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 versus set_knob, set_expression, or keyframe-editing siblings, and no prerequisites (e.g. that node/knob must already exist). The agent must 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?

Annotations already establish idempotentHint=true and destructiveHint=false, so the agent knows repeat calls are safe and nothing is destroyed. The description adds the type-dependent nature of the value argument but says nothing about validation failures, whether the knob must exist, or error behavior. Adequate but thin given the annotations carry the safety profile.

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

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

Short and front-loaded, with the operation in the first sentence and parameters listed after. The Args block mostly duplicates the schema, which is mild waste, but the whole thing is compact overall.

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

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

For a simple 3-param mutation with no output schema, the description is minimally sufficient. It lacks any note about which node/knob combinations are valid or what happens on failure, but the schema and annotations cover the essentials.

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 100%, so all three params already carry their meaning in the schema, and the Args block largely repeats it. The one added nugget is 'type depends on the knob' for value, which warns the agent to match the knob's expected type. Otherwise baseline 3 applies.

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 specific verb (set) plus resource (knob value on a node). It distinguishes itself from the sibling get_knob, which reads the value rather than writing it. It doesn't explicitly call out that distinction, but the verb picks it out.

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?

Setting a knob value is implicitly the right tool whenever a knob needs to change, and get_knob is the obvious read counterpart. But there's no explicit when-to-use guidance, no note about when to prefer set_expression or set_keyframe for animating that same knob.

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?

Annotations declare idempotentHint=true and destructiveHint=false, and the description is consistent with that, adding a layout heuristic rather than behavioral facts. It does not disclose whether these positions are display-only and independent of render output, nor whether coordinates are absolute or relative, so it adds little beyond the 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 purpose sentence is front-loaded and efficient, but the Args section duplicates the schema's parameter description and example verbatim, which is dead weight since the schema already carries it.

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 single-parameter, non-destructive layout tool with no output schema is adequately covered: what it does, how to call it, and an example payload. The only notable omission is the manual-vs-automatic layout distinction.

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 100% and the description's Args block repeats the schema's parameter description almost verbatim, including the same example. No extra syntax or semantics beyond the schema's own 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 concrete verb+resource: 'Set x/y positions for one or more nodes in the DAG', which an agent can distinguish from sibling mutations like modify_node or connect_nodes. It does not explicitly name the closest sibling, auto_layout, so it stops short of a 5.

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

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

Gives a positive usage context ('Use for manual layout control') and a heuristic (main pipe vertical, branches right), which implies the manual counterpart to auto_layout. However it never states when NOT to use it or names the automatic alternative explicitly, leaving the routing decision 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?

Annotations only declare destructiveHint=false, so the description carries most of the behavioral burden. 'Production defaults' is the one real piece of extra context (the node arrives pre-configured rather than blank), but it doesn't say what those defaults are, whether the input_node is consumed/modified, or what is 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?

Two short sentences, front-loaded with the action and padded only slightly by an Args section that duplicates the schema. Nothing superfluous but nothing especially tight either.

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 one-parameter setup tool this is roughly adequate, but with no output schema the description should say what the call yields (e.g., a node reference or name) and what 'production defaults' concretely means. Those gaps are minor but real.

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 100% and the description's Args line restates the schema field verbatim ('node to denoise'), adding no new meaning. With only one well-documented parameter, the baseline 3 applies.

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+resource pair is specific: create a Denoise node, with the qualifier 'production defaults' signaling a preset configuration rather than a bare node. It's clearly a specialization of the generic create_node sibling, though the description never names that sibling or explains what makes this different beyond the defaults.

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 routing guidance at all. An agent must infer from the name alone that this is the preferred tool for adding denoising versus using create_node and configuring the node manually.

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?

Annotations only state destructiveHint=false, a low bar. The description adds useful behavior in noting it auto-connects fg to the B pipe, which is real side-effect disclosure beyond the annotations. It doesn't mention failure modes (e.g., nonexistent node names) or any permission/state requirements.

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

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

Front-loaded one-line purpose followed by a compact Args block; no wasted prose. The Args block duplicates schema info but is easy to scan.

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

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

For a 3-param setup tool with no output schema, the description covers the core action and the auto-connect side effect, but omits operation list completeness beyond examples, error behavior, and how it relates to sibling node tools. Adequate but with clear gaps.

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

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

Schema description coverage is 100% and the description essentially restates the parameter descriptions verbatim, adding no new syntax, default, or allowed-value detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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: merges a foreground over a background, which is a clear compositing operation. It's distinguishable from sibling setup tools by the merge action, though it doesn't explicitly name a sibling to contrast with.

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 operation semantics (compositing two existing nodes), and the auto-connect note hints at when it's handy, but there is no explicit when-to-use vs. an alternative like connect_nodes or 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?

Annotations only declare destructiveHint=false, so the description carries most of the behavioral burden and does so well: it discloses that two nodes are created, that downstream nodes are rewired to the Read (a non-obvious graph mutation), and that the Write path is auto-generated when omitted. It stops short of describing return values or failure modes.

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

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

The behavioral paragraph is front-loaded and earn-worthy, but the trailing 'Args' section duplicates the input schema's descriptions word-for-word, adding length without new information. Roughly a third of the definition is redundant.

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

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

For a three-parameter mutation tool with no output schema, the description covers what gets created and the rewiring side effect, which is the essential context. Missing only explicit usage routing and any indication of the response or error behavior.

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

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

Schema description coverage is 100%, so the baseline is 3. The 'Args' block merely restates the schema descriptions for source_node, name, and path verbatim, adding no format, constraint, or interaction detail beyond what the schema already provides.

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

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

The description states a specific verb and resource ('Set up a precomp') and spells out the concrete result: a Write node for the source plus a Read node that reads the rendered output back, with downstream nodes rewired. That is specific enough to distinguish it from generic node creation, though it never names the close sibling setup_write to explain the boundary between 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?

Usage is only implied by the operation itself ('set up a precomp'); there is no explicit statement of when to choose this over setup_write or manual create_node/connect_nodes, nor any prerequisite or exclusion. An agent can infer the intent but gets no routing 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?

The only annotation is destructiveHint=false, and the description adds no behavioral context beyond it: nothing about where the node is placed, whether it is connected, what the return value is, or what the operation default does. For a creation tool with minimal annotation coverage, the description carries more burden than it meets.

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?

Purpose is front-loaded in a single short sentence and the parameter list is compact. It is efficiently sized, though the Args block duplicates schema content and earns little of its 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?

Adequate minimum for a 2-parameter creation tool with no output schema: the agent knows what is created and what inputs are needed. It omits what the resulting node references or how placement/connection works, which an agent likely needs to chain this with connect_nodes or set_node_position.

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 100%, so baseline 3 applies. The description's Args block merely restates the schema text ('node to transform', the four operation values) with no additional semantics such as ordering, exclusivity, or default behavior beyond what the schema already declares.

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 ('Create a transform node'), which is clear and actionable. However, it does not differentiate itself from close siblings like create_node, setup_merge, setup_denoise, or setup_precomp, all of 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 guidance on when to use setup_transform versus create_node or the other setup_* siblings. The agent is left to infer that this is the specialized path for the four node types listed, but nothing states that explicitly.

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?

Only a destructiveHint=false annotation is present, so the description must carry the safety burden. The 'A3' note usefully discloses validation behavior (allowlist enforcement, path traversal rejection) beyond the schema, which is genuine added value; however, it doesn't state idempotency, whether an existing Write node is overwritten, or what defaults are set.

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 concrete action and connection target, which is the most important fact. The duplicated Args section is mild redundancy rather than noise, and the A3 validation note earns its place as behavioral disclosure.

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 4-param node-creation tool with a full schema and a destructiveHint annotation, the description covers what gets created and how it wires up. Missing only the resolved 'production defaults' and overwrite/idempotency semantics, minor gaps for arguably the most common setup 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 100% and the Args block repeats the same parameter text verbatim, adding no new meaning. Baseline 3 applies when the schema already documents all parameters. The 'use #### for frame padding' syntax is the only marginally useful hint, and it already exists in the schema.

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

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

States a specific verb+resource ('Create a Write node') and adds scope ('connected to input_node with production defaults'). Distinguishes from sibling setup_precomp/setup_merge/setup_transform/setup_denoise by naming the exact node type created and the input wiring behavior.

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 'production defaults' phrase and the file_type allowlist imply when to use this convenience tool vs. composing create_node + connect_nodes + set_knob manually, but the routing is left to inference. No explicit when-not or named alternative.

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

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

Annotations already declare idempotentHint=true and destructiveHint=false, so safety profile is covered. Description adds that it changes the viewer display, but doesn't disclose whether the change persists across sessions, affects all open viewers, or requires a valid node context. With annotations, this is adequate but not rich.

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

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

Two sentences: one-line purpose followed by a clearly labeled Args section. Zero waste, front-loaded, appropriately sized for a single-parameter 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 no output schema and full schema coverage, the description covers the essentials. However, it omits behavioral details like whether the LUT change is persistent, what happens with invalid LUT names, or how it interacts with view_node or load_profile, which could matter in a complex compositing 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 100%, so the schema already fully documents the 'lut' parameter. Description repeats the schema exactly with no additional semantics (e.g., case sensitivity, default value behavior, valid values beyond examples). Baseline 3 when schema does the heavy lifting.

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 (switch) and resource (viewer's display LUT/colorspace). Clear what it does, though it doesn't distinguish itself from sibling tools like set_knob or get_knob which could also affect viewer settings.

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

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

No explicit when-to-use or when-not-to-use guidance, no alternatives named. The purpose is clear enough that usage is implied (use to change viewer LUT), but the description doesn't help an agent choose between this and other viewer/knob 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?

The only annotation is destructiveHint=false, and the description adds no behavioral context beyond it: it does not say whether the node is added to the current comp, whether existing connections are affected, or what the result looks like. Since the annotation bar is low, a modest score is warranted, but for a graph-mutating creation tool this is 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?

The lead sentence is well front-loaded, but the 'Args' block duplicates schema content word-for-word rather than adding meaning, so a chunk of the text does not earn its place.

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

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

With full schema coverage and no output schema, the description covers the minimum an agent needs to call the tool. It omits any comp/graph preconditions and any effect on existing node connections, which is a real gap for a node-creation tool, but not fatal.

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 100%, so the baseline is 3 and the parameter schema already documents input_node, from_layer, and to_layer with their default. The description merely restates those same definitions verbatim, adding no syntax, format, or constraint detail the schema lacks.

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

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

The description states a specific verb and resource — 'Create a Shuffle node to move channels between layers' — which lets an agent distinguish it from generic node tools like create_node or connect_nodes. It stops short of naming an explicit sibling alternative, so it is clear but not fully differentiated.

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

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

There is no guidance on when to use this tool versus alternatives such as create_node, connect_nodes, or setup_merge, and no statement of prerequisites (e.g. that a comp/node graph context must exist). The example layer names hint at the domain but not at selection criteria.

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?

Adds behavioral context the annotations do not carry: snapshots live server-side, are capped at 5, and the call returns a snapshot_id. It does not explain eviction behavior once the cap is hit. Note the mild tension with readOnlyHint=true, since storing a snapshot writes server-side state, though the description does disclose that write explicitly rather than hiding it.

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 sentences, zero filler, and the core action is front-loaded ahead of the storage caveat and the timing advice. Every sentence earns its place.

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

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

For a zero-parameter, no-output-schema tool, the description covers the essential contract: what is captured, what comes back, where it is stored, and when to call it. Only the over-limit behavior and the scope (comp vs project) of the snapshot are left 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 schema has zero parameters, so there is no parameter semantics to document and the baseline is 4. The description correctly uses its space to describe the return value instead of inventing 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?

States a specific verb+resource ('Take a snapshot of the current comp state') and immediately distinguishes itself from its closest sibling by naming diff_comp as the consumer of the returned snapshot_id. An agent can tell snapshot_comp apart from diff_comp, scene_digest, and scene_delta without opening any schema.

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

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

Gives explicit timing guidance ('Use before making changes') and routes the agent forward to diff_comp for comparison. It lacks an explicit 'when not to use' clause (e.g. no need if you are only reading), so it is clear context rather than full alternative routing.

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

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

Goes well beyond the destructiveHint annotation by disclosing the mechanism: it sets state="cancelled" on the disk record AND signals the addon-side worker to stop between frames, and cancelling a terminal task is a no-op that returns existing state. This is exactly the operational context an agent needs before a destructive call.

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 purpose in one short sentence, then adds only the two behavioral facts that matter. No filler and no redundancy.

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

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

For a one-parameter destructive tool with no output schema, the description covers the action, side effects on disk and worker, and the no-op/return behavior on terminal tasks. Nothing material is missing.

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

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

Schema coverage is 100% for the single id parameter, which the schema already documents as a 16-hex-char task id. The description adds no format or sourcing detail beyond the schema, so the baseline 3 applies.

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 (cancel) and resource (in-flight task), and the verb immediately separates it from siblings like tasks_resume, tasks_list, and tasks_get. An agent can identify what this does without opening the schema.

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

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

The opening 'Cancel an in-flight task' establishes the operating context, and the no-op note clarifies behavior for already-terminal tasks. It stops short of naming the inverse sibling (tasks_resume) as the alternative, so routing is clear but not fully explicit.

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

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

Annotations cover read-only safety, but the description adds no behavioral context beyond the basic fetch action. Error handling is described only in the parameter schema, not the tool description.

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 waste. It is appropriately sized for a simple get-by-id tool.

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

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

Given the low complexity, rich schema coverage, and read-only annotation, the definition is nearly complete. The description omits return shape, but no output schema exists and the operation is straightforward.

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 100%, so the baseline is 3. The description's 'by id' adds no information beyond what the schema already provides for the single parameter.

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

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

States a specific verb+resource ('Fetch a single task') and scope ('by id'), which implicitly distinguishes it from tasks_list. No explicit sibling naming, but the purpose 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?

Provides no guidance on when to use this tool versus alternatives such as tasks_list, nor any conditions or prerequisites. The id provenance is only in the schema, not the description.

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

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

Annotations declare readOnlyHint=true, so safety is covered. The description adds ordering (newest first), which is useful. But it omits pagination, whether it returns only recent/incomplete tasks, and what 'recent' means – notable gaps for a list 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 compact sentence with the ordering constraint front-loaded. 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?

For a simple list tool with one fully-described parameter and a readOnly annotation, this is minimally adequate. However, it lacks guidance on result size, pagination, and how it relates to tasks_get, leaving the agent to fill 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 coverage is 100%, so the single limit parameter is fully documented in the schema, including the rationale for capping. The description adds no parameter detail beyond what the schema provides. Baseline 3 applies.

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 resource (tasks) with ordering detail (newest first). It doesn't explicitly distinguish from tasks_get or tasks_cancel, but the plural 'tasks' and 'List' make the shape clear enough.

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

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

No when-to-use guidance, no mention of alternatives like tasks_get for a single task, and no exclusion conditions. The agent has to infer from the name alone.

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

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

readOnlyHint=true already covers the safety profile, but the description adds the crucial behavioral fact that this is a stub returning a status purely so clients can probe capability without crashing. That is exactly the kind of non-obvious caveat annotations cannot express; it does not, however, cover error behavior or return shape beyond the stub.

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 core sentence is front-loaded and earns its place, and the caveat is essential information. However, the internal developer references ('TODO(B2c)', 'commit 4', 'a future commit') are engineering-notebook noise that the agent does not need and slightly dilute the message.

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 one-parameter, no-output-schema tool whose annotations already signal read-only, the description supplies the decisive context an agent needs: that the operation is currently a no-op probe. Nothing essential is missing, though it could briefly state what the stub status return looks like.

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 100% (the 'id' field is documented as a 16-hex-char task id), so the schema carries parameter semantics. The description adds nothing further about the id, so the baseline 3 applies.

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 ('Resume a task') and adds the precondition ('that's awaiting input'), which cleanly separates it from tasks_get, tasks_cancel, and tasks_list. It also discloses that the tool is currently a non-functional stub, so an agent understands both the intent and the present reality.

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

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

Explicitly gives the triggering condition (task parked in 'input_required') and, unusually, the when-not: every Task currently succeeds or fails synchronously, so 'resume has nothing to drive.' It stops short of naming sibling alternatives, but the applicability is otherwise unambiguous.

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

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

With only destructiveHint=false in annotations, the description carries most of the disclosure burden and delivers: it explains the side effect (disabling all tools in the profile) and the core-locked constraint with its rationale. It does not state reversibility or whether the profile config is deleted, which is the main remaining 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?

Front-loaded with the core action, followed by a useful caveat; the Args restatement of the single param is redundant but small. Overall tight and well-ordered.

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 covers the action, the excluded case, and the rationale. For a one-parameter mutation tool it is nearly complete, though reversibility/return behavior is left 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 100% with a single parameter, so the schema already documents 'name'. The description's Args block merely repeats 'profile name to disable', adding no format or constraint detail beyond the schema.

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

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

States a specific verb (disable) and resource (every tool in a named profile), so the agent knows exactly what the tool does. It does not explicitly contrast with load_profile/list_profiles siblings, but the semantics are 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?

Provides a clear when-not rule: 'core' is locked on and cannot be unloaded because it would strip read paths and load_profile. It doesn't name an explicit alternative, but the exclusion plus the inverse sibling make the usage context clear.

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

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

The annotations only declare destructiveHint=false, so the description carries most of the behavioral burden. It does disclose that the tool mutates viewer state rather than returning data, which is useful, but says nothing about persistence, whether other viewers are affected, or side effects on the current viewer input.

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 core sentence is front-loaded and wastes no words. The trailing Args section duplicates the schema's parameter description, which is minor redundancy but not harmful.

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 one-parameter tool with no output schema and no nested objects, the description covers what the tool does and what it operates on. Missing only the behavioral details (viewer scope, side effects) that the sparse annotations do not supply.

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 100% and there is a single required parameter, so the schema already documents it fully. The description's Args block simply restates the schema text ('name of the node to view') without adding format, naming-convention, or resolution details.

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

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

The description states a specific verb and effect ('Set the viewer to display a specific node's output'), naming both the resource (node) and the resulting state change, so an agent can distinguish it from read-only siblings like read_node_detail. It stops short of explicitly contrasting 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?

Usage is implied by the verb phrase: call this when you want a node's output shown in the viewer. There is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as read_node_detail or snapshot_comp.

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