Skip to main content
Glama

set_component_property

DestructiveIdempotent

Set any property on a level actor's component—structs, arrays, maps, refs, enums, tags—targeting the editor world or a live PIE world by name.

Instructions

Set the value of any property on a level actor's component via the canonical JSON->property importer (mcp_common::SetObjectProperty). Handles every FProperty kind: object/soft-object/class/soft-class refs (by "/Game/..." path string), enums (by name), FGameplayTag/FGameplayTagContainer (registry-validated), nested structs, arrays, sets and maps -- not just scalars, FVector, FRotator and FLinearColor. WARNING: it writes the EDITOR world BY DEFAULT even while PIE is running, and that is deliberate, not a bug: it is the only MCP route to a property Python's set_editor_property refuses (CPF_DisableEditOnInstance), and because the edit lands in the editor instance the NEXT PIE session already starts with it. The flip side is that a value written mid-PIE does NOT reach the running actor -- so to hit the live one you must ask for it: world='server' | 'client' | 'pie:N'. The reply stamps world_name/world_package/world_type/net_mode/pie_instance, so success:true says WHICH world was written (world_package is the field carrying the UEDPIE_N prefix -- in a World Partition map the UWorld keeps the map's own name).

Returns: { actor_name: string, component_name: string, property_name: string, property_type: string (FProperty class name), old_value: string, new_value: string (== final applied value), final_value: string (real value read back off the component), success: bool, value_changed: bool, component_class: string, component_is_active: bool, component_is_registered: bool, world: string (the selector actually used), world_name: string|null, world_package: string|null, world_type: string|null, net_mode: string|null, pie_instance: number }. With verify_persistence=true it also returns { construction_scripts_rerun: bool, has_non_trivial_user_construction_script: bool, post_construction_value: string, survives_construction_script: bool, persistence_note: string, verification: object, verification_checks: [object] }. On failure returns { success:false, error: <precise reason from the importer, or from the world resolver> }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
worldNoOptional world selector: absent/'editor' is the DEFAULT -- it writes the editor world even with PIE running, which is what persists into the next PIE and what makes CPF_DisableEditOnInstance reachable; 'server' (the live PIE world with authority) | 'client' | 'pie:N' write the RUNNING actor instead; 'pie' is the ambiguous resolution and 'game' its alias. An unrecognised value FAILS with a message naming what was asked for and listing the worlds that exist -- it never falls back to another world in silence.
actor_nameYesName of the actor containing the component. Matched against the actor's OBJECT name (GetName) only -- not its editor label.
property_nameYesName of the property to set
component_nameYesName of the component
property_valueNoNew value. Any JSON type: a bare string (e.g. "/Game/Foo.Foo" object path, "Movable" enum name, "A.B.C" gameplay tag, "(X=1,Y=2,Z=3)" struct text), a number/bool, or nested JSON (a struct object, an array for array/set/tag-container props, an object for map props). Strings still import via ImportText_Direct so prior callers keep working.
verify_persistenceNoOptional bool, default false. When true, run AActor::RerunConstructionScripts() and re-read the property to find out whether the value SURVIVES the User Construction Script. Without this, value_changed:true is measured BEFORE the UCS runs, so a property the UCS recomputes (the classic case: RelativeScale3D on a spline/box the UCS rescales) reports as changed and is silently reverted a moment later. Costs a full component rebuild of that actor, and it re-runs in whichever world you selected.

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?

Goes well beyond the annotations (destructiveHint=true, idempotentHint=true): it discloses that the default write target is the editor world even mid-PIE and that this is deliberate rather than a bug, that mid-PIE writes do NOT reach the running actor, that the response stamps world_package/net_mode/pie_instance, and that verify_persistence costs a full component rebuild. This is exactly the behavioural context 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 and the default-world WARNING are front-loaded, and the long returns block is justified because there is no output schema. It is verbose and the world semantics are repeated near-verbatim between the description and the schema's world parameter, which is mild duplication, but almost every sentence carries information.

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, the description fully enumerates the return shape and the verify_persistence extras, and it explains the failure response. For a destructive, world-selector-dependent mutation tool this leaves an agent with everything needed to call it correctly and interpret the result.

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 already 100%, so the schema carries the per-parameter text; the description adds semantic depth on top (the importer accepts every FProperty kind, property_value JSON shapes for refs/enums/tags/structs, world selector failure semantics). It largely restates the schema's world explanation, so it is reinforcement rather than net-new, but it is not redundant noise.

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 and resource ('Set the value of any property on a level actor's component') and scopes it against the alternatives by naming the mechanism ('the canonical JSON->property importer') and contrasting with Python's set_editor_property and other MCP routes. An agent can tell this apart from the blueprint-component and generic property setters without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear conditional guidance: default writes the editor world (persists into next PIE, reaches CPF_DisableEditOnInstance properties), while a live PIE actor requires world='server'|'client'|'pie:N'. It also tells the agent to opt into verify_persistence when the UCS may recompute a property. It stops short of explicitly naming sibling tools to prefer or when not to use this at all.

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