Skip to main content
Glama

spawn_box_volume

Spawn AVolume-derived actors with a real cube brush sized from half-extents, then normalize scale and verify world bounds so the volume encloses space as requested.

Instructions

USE THIS, NOT the plain actor spawners, for ANY AVolume-derived actor: it spawns the actor AND builds a real cube brush for it from a half-extent, so the volume actually encloses space. The generic spawners leave an EMPTY UModel brush -- zero bounds, which means 0 nav tiles and no overlap, an actor that looks spawned and does nothing. It then normalizes the residual scale some actor factories stamp on placement and RE-READS the resulting world bounds, so success means "the volume you got matches the volume you asked for", not "the call returned".

Returns: { actor_name, actor_path, actor_class, volume_class, world_bounds_extent: [x,y,z] (RE-READ, GetActorBounds -- kept for compatibility), bounds_extent_actual: [x,y,z] (RE-READ from the BRUSH component's world bounds; this is the volume itself, with no stray editor sprite in the box), bounds_origin_actual: [x,y,z], actor_scale: [x,y,z] (RE-READ, after normalization), spawn_scale: [x,y,z] (RE-READ, as the actor factory left it), scale_normalized: bool (true only when a correction was actually needed), extent_matches_request: bool, bounds_tolerance_uu: number, has_brush_geometry, brush_built, is_spatially_loaded (RE-READ), spatial_flag_applied, success, requested: { volume_class, location, extent, actor_label, is_spatially_loaded, normalize_scale } }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
extentNoRequired [x, y, z] in unreal units, each component > 0. !!! THIS IS THE SEMI-AXIS (HALF-size), NOT the full edge length !!! extent=[500,500,200] builds a 1000 x 1000 x 400 cube and, with the scale normalized, gives world bounds of +/-500 / +/-200 around `location`. Check `bounds_extent_actual` against what you asked for.
locationNoWorld [x, y, z] location to spawn the volume (default 0,0,0)
actor_labelNoOptional editor label for the spawned actor
volume_classYesVolume class: short reflected name ('NavMeshBoundsVolume', 'PhysicsVolume', 'TriggerVolume', 'BlockingVolume', 'PCGVolume', with or without a leading 'A') or a full object path ('/Script/Engine.TriggerVolume'). Must derive from AVolume (required).
normalize_scaleNoDefault TRUE: resets the actor scale to (1,1,1) after building the brush, so the world bounds equal the requested `extent`. It matters because some actor factories stamp a default scale during placement -- APCGVolume is spawned at (25, 25, 10) -- and since brush polys are authored in LOCAL space that scale MULTIPLIES your extent. Set it false only if you deliberately want the factory's scale; `spawn_scale` always reports what it was. Be aware that with normalize_scale=false and a factory scale != 1 the real bounds are NOT the requested extent, so `extent_matches_request` and therefore `success` come back FALSE -- that is the honest answer, not a bug, and `actor_scale` says why they differ.
is_spatially_loadedNoWorld Partition spatial-loading flag (default true; only applied when the actor allows changing it). Reported RE-READ from the actor.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnly=false, destructive=false): it discloses the brush-building step, residual-scale normalization, the PCGVolume factory scale trap, the re-read of world bounds, and the non-obvious meaning of `success` ('the volume you got matches the volume you asked for'). It also explains when success legitimately returns false, which prevents misreading an expected outcome as a bug.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the differentiator in the first clause and the Returns block is justified because no output schema exists. It is dense and run-on, with heavy ALL-CAPS and parenthetical asides, so it is efficient in intent but heavier than necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema, the description documents the returned fields, the success criterion, and the tolerance behavior, and warns about the factory-scale pitfall. An agent has everything needed to call it and interpret the result correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema descriptions already carry the critical half-extent warning, the normalize_scale rationale, and the spatial-loading flag, so the baseline is 3. The description reinforces 'half-extent' but adds no syntax or semantics the schema lacks, and it labels `extent` as 'Required' while the schema's required list contains only volume_class.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('spawns the actor AND builds a real cube brush for it from a half-extent') and immediately contrasts with 'the plain actor spawners'. An agent can tell it apart and knows exactly what artifact it produces (a volume that actually encloses space).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing: 'USE THIS, NOT the plain actor spawners, for ANY AVolume-derived actor', with the failure mode of the alternative spelled out (empty UModel, zero bounds, 0 nav tiles). It does not name precise sibling tools such as spawn_navmesh_bounds_volume or spawn_pcg_volume, which an agent might otherwise consider for the same volume classes, so the exclusion is directional rather than exhaustive.

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

Deploy Server

Other Tools