rerun_construction_scripts

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

Annotations declare destructiveHint=true and idempotentHint=false, and the description reinforces this with concrete detail: it destroys every generated component and rebuilds it, and states that this is the only route to the engine API function. It also reports before/after component sets with destroyed/created component names, far exceeding what the annotations convey.

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?

Front-loads the core action and effect, then the uniqueness constraint, then the use cases. The long returns enumeration is justified because no output schema exists, though the block is dense and could be trimmed slightly.

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?

With no output schema, the description supplies the full return shape (actor resolution, before/after component counts and names, verification checks, world/net_mode/PIE fields), plus the destructive semantics and the reason the tool exists. An agent has everything needed to invoke and interpret it.

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 100%, so the schema already documents both parameters thoroughly, including the world selector's editor/'server'/'client'/'pie:N' semantics. The description adds no additional parameter-level detail, so the baseline 3 is appropriate.

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?

States a specific verb and resource (runs AActor::RerunConstructionScripts on a level actor) and precisely describes the effect: destroying every construction-script-generated component and rebuilding it, like dragging the actor in the editor. No sibling tool performs this operation, and the description makes that uniqueness explicit by noting reflection, call_function and execute_python cannot reach it.

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?

Gives explicit use cases ('find out what a property edit really survives', 're-apply a Blueprint's construction logic after editing the instance') and explicitly names the alternatives that cannot do this (reflection, call_function, execute_python). The world parameter's editor-vs-PIE targeting is also called out, so the agent knows when each mode applies.

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