set_collision_settings

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

With no annotations present, the description carries the behavior burden and mostly succeeds: it explains that this mutates collision and visibility, enumerates valid collision presets, and clarifies that hidden_in_game hides the component during gameplay. It does not discuss persistence, compile requirements, or error cases, but the core effect on the Blueprint component is well disclosed.

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-structured with intro, context, preset list, args, KB pointer, and example. It is slightly padded with source-chapter context that an agent may not need, but the structure and front-loading are effective and not wasteful.

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 5 parameters, zero schema descriptions, and no annotations, the description is remarkably complete: it covers all args, provides valid preset values, and includes a concrete invocation example. It could be even more complete with side-effects like whether the Blueprint needs recompilation, but nothing essential for selecting or invoking the tool is missing.

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 fully compensates. Every argument has at least a defining phrase, and collision_preset is backed by an explicit list of valid values. The example also demonstrates the expected blueprint_name format with a full asset path.

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 verb and resource: 'Set collision and visibility settings on a Blueprint component.' It further narrows the intent with 'configure CapsuleComponent collision' and 'hide components in-game', making it easy to distinguish from generic component-property setters or graph-node tools.

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 usage context by tying the tool to Ch. 9 AI setup and explicitly noting it configures CapsuleComponent collision and in-game visibility. It does not list exclusions or name alternative tools like set_component_property or add_set_collision_profile_node, but the context is clear.

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