Skip to main content
Glama

set_static_mesh_nanite

DestructiveIdempotent

Configure Nanite for a UStaticMesh asset: enable or disable it, set the kept triangle percentage, rebuild the mesh, and save the changes.

Instructions

Set the Nanite settings of a UStaticMesh asset through the StaticMeshEditor subsystem, which rebuilds the mesh, then save it; a failed save is an error. Both fields are always written: omitting enabled disables Nanite and omitting keep_percent_triangles resets it to 1.0. Returns nanite_enabled read back.

Returns: { static_mesh_path, nanite_enabled, saved }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
enabledNotrue enables Nanite, false disables it; default false, so leaving it out disables Nanite.
static_mesh_pathYesContent path to the UStaticMesh asset.
keep_percent_trianglesNoFraction of the source triangles Nanite keeps, 1.0 keeps them all (default 1.0, written even when omitted).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.2.0
    • changedInput schema / properties / enabled / description
      Previous value: -"Whether to enable Nanite."New value: +"true enables Nanite, false disables it; default false, so leaving it out disables Nanite."
    • changedInput schema / properties / keep_percent_triangles / description
      Previous value: -"Fraction of triangles to keep (defaults to 1.0)"New value: +"Fraction of the source triangles Nanite keeps, 1.0 keeps them all (default 1.0, written even when omitted)."
  2. First observedv1.1.0

TDQS

A4.1/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing that the operation rebuilds the mesh, then saves, and that a failed save is an error. It also warns that both fields are always written, so omitting enabled disables Nanite and omitting keep_percent_triangles resets to 1.0 — critical destructive side effects for a tool flagged destructiveHint=true.

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 operation and subsystem, then the critical write semantics, in two tight sentences. The 'Returns nanite_enabled read back' and trailing 'Returns: { ... }' line are slightly redundant, costing a point.

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

Completeness4/5

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

For a destructive mutation with no output schema, the description covers the rebuild/save pipeline, error condition, forced-write semantics, and return shape, which is enough for correct invocation. Missing explicit guidance on save/permission prerequisites keeps it short of complete.

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 both field descriptions already document the defaults and 'written even when omitted' behavior, so the description largely repeats the schema. It reinforces the write-always semantics but adds no syntax or format detail beyond what the schema provides.

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 ('Set the Nanite settings of a UStaticMesh asset') and names the exact subsystem responsible for the write. It is unambiguous against the many sibling set_static_mesh_* tools, since Nanite is a distinct asset setting.

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

Usage Guidelines3/5

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

No explicit statement of when to prefer this over alternatives like set_static_mesh_properties, nor prerequisites. Usage is only implied via the note that omitting fields has side effects. Nothing routes the agent between this and sibling mesh-setting tools.

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