Skip to main content
Glama

get_actor_references

Read-onlyIdempotent

Lists the actor's own components (type, name, class), not external referencers; supports world selection to include components added at runtime.

Instructions

Despite the name this does NOT find who references the actor: it lists that actor's own COMPONENTS (type/name/class), i.e. a thinner get_actor_components with no mesh/light detail. For real reference graphs use the Asset Registry tools (get_asset_referencers / get_asset_dependencies). World-aware: world='editor' (default) | 'pie' | 'server' | 'client' | 'pie:N', which also makes it see components ADDED AT RUNTIME (AddComponent in BeginPlay) that the editor world does not have; the reply stamps world_name/world_package/net_mode/pie_instance.

Returns: { actor_name: string, actor_class: string, world: string, references: [{ type: string, name: string, class: string }], references_count: number, 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/'editor' (default) | 'pie' (ambiguous: PlayWorld, else the first PIE context) | 'server' (the PIE world with authority) | 'client' | 'pie:N' | 'game' (alias of 'pie'). An unrecognised value FAILS naming the worlds that exist; it never falls back to another world in silence.
actor_nameYesActor's internal name (GetName) or editor label (GetActorLabel); exact match.

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?

Beyond the readOnly/idempotent/non-destructive annotations, it discloses that world selection changes what is visible (PIE sees components ADDED AT RUNTIME that the editor world lacks) and that the reply stamps world_name/world_package/net_mode/pie_instance. It also reports the return shape, which is necessary since no output schema exists.

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?

The most important correction (the misleading name and its actual output) is front-loaded in the first clause. The trailing 'Returns:' block is long but earns its place because there is no output schema, so the size is justified rather than padding.

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 and a misleading tool name, the description supplies both the return shape and the world/context semantics an agent needs to call it correctly. Nothing material is missing for a two-parameter, world-aware query.

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 both parameters are already documented, making 3 the baseline. The description adds meaning by explaining the semantic consequence of the world selector (runtime-added component visibility) rather than just repeating the enumerations, which pushes it above baseline.

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 immediately corrects the misleading name ('Despite the name this does NOT find who references the actor') and states the real verb+resource: it lists the actor's own COMPONENTS. It also positions itself against siblings by calling itself 'a thinner get_actor_components with no mesh/light detail,' so an agent can distinguish it without opening any 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?

It explicitly says when NOT to use it ('For real reference graphs use the Asset Registry tools (get_asset_referencers / get_asset_dependencies)'), naming the exact alternatives. It further explains when to choose each world selector, including the runtime-visibility caveat, leaving nothing to inference.

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