create_ai_controller

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

No annotations are provided, so the description carries the full behavioral transparency burden. It does disclose that the AIController possesses an AI Pawn and runs its Behavior Tree, which is useful. However, it omits important behavioral details such as whether the blueprint asset is compiled/saved, what happens when the behavior_tree asset does not exist, side effects of auto_run_bt=false, and whether creating with an existing name overwrites anything. The description only covers high-level intent, not operationally relevant behavior.

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 front-loaded: summary sentence, one behavior line, Args block, KB reference, and example. Nothing is wasted, and the example shows a minimal valid invocation. The structure is easy to scan and helps an agent parse the essential contract quickly.

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 creation tool with an output schema and a KB pointer, the description covers the basic invocation contract: purpose, parameters, and an example. However, given the lack of annotations and the crowded sibling landscape, it is missing contextual details like prerequisites (e.g., the behavior tree asset must already exist), the relationship to set_blueprint_ai_controller, and any side effects such as asset persistence or compilation. It is adequate but not fully complete.

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 supply parameter meaning, and it does. Each parameter gets a plain-language definition: name has an inline example, behavior_tree is described as the asset to run automatically, and auto_run_bt is defined as running the tree on possession. This goes beyond the bare schema titles and defaults, though it could further clarify optionality and prerequisite asset existence.

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 opens with a concrete verb and resource: 'Create an AIController Blueprint.' It also explains the core role of the controller (possessing an AI Pawn and running its Behavior Tree), which clarifies the tool's function. It does not explicitly differentiate from siblings like set_blueprint_ai_controller or create_full_enemy_ai, but the verb and resource are specific enough to avoid major confusion.

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 explains what the tool does but gives no guidance on when to choose it over alternatives. Sibling tools such as set_blueprint_ai_controller, create_behavior_tree, create_full_enemy_ai, and build_behavior_tree all touch related workflows, yet no conditions, exclusions, or alternative recommendations are provided. The KB pointer is a reference, not actionable selection guidance.

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