Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

copy_dynamic_mesh_to_static_mesh

DestructiveIdempotent

Copy a DynamicMeshActor's live dynamic mesh into an existing /Game UStaticMesh LOD, overwriting the target LOD in place so it can be saved as a static asset.

Instructions

Write the live dynamic mesh of a DynamicMeshActor INTO an EXISTING /Game UStaticMesh asset's LOD via UGeometryScriptLibrary_StaticMeshFunctions::CopyMeshToStaticMesh (7-arg V2, bUseSectionMaterials=true; engine-default options). Editor-only (the engine function is WITH_EDITOR-gated and touches GEditor + FlushRenderingCommands). Idempotent: overwrites the target LOD in place, no duplication. HONEST GATES: the target asset must already exist (create it first, e.g. via create_editable_static_mesh) and must NOT live under /Engine/ (the engine refuses to modify built-in engine assets). A lod_index outside 0 to 7 (a static mesh has at most 8 LODs) is an error checked before anything changes; one past the asset's last LOD adds the LODs in between, which the engine sets up to be reduced from an earlier LOD.

Returns: { actor_name, target_static_mesh_path, lod_index, outcome_success: bool, source_triangle_count, material_count: int, replaced_materials: bool, wrote: bool }. NOTE: this marks the target package dirty (transaction) but does NOT save to disk — persistence requires a separate save (e.g. via save_asset).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lod_indexNoOptional target LOD index, 0 to 7 (default 0); a negative index or one of 8 or more is refused.
materialsNoOptional ordered list of UMaterialInterface content paths, one per MaterialID (index 0 = MaterialID 0). Supplying it flips bReplaceMaterials on, so the target asset gets exactly these material slots. WITHOUT this the asset keeps its existing slots and a multi-MaterialID mesh collapses into whatever slots already existed — this is the parameter that makes per-triangle MaterialIDs visible on the saved asset.
actor_nameYesLabel or name of the source DynamicMeshActor.
material_slot_namesNoOptional slot names matching materials 1:1 (default: the engine names them). Ignored when materials is absent.
target_static_mesh_pathYesContent path of an EXISTING /Game UStaticMesh to overwrite.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.2
    • changedInput schema / properties / lod_index / description
      Previous value: -"Optional target LOD index (default 0). Clamped by the engine to [0, MAX_STATIC_MESH_LODS]."New value: +"Optional target LOD index, 0 to 7 (default 0); a negative index or one of 8 or more is refused."
  2. First observedv1.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructive + idempotent, and the description adds substantial context beyond them: editor-only, WITH_EDITOR-gated touching GEditor + FlushRenderingCommands, in-place overwrite (no duplication), and the critical note that it dirties the package but does NOT save to disk (needs save_asset). That last point is exactly the kind of gap annotations don't cover.

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?

Purpose is front-loaded and the caps-emphasized constraints (INTO, EXISTING, HONEST GATES) aid scanning. It is dense and slightly long with the Returns list, but every clause carries 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 supplies the return shape (actor_name, outcome_success, wrote, etc.) and the persistence caveat. An agent has everything needed to invoke and interpret the result.

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% (baseline 3), but the description still adds meaning: it explains lod_index error behavior and that one past the last LOD adds intervening LODs reducible from an earlier LOD. This goes beyond the schema's simple bounds note.

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 (Write/COPY) and resource (live dynamic mesh of a DynamicMeshActor into an existing /Game UStaticMesh LOD), naming the exact engine function used. Clearly distinguishes itself from the reverse-direction sibling copy_static_mesh_to_dynamic_mesh.

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?

Explicit gates: target asset must already exist (create first via create_editable_static_mesh), must NOT be under /Engine/, lod_index bounds are validated before mutation. Names the alternative for creating the target, so when-to-use and prerequisites are both covered.

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