Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

get_component_properties

Read-onlyIdempotent

Read all editable or Blueprint-visible properties of one component, including current values and active/registered state, without modifying anything—the read-back for set_component_property.

Instructions

Read every editable or Blueprint-visible property of one component, with its current value as text, plus whether it is active and registered, without changing anything: the read-back for set_component_property. Pass actor_name for a placed actor (world picks the editor instance or a live PIE world) or blueprint_name for a Blueprint component template.

Returns: { actor_name: string, component_name: string, component_class: string, properties: [{...}], properties_count: int, editable_properties_count: int, blueprint_visible_properties_count: int, public_properties_count: int, component_owner: string, component_is_active: bool, component_is_registered: bool, component_creation_method: string, 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/'editor' (default) reads the frozen editor archetype/CDO (pre-BeginPlay defaults); 'server' (the PIE world with authority -- what you want for replicated state in co-op) | 'client' | 'pie:N' | 'pie' (ambiguous) resolve the LIVE running PIE actor+component so runtime-mutated values (e.g. Health after BeginPlay) are returned; 'game' is an alias of 'pie'. Only affects the actor_name path; ignored for blueprint_name.
actor_nameNoObject name, else editor label, of the placed actor that owns the component; ignored when blueprint_name is given.
blueprint_nameNoBlueprint whose component template to read, by short name (searched under /Game/Blueprints, then the whole project) or asset path such as "/Game/Characters/BP_Hero"; it wins over actor_name, and world is ignored.
blueprint_pathNoAlias of `blueprint_name` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `blueprint_name`.
component_nameYesName of the component: its object name on a placed actor, or its SCS variable or native subobject name in a Blueprint.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.2.0
    • changedInput schema / properties / actor_name / description
      Previous value: -"Name of the actor containing the component"New value: +"Object name, else editor label, of the placed actor that owns the component; ignored when blueprint_name is given."
    • addedInput schema / properties / blueprint_name / description
      Added value: +"Blueprint whose component template to read, by short name (searched under /Game/Blueprints, then the whole project) or asset path such as \"/Game/Characters/BP_Hero\"; it wins over actor_name, and world is ignored."
    • changedInput schema / properties / component_name / description
      Previous value: -"Name of the component to get properties from"New value: +"Name of the component: its object name on a placed actor, or its SCS variable or native subobject name in a Blueprint."
  2. First observedv1.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered; the description reinforces this with 'without changing anything' and adds genuinely new context by enumerating the returned fields (property values, active/registered flags). It stops short of detailing the world-selection modes, which live in the schema.

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 in the first clause, followed by the alternative routing and then the return shape. The Returns block is long, but it earns its place because no output schema exists; it is slightly list-heavy but not redundant.

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, so the description carries the return-value burden and does so fully, enumerating every returned field. Combined with the 100%-covered schema, an agent has everything needed for both the placed-actor and Blueprint-template paths.

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 description coverage is 100%, so the schema already documents each parameter; baseline would be 3. The description adds conceptual clarity by explaining the actor_name vs blueprint_name fork and noting that world picks the editor instance or a live PIE world, giving an agent the mental model before it reads the per-parameter prose.

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 (Read) and resource (every editable or Blueprint-visible property of one component), including value-as-text and active/registered status. It explicitly positions itself as the counterpart to set_component_property, so an agent can distinguish it from mutation siblings without opening the 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?

Gives explicit routing: pass actor_name for a placed actor or blueprint_name for a Blueprint component template, and names set_component_property as the write counterpart this reads back. The when-to-use conditions are spelled out rather than implied.

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