add_create_widget_node

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

With no annotations, the description carries full transparency responsibility. It discloses the node's runtime behavior and the empty-owning-player fallback, but it doesn't state whether the blueprint is saved or compiled, whether existing graph connections are affected, or whether the node is left disconnected until the user wires it. This is a moderate gap for a graph-mutating 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 description is well organized: a leading summary sentence, a context block, a clear args list, a KB reference, and an example. There is minor redundancy between 'instantiate a Widget Blueprint at runtime' and 'Creates a widget instance,' but overall it is efficient and front-loaded.

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 all parameters and points to KB documentation, which is helpful, but it omits expected formats for widget_class, whether the node is auto-connected to execution, and whether the blueprint needs to be compiled afterward. The presence of an output schema softens the missing-return-value concern, but the mutation side effects remain underspecified.

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 provides a meaningful one-line explanation for all five arguments, including the important empty = Get Player Controller behavior for owning_player_variable, and includes an example with a full asset path. This goes well beyond the bare schema titles.

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 starts with a specific action and object: 'Add a CreateWidget node to instantiate a Widget Blueprint at runtime.' This clearly distinguishes it from sibling UMG tools like add_widget_to_viewport (direct viewport operation) and create_umg_widget_blueprint (asset creation), as it specifically targets adding a graph node.

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

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

The description gives contextual signals like references to chapters and 'Creates a widget instance and optionally adds it to the viewport,' but it never explicitly states when to use this tool versus alternative node-adding or widget tools. An agent must infer that this is for blueprint graph node insertion rather than direct widget manipulation.

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