Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

scale_mesh_uvs

Destructive

Scale U and V coordinates of a mesh's UV channel on a DynamicMeshActor in the editor, centered on an optional origin. Non-zero factors required; returns updated scale info.

Instructions

Scale all UVs of one channel on a DynamicMeshActor's live dynamic mesh in the editor world by separate U and V factors; zero factors are refused and 1, 1 changes nothing (scaled false). No undo entry; reply actor_name is the component name, not the actor label.

Returns: { actor_name: string, uv_channel: int, scale_u: number, scale_v: number, scale_origin: { u, v }, scaled: bool }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scale_uYesScale factor along U; must be non-zero (1 keeps U unchanged).
scale_vYesScale factor along V; must be non-zero (1 keeps V unchanged).
actor_nameYesLabel or object name (case-insensitive) of the target DynamicMeshActor in the editor world.
uv_channelYes0-based UV channel index; a channel the mesh does not have fails the call.
scale_origin_uNoU coordinate of the point the scaling is centred on (default 0).
scale_origin_vNoV coordinate of the point the scaling is centred on (default 0).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.2.0
    • changedInput schema / properties / actor_name / description
      Previous value: -"DynamicMeshActor name (required)"New value: +"Label or object name (case-insensitive) of the target DynamicMeshActor in the editor world."
    • changedInput schema / properties / scale_origin_u / description
      Previous value: -"Optional U scale origin (default 0)"New value: +"U coordinate of the point the scaling is centred on (default 0)."
    • changedInput schema / properties / scale_origin_v / description
      Previous value: -"Optional V scale origin (default 0)"New value: +"V coordinate of the point the scaling is centred on (default 0)."
    • changedInput schema / properties / scale_u / description
      Previous value: -"U scale (required, non-zero)"New value: +"Scale factor along U; must be non-zero (1 keeps U unchanged)."
    • changedInput schema / properties / scale_v / description
      Previous value: -"V scale (required, non-zero)"New value: +"Scale factor along V; must be non-zero (1 keeps V unchanged)."
    • changedInput schema / properties / uv_channel / description
      Previous value: -"UV channel index (required)"New value: +"0-based UV channel index; a channel the mesh does not have fails the call."
  2. First observedv1.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Beyond destructiveHint=true/readOnlyHint=false, the description discloses valuable traits: there is no undo entry, zero factors are refused, a 1,1 scale returns scaled=false, and returned actor_name is the component name rather than the actor label. These are real failure-mode and semantics disclosures the annotations cannot carry.

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, followed by constraints and a clearly labeled Returns block. Dense but every clause carries information; the return-object restatement is mildly redundant but useful given there is no output schema.

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?

With no output schema, the description appropriately spells out the return shape and the mutation caveats (no undo, refusal conditions, actor_name meaning). Complete enough for an agent to invoke it safely, though a note on required mesh/mesh-editing context is absent.

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 the parameters are already documented, establishing a baseline of 3. The description adds the meaningful nuance that the reply's actor_name is the component name rather than the actor label, clarifying an ambiguity the schema's 'label or object name' wording leaves open.

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 specific verb (scale), resource (mesh UVs), scope (one channel on a DynamicMeshActor's live dynamic mesh in the editor world), and parameterization (separate U and V factors). This clearly separates it from siblings like rotate_mesh_uvs, translate_mesh_uvs, and scale_dynamic_mesh (which scales the whole mesh rather than UVs).

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?

It states useful operating conditions (zero factors are refused, 1,1 is a no-op) but never says when to reach for this tool versus the other UV-transforming siblings (rotate/translate/repack_mesh_uvs) or what prerequisite state the mesh must be in. Usage is implied rather than explicit.

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