Skip to main content
Glama

get_mesh_components_detail

Read-onlyIdempotent

Enumerate connected components in a DynamicMeshActor's live mesh to get each island's triangle count, bounds, triangle ID range, and material IDs before painting or editing.

Instructions

Enumerate the connected components (physical pieces) of a DynamicMeshActor's live dynamic mesh via UE::Geometry::FMeshConnectedComponents, reporting for EACH island its triangle count, its local-space bounding box, its triangle_id range and which MaterialIDs it carries. Read-only (unlike the engine's SplitMeshByComponents, which consumes the mesh). This is the map of a mesh in ONE call, and the tool to reach for BEFORE painting anything: get_mesh_material_ids says how many triangles carry each material, and this says what those triangles physically ARE. HONEST GATE: it names nothing — it gives you sizes and positions, and which island is which part is still a human call; what it prevents is deriving that from a triangle-count assumption.

Returns: { actor_name, component_count: int, components_truncated: bool, components: [ { index, triangle_count, id_min, id_max, id_contiguous: bool, material_ids: [int], 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 }, triangle_ids: [int] } ] }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actor_nameYesLabel or name of the target DynamicMeshActor.
max_componentsNoCap on how many islands to return (default 64). components_truncated says whether the cap cut the list; component_count is always the real total.
include_triangle_idsNoAlso return each island's full triangle ID list (default false; use the reported id_min/id_max range instead unless the island is non-contiguous).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint, so the safety profile is covered, but the description adds genuine behavioral context: it contrasts with the destructive SplitMeshByComponents and discloses an 'HONEST GATE' limitation (it names nothing; island identity remains a human call). That limitation disclosure is unusually valuable, though it doesn't cover pagination/truncation behavior in prose.

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-loaded with the core purpose and a full return shape, and every section is relevant. The 'HONEST GATE' paragraph is somewhat verbose and could be tightened, keeping it short of 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 3-param read tool with no output schema, the description supplies the return structure inline (component_count, components_truncated, per-island fields) plus usage context and limitations, so 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 description coverage is 100%, so the schema already fully documents actor_name, max_components, and include_triangle_ids. The description adds marginal semantic value here, only implying the truncation/range semantics that the schema itself already states, so the baseline of 3 applies.

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 (enumerate) and resource (connected components / physical pieces of a DynamicMeshActor's dynamic mesh) and even names the underlying implementation. It explicitly distinguishes itself from SplitMeshByComponents and describes its relationship to get_mesh_material_ids, so an agent can tell it apart from siblings without opening a schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use guidance ('the tool to reach for BEFORE painting anything') and names the alternative (get_mesh_material_ids) with the distinct question each answers. It also clarifies a distinction from SplitMeshByComponents (read-only vs consuming the mesh).

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