Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

set_blueprint_component_array_element

DestructiveIdempotent

Patch, insert, or remove one element in a TArray property on a Blueprint component template while verifying all sibling elements remain unchanged.

Instructions

Author ONE element of a TArray property on a Blueprint component TEMPLATE (own SCS, or ICH-aware for a component inherited from an ancestor Blueprint): patch named struct members of an existing element, insert a new element at an index, or remove one. Every OTHER element is exported before and after and compared, so a whole-array rewrite that quietly loses the empty/None gaps cannot pass itself off as a targeted edit. There is deliberately NO 'move' operation.

Returns: { success, error?, data: { blueprint_name, component_name, property_name, source, operation, index, inner_type, num_before, num_after, fields_applied[], field_errors[], siblings_unchanged, siblings_changed[], element_value, post_compile_num, post_compile_element, compiled, saved, save_error?, verification } }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
saveNoOptional bool (default true): save the Blueprint package after the compile
forceNoOptional. This command is REFUSED while a Play-in-Editor session is running: it either compiles a Blueprint (the reinstancer can retain a world, and CheckForWorldGCLeaks is Fatal -- it KILLS the editor) or writes to disk (Editor.AllowSavingAssetsDuringPIE=0 makes the engine refuse the write, so it would report success without writing a byte). Stop PIE and retry instead; force=true runs it anyway, at your own risk.
indexYes0-based element index. set_fields/remove need an existing index; insert accepts 0..Num (Num appends)
fieldsNoObject of { StructMemberName: value } applied to the element. Used by set_fields, and by insert when the element type is a struct
compileNoOptional bool (default true): compile so the edited template reinstances
elementNoWhole-element JSON value. Used by insert for NON-struct element types (or instead of 'fields' for a struct)
operationNo'set_fields' (default), 'insert' or 'remove'
property_nameYesName of the TArray property on the component template
blueprint_nameNoBlueprint asset path or short name
blueprint_pathNoAlias of `blueprint_name` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `blueprint_name`.
component_nameYesComponent variable name (own or inherited)

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?

With annotations already covering the safety profile (destructive, idempotent, non-open-world), the description adds real behavioral context: it discloses that every OTHER element is exported before/after and compared so whole-array rewrites cannot masquerade as targeted edits, and that no 'move' operation exists. The schema's force param covers PIE refusal, so the description isn't repeating structured data.

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 the core action and scope; the Returns block is dense but justified since there is no output schema. The middle sentence on sibling comparison is slightly verbose, but 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?

For an 11-parameter mutation tool with nested objects and no output schema, the definition compensates by describing the returned payload (num_before/num_after, siblings_changed, compiled, saved, verification) and operation semantics. An agent has enough to call it correctly.

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 baseline is 3, but the description maps operations to parameters meaningfully: 'patch named struct members' ('fields'), 'insert a new element at an index' ('index'+'element'), and 'remove one' ('index'). This adds operation→parameter semantics beyond the already-detailed schema.

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 precise verb+resource: authoring ONE element of a TArray property on a Blueprint component template, with three named operations (set_fields/insert/remove). It explicitly bounds scope ('ONE element') and declares the absent 'move' operation, which distinguishes it from array-wide property setters like set_blueprint_component_property.

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?

Clear context is given: it distinguishes own-SCS vs ICH-aware inherited components and enumerates the three operations with their intent. However, it never names a sibling as the alternative (e.g. when to use set_blueprint_component_property instead), so routing still requires 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