Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

build_mesh_bvh

Read-onlyIdempotent

Checks if a bounding volume hierarchy (BVH) can be built and read back as valid for a DynamicMeshActor's current mesh, without modifying it.

Instructions

Build a BVH (bounding volume hierarchy) for the live dynamic mesh of a DynamicMeshActor in the editor world with BuildBVHForMesh, and read it back with IsBVHValidForMesh. The plugin keeps no BVH between calls: this one is dropped on return, and the spatial-query tools (find_nearest_point_on_mesh, find_nearest_ray_intersection_with_mesh, is_point_inside_mesh) build their own on every call, so they never need this first. It checks that a BVH can be built for the mesh as it is now: built is true when the engine reported no error and the BVH reads back as valid; the call fails otherwise. The mesh is not changed.

Returns: { actor_name, built: bool, b_only_if_invalid: bool, bvh_valid: bool, vertex_count, triangle_count } -- actor_name is the dynamic mesh component's name, not the actor label; b_only_if_invalid echoes the request; the counts are those of the mesh the BVH was built for.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actor_nameYesLabel or name of the target DynamicMeshActor.
b_only_if_invalidNoOptional bool, default true; it has no effect, since no earlier BVH is kept and every call builds a new one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.2
    • changedInput schema / properties / b_only_if_invalid / description
      Previous value: -"Optional bool; defaults to true (skip rebuild if BVH is still valid)."New value: +"Optional bool, default true; it has no effect, since no earlier BVH is kept and every call builds a new one."
  2. First observedv1.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial non-obvious behavior: no BVH is retained between calls, the built BVH is dropped on return, the mesh is not modified, the call fails when the engine errors or the BVH fails to read back, and the exact meaning of 'built' is defined. This is well beyond what 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.

Conciseness4/5

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

The action is front-loaded, and the returns block is parsed field-by-field with the non-obvious semantics called out. It is on the long side and repeats the 'no BVH kept' idea across two sentences, but each sentence still carries useful information.

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?

With no output schema, the description fully discharges the burden: it documents the return fields and their edge cases, states the side-effect profile (mesh unchanged, BVH discarded), and describes failure behavior. Nothing an agent needs to call and interpret it correctly appears to be missing.

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

Parameters4/5

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

Schema coverage is 100% (so baseline 3), and the description goes further: it clarifies that actor_name is the dynamic mesh component's name rather than the actor label, correcting an ambiguity in the schema text, and explains that b_only_if_invalid is a no-op echo since no earlier BVH is kept. That meaningfully exceeds the schema.

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?

The description names a concrete verb and resource ('Build a BVH ... for the live dynamic mesh of a DynamicMeshActor in the editor world') and pins down the underlying engine calls (BuildBVHForMesh / IsBVHValidForMesh). It also names the sibling spatial-query tools that render this one optional, so an agent can distinguish its role without opening any schema.

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?

It gives explicit when-not guidance: the spatial-query tools 'build their own on every call, so they never need this first,' framing this as a validation/check call rather than a prerequisite. It does not address the obvious alternative sibling rebuild_mesh_bvh or when a caller would prefer one over the other, leaving a gap.

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