spatial_plan_asset_scale_corrections

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

With no annotations, the description carries the full burden and handles it well: it states the tool is local/read-only, returns a dry-run composition plan, and does not mutate the Unreal Editor scene. It also specifies the planner's behavior ('compares... recommends... returns') rather than hiding side effects.

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 with the core purpose, followed by a KB pointer and a concrete invocation example. Every sentence contributes meaningful behavioral or usage information, with minimal redundancy.

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 the primary required parameter and the read-only behavior, the description is complete, and an output schema exists to document return values. However, an 8-parameter tool with zero schema descriptions still leaves the optional tuning knobs unexplained, and the description does not position this tool against sibling planners/apply tools. An agent can call the basic path but not confidently customize advanced behavior.

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%, yet the description only elaborates on composition_plan_json via its example. The remaining seven parameters are left entirely to their titles/defaults; the description does not explain acceptable values, relationships, or when to change min_scale, max_scale, anisotropy_tolerance, close_scale_tolerance, include_updated_plan, limit, or allow_non_uniform_scale.

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 specific verb and resource ('Plan scale corrections for generated or bound spatial assets') and expands with a precise workflow: comparing planned prop dimensions to imported mesh bounds, recommending reviewed scale updates, and returning a dry-run plan. It also distinguishes itself from mutating siblings by explicitly labeling itself a local/read-only planner. This is enough for an agent to separate it from nearby spatial_plan_* 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 names the relevant input contexts ('generated-asset binding output, interior composition, or screenshot reconstruction') and makes clear this is the planning step, not the apply step. It does not explicitly name an alternative tool or a when-not-to-use condition, but a clear usage context is present.

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