set_shader_node_param

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

No annotations are provided, so the description carries the full disclosure burden, yet it only states the mutation intent ('Set a parameter'). It omits side effects such as writing to the .tres file, preconditions like valid node index or existing node, and error behavior for invalid param/value combinations.

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

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

The description is a single front-loaded sentence with no filler or repetition of schema content, and the action verb appears first. However, the trailing 'etc.' is slightly vague, and one sentence feels lean for a mutating tool with four parameters, though nothing is wasted.

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

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

For a mutating tool with 4 required parameters, no output schema, and no annotations, the description plus terse schema descriptions is insufficient. The agent lacks guidance on locating node_index (e.g., via read_visual_shader), valid value types per param, and failure outcomes, making confident invocation unlikely.

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 slight value by echoing param examples (constant, expression, operator) and linking them to node types, but it does not clarify the 'value' parameter's expected format or how 'node_index' is resolved, leaving schema entries like 'New value' and 'Node index' unenriched.

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

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

The description uses a specific verb+resource ('Set a parameter on a VisualShader node') and narrows scope with the parenthetical '(constant, expression, operator, etc.)'. It clearly distinguishes itself from structural siblings like add_shader_graph_node, remove_shader_graph_node, and connect_shader_graph_nodes, as well as other set_*_param tools by naming VisualShader as the target.

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/when-not guidance, no mention of prerequisites, and no reference to alternatives. The agent is not told to inspect existing nodes via read_visual_shader, create nodes first via add_shader_graph_node, or consult get_shader_node_defaults for valid values. Usage must be entirely inferred from the tool name and the minimal examples.

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