Skip to main content
Glama

get_mesh_selection_bounds

Read-onlyIdempotent

Resolve a mesh region and report its local-space bounding box, returning center and size in centimeters to measure selected geometry without opening the editor.

Instructions

Resolve a region into a selection and report its local-space BOUNDING BOX via UGeometryScriptLibrary_MeshSelectionQueryFunctions::GetMeshSelectionBoundingBox. Read-only. Takes exactly the same region parameters as select_mesh_triangles and set_mesh_material_id_in_region, so a region measured here is the same one painted there. This is what turns a bisection answer ("the piece is somewhere in X>0") into actual numbers: centre and size, which is what lets you tell a 150x100x40 slab from a 14x230x75 rail without opening the editor.

Returns: { actor_name, region, triangles_selected: int, is_empty: bool, bounds: { min_x, min_y, min_z, max_x, max_y, max_z, center_x, center_y, center_z, size_x, size_y, size_z } }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
centerNoLocal [x,y,z] centre. Used by box/sphere, and as the plane origin.
extentNoLocal [x,y,z] HALF-size in cm. Required by region='box'.
invertNoInvert the spatial selection (default false).
normalNo[x,y,z] direction. Plane normal for region='plane', facing direction for 'normal_angle'. Default [0,0,1].
radiusNoRadius in cm. Required by region='sphere'.
regionNo'all' (default) | 'box' | 'sphere' | 'plane' | 'normal_angle' | 'material_id' | 'polygroup' | 'connected_component'.
actor_nameYesLabel or name of the target DynamicMeshActor.
polygroup_idNoPolygroup to select when region='polygroup'.
max_angle_degNoMax angle from normal in degrees for region='normal_angle' (default 15).
component_indexNoIsland index when region='connected_component'. Get it from get_mesh_components_detail, which reports each piece's size and bounding box.
polygroup_layerNoOptional extended polygroup layer index for region='polygroup'.
source_material_idNoMaterialID to select when region='material_id'.
min_triangle_pointsNoHow many of a triangle's 3 points must be inside for it to count, 1-3 (default 3).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already carry readOnly/idempotent/non-destructive, but the description adds the important qualifier that bounds are local-space (not world), plus the return shape and the cross-tool consistency guarantee. Since no output schema exists, the explicit Returns block is real added value beyond the annotations.

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 purpose and mechanics, then the return structure; sentences are information-dense. The slab/rail illustration is slightly rhetorical but does clarify the value proposition, so it earns its place, leaving a 4 rather than a 5.

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 13-parameter query tool with no output schema, the description supplies everything needed: purpose, usage context, sibling consistency, read-only nature, and the full return shape including bounds fields. Nothing an agent needs to call it correctly is missing.

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%, so every parameter is already documented with enums and defaults. The description's only parameter-relevant addition is that the region params match select_mesh_triangles, which helps but doesn't add syntax or format meaning. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Resolve a region into a selection and report its local-space BOUNDING BOX') and names the underlying function. It distinguishes itself from siblings by explicitly linking to select_mesh_triangles and set_mesh_material_id_in_region, so an agent knows this reads bounds rather than selecting or painting.

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?

Gives clear context for when to reach for it — converting a bisection answer into concrete numbers to distinguish a slab from a rail — and calls out the parameter-sharing contract with the sibling region tools. It stops short of an explicit 'when not to use' or exclusion, so a 4 rather than 5.

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