Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

add_widget_extended

Add additional widget types—native classes or nested UserWidget instances—to a Widget Blueprint's tree.

Instructions

Add an EXTENDED-palette widget to a Widget Blueprint's tree. Same authoring path as add_widget_to_blueprint but supports a wider set of widget types (resolved via /Script/UMG.), PLUS arbitrary native widget classes and UserWidget (nested Widget Blueprint) instances.

Returns: { widget_bp_path: string, added_widget_name: string, widget_type: string, widget_class: string, parent_name: string, slot_class: string, added: bool, already_existed: bool, saved: bool, save_error: string }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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.
parent_nameNoOptional name of a panel widget to host the new child; defaults to the root widget.
widget_nameYesunique name for the new widget
widget_typeYesone of TextBlock, Button, Image, VerticalBox, CanvasPanel, ProgressBar, Slider, CheckBox, ComboBoxString, ScrollBox, Border, Overlay, SizeBox, WidgetSwitcher, HorizontalBox, EditableTextBox, Spacer, GridPanel, RichTextBlock, EditableText, MultiLineEditableText, ComboBox, SpinBox, ScaleBox, SafeZone, UniformGridPanel, WrapBox, MenuAnchor (the curated names; see list_widget_types), OR any other native widget class path (e.g. /Script/UMG.Throbber, /Script/UMG.ListView), OR a UserWidget-derived Widget Blueprint to embed as a nested instance, by its /Game asset path (e.g. /Game/UI/WBP_HealthBar) or generated-class path (/Game/UI/WBP_HealthBar.WBP_HealthBar_C)
blueprint_nameNoAlias of `widget_bp_path` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `widget_bp_path`.
widget_bp_pathNo/Game path of the Widget Blueprint asset

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare the write, non-idempotent, non-destructive profile. Beyond that the definition discloses the type-resolution mechanism (/Script/UMG.<Name>), the UserWidget-as-nested-instance behavior, and the full return payload shape (added/already_existed/saved/save_error) that no output schema provides. The PIE-refusal and asset-writing hazard is disclosed but lives in the force parameter description rather than the main body.

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-loads the purpose and the sibling comparison before the return contract, and every clause carries information. The inline enumeration of ten return fields is slightly dense but justified given no output schema exists.

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 a mutation tool with no output schema, the definition supplies the return shape, the alias rationale, the resolution rules, and the PIE hazard, while annotations carry the safety profile. Nothing an agent needs to invoke this correctly and interpret the result 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 enumerated widget_type values, the parent_name default, the blueprint_name alias, and the force/PIE warning are already in the schema. The description only re-paraphrases the resolution path; baseline 3 is correct when the schema does the heavy lifting.

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 (Add widget to a Widget Blueprint's tree) and explicitly scopes it as the EXTENDED-palette variant that also accepts arbitrary native classes and UserWidget instances. This cleanly distinguishes it from sibling add_widget_to_blueprint without the agent needing to open either schema.

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?

The comparison 'Same authoring path as add_widget_to_blueprint but supports a wider set of widget types... PLUS arbitrary native classes and UserWidget instances' gives clear context for when to pick this over the sibling. It stops short of an explicit 'use add_widget_to_blueprint when the type is in the curated list' routing statement, so selection still requires a small 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