add_set_vector_parameter_value_node

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool adds a node and changes a material color at runtime, referencing a KB chapter for more depth. However, it omits side effects such as modifying the blueprint graph, requiring an existing dynamic material variable, or needing a subsequent compile.

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

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

The description is well organized: a front-loaded purpose statement, a useful analogy, a complete args list, a KB pointer, and an example. It is a bit longer than needed, and the example's inconsistency adds confusion, but each section earns its place and supports correct usage.

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

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

The description covers the main purpose, all parameter meanings, and an example. Missing context includes which parameters are optional versus required (schema says only 3 are required), prerequisites such as an existing Dynamic Material Instance variable, and post-conditions like compilation. Given the 0% schema coverage and no annotations, these gaps are noticeable.

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

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

Schema description coverage is 0%, so the description must compensate. It defines all five parameters with their meanings and formats (RGBA, [X,Y] position), which is strong compensation. However, the example passes an asset path for dynamic_material_variable while the arg description says 'Variable name holding the Dynamic Material Instance,' creating a confusing inconsistency.

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

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

The description clearly states the action: 'Add a SetVectorParameterValue node to change a material color at runtime.' This is specific about the verb, resource, and purpose. It does not explicitly differentiate from the sibling add_set_scalar_parameter_value_node, but the focus on color and RGBA makes the vector nature apparent.

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

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

The description gives clear context: 'This is the runtime equivalent of double-clicking the VectorParameter node in the Material Editor' and 'Use this to dynamically change an actor's color.' It does not mention exclusions or alternative tools, but the intended usage is clear enough for an agent to decide when to invoke it.

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