Skip to main content
Glama

get_actor_properties_by_class

Read-onlyIdempotent

Enumerate actors by class or editor label and read their properties in one call, from the editor or a live world, returning path and typed props per instance.

Instructions

Enumerate ACTORS by CLASS (or by editor label) and read their PROPERTIES in one call, in the editor world or in a live one. Reads the EDITOR world too (world='editor', with no PIE running), not just a live one. Use it instead of an execute_python loop over GetAllActorsOfClass + get_editor_property: it returns { path, props } per instance and stamps the world that answered, which such a loop does not. Filter with class_name (IsA) and/or actor_label, drill into one component, pick which properties to read, and use world='server' vs 'client' to separate an authoritative reading from a replicated one.

Returns: { instances: [{ path: string, props: object (typed values) }], instance_count: int, world: string, world_name: string|null, world_package: string|null, world_type: string|null, net_mode: string|null, pie_instance: number }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
worldNoOptional world selector: absent/'pie' (default, ambiguous: PlayWorld, else the first PIE context) | 'server' (the PIE world with authority) | 'client' | 'pie:N' | 'editor' | 'game' (alias of 'pie'). THIS is the parameter that separates a server reading from a client one.
componentNoOptional component name to drill into on each matched actor (reads that component's props instead of the actor's). WARNING: actors that have no component with this name are DROPPED from `instances` entirely, so a short list can mean "wrong component name", not "no such actor".
class_nameNoClass filter: bare UClass name resolved with FindFirstObject (e.g. "BP_MyActor_C", "StaticMeshActor"), NOT an asset path. Matches every actor that IsA(class_name). REQUIRED unless actor_label is given.
propertiesNoOptional property names to read. Names the target does not have are skipped SILENTLY (no not_found list — cross-check the spelling with list_object_properties or get_class_properties). Omit it to read every BlueprintVisible property, which on a Character is a very large payload.
actor_labelNoEditor-label filter; matches actors whose GetActorLabel() equals this EXACTLY (no substring, no case-folding). REQUIRED unless class_name is given — the call errors when both are missing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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 mark it read-only/idempotent, but the description adds substantive behavior beyond them: it reads the editor world even with no PIE running, stamps which world answered, drops actors lacking the requested component (so a short list may mean wrong component name), and silently skips unknown property names.

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 and the key 'instead of execute_python' hook are front-loaded, and the Returns block is clean. However the middle is a dense run-on covering world/filter/component/property guidance in one breath, with some repetition of schema text.

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, but the description spells out the return shape ({ instances, instance_count, world, world_name, world_package, world_type, net_mode, pie_instance }), the required-parameter error condition, and the component/property caveats. Nothing an agent needs 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.

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all five parameters, including the world selector and the component-drop warning. The description largely mirrors that content rather than adding new syntax or semantics, so baseline 3 applies.

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+resource (enumerate actors by class/editor label and read their properties in one call), and carves out its niche versus siblings like get_actors_by_class and list_object_properties by emphasizing the combined enumerate+read behavior and { path, props } return. An agent can tell exactly what this does and what it replaces.

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?

Explicitly says to use it instead of an execute_python loop over GetAllActorsOfClass + get_editor_property, and names the reason (returns { path, props } per instance and stamps the answering world). It also gives concrete routing advice: filter with class_name/actor_label, drill with component, separate authority via world='server' vs 'client'.

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