add_actor_world_rotation_node

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the core semantic behavior (the node additively applies DeltaRotation to current rotation) and gives a concrete example. It does not disclose operational traits such as whether the blueprint is mutated in place, whether compilation is triggered, or failure behavior for a nonexistent blueprint path.

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-organized into summary, args, KB pointer, and example, with the core action front-loaded. The Ch.14 line slightly repeats the first sentence's DeltaRotation point, but the overall structure 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 simple 2-parameter node-adder with an output schema present, the description covers the essentials: what node is added, the parameters, and a working example. It leaves gaps around error conditions, whether the node's DeltaRotation input requires downstream wiring, and why a CHAOS-physics KB chapter is referenced for a generic rotation node.

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, and it does: both parameters are explained (blueprint_name as 'Blueprint name', node_position as 'Optional [X, Y] graph position'). The example clarifies that blueprint_name expects an asset path like '/Game/MCP_Test/BP_Example', which the bare schema does not convey.

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 action ('Add an 'Add Actor World Rotation' node') and the node's function ('rotates actor by DeltaRotation'), grounding the verb and resource clearly. It does not explicitly name sibling alternatives like add_set_actor_rotation_node or add_get_actor_rotation_node, but the additive-rotation semantics distinguish it from 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 context is implied rather than stated: 'AddActorWorldRotation adds the Delta Rotation to the current rotation' tells an agent this is for relative rotations, not absolute ones. However, with a huge family of rotation/transform node-adders among siblings, there is no explicit when-to-use versus alternative guidance or exclusion criteria.

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