Skip to main content
Glama

batch_set_actor_transform

DestructiveIdempotent

Batch-update many Unreal Engine actors' location, rotation, or scale in one undoable transaction, avoiding repeated transform calls, with success and failure counts for unresolved names.

Instructions

Move/rotate/scale MANY actors in a single undoable transaction, each with its own optional location/rotation/scale, reporting success_count, failure_count and the names that did not resolve. Cheaper and atomically undoable versus N set_actor_transform calls. Calls Modify() per actor so their OFPA packages dirty and save_level actually writes them. Takes the same world selector as set_actor_transform, so it reaches a live PIE world too. WARNING: resolves the INTERNAL name only (no editor labels, unlike set_actor_transform); a name it cannot find is counted in failure_count, not raised as an error -- read that number.

Returns: { success_count: int, failure_count: int (unresolved or malformed entries -- check it), updated_actors: [actor JSON re-read after the write], failed_actors?: [string], world_name, world_package, ... }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
worldNoOptional: "editor" (default) | "pie" | "server" | "client" | "pie:N". The response stamps which world answered.
actor_transformsYesArray of objects {actor_name: internal GetName; location?: [x,y,z] array only; rotation?: [pitch,yaw,roll] or the safer {pitch,yaw,roll}; scale?: [x,y,z] array only}. Omitted components keep their current value; an entry with no actor_name just increments failure_count, and a malformed vector silently reads as zero.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond annotations: discloses that Modify() is called per actor so OFPA packages dirty and save_level writes them, that only INTERNAL names resolve (no editor labels), and that unresolved names increment failure_count rather than raising. These are exactly the mutation-side effects an agent needs.

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 purpose before constraints and warns the agent clearly. Slightly dense, with return fields repeated in both the body and the 'Returns:' line, but every sentence adds actionable content.

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?

No output schema exists, yet the description enumerates the return shape (success_count, failure_count, updated_actors, failed_actors, world_name, world_package) and stresses reading failure_count. Nothing needed 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.

Parameters4/5

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

Schema coverage is 100% so the schema carries the parameter detail, but the description adds real meaning: the `world` selector behaves identically to set_actor_transform, name resolution is internal-only unlike the singular tool, and malformed vectors silently read as zero. That is beyond what the schema states.

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 set (move/rotate/scale), resource (many actors), and scope (single undoable transaction), and explicitly positions itself against set_actor_transform. An agent can distinguish it from the singular sibling without reading either 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?

Names the alternative ('cheaper and atomically undoable versus N set_actor_transform calls') and the condition selecting this tool over it. It also clarifies the shared `world` selector reaches a live PIE world, giving concrete context for when to use.

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