create_dynamic_material_instance

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

With no annotations, the description carries the behavioral burden. It explains that the tool creates a node in a Blueprint, stores a reference in a named variable, and places it at a graph position. However, it does not disclose prerequisites, failure modes, whether an existing variable is overwritten, or whether the Blueprint must be compiled afterward.

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

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

The description is compact and well-structured: a clear one-line action, a short purpose paragraph, parameter semantics, a KB pointer, and a concrete example. Every section adds value and supports correct invocation without 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?

Given the absence of annotations, the description covers the core purpose, all parameter meanings, and an example. The output schema handles return-value expectations. The main gaps are prerequisites and failure behavior, but these are less critical for a relatively straightforward Blueprint node-creation operation.

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

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

Schema description coverage is 0%, so the description must compensate. The Args block documents all five parameters with meaningful semantics: blueprint_name, component_name, source_material_path, variable_name, and node_position. The example call further clarifies how parameters are expected to be provided.

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 clearly states the action: 'Create a Dynamic Material Instance from a source Material in a Blueprint.' It specifies the resource and operation precisely. It does not explicitly differentiate this tool from sibling material tools like material_create_instance_from_master, but the term 'Dynamic Material Instance' is specific enough to avoid major ambiguity.

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

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

The description provides clear usage context: dynamic instances are for runtime modification of material parameters and are used in HUDs, pickups, and interactive props. It does not name alternative tools or state when not to use this approach, but the context is sufficient for an agent to understand the intended scenario.

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