Skip to main content
Glama

create_common_ui_stack

Sets a Widget Blueprint's root to a Common Activatable Widget Stack, creating it if missing. Optionally specify a subclass; falls back to base if invalid.

Instructions

Set the WidgetTree root to a UCommonActivatableWidgetStack (creating one if absent). root_class, when given, picks which UCommonActivatableWidgetStack subclass gets constructed (e.g. a project-authored BP subclass) -- an unresolvable or non-subclass value does not fail the call, it honestly falls back to the base stack class with a note (see root_class_note in the response).

Returns: { widget_blueprint_name, root_class?, already_existed, stack_class, root_class_requested, root_class_resolved, root_class_note?, root_changed, root_widget, root_widget_class }

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.
root_classNoOptional. Asset path (/Game/...) or /Script/<Module>.<ClassName> of a UCommonActivatableWidgetStack subclass. Omitted = base UCommonActivatableWidgetStack.
widget_blueprint_nameYes/Game path of the Widget Blueprint

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare the mutation/safety profile (readOnlyHint=false, destructiveHint=false). The description adds real behavioral context beyond that: the graceful fallback to the base stack class for unresolvable or non-subclass root_class values, and it foreshadows the response fields via root_class_note. It omits the PIE refusal behavior, though that is documented in the force parameter.

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, then qualifies root_class. The Returns block is verbose but useful given no output schema. Slightly dense but every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Annotations cover the safety profile and the description supplies the return-field shape in lieu of an output schema, plus fallback semantics. The only gap is the PIE constraint, which lives in the force parameter rather than the description.

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 baseline is 3, but the description adds genuinely useful semantics for root_class (subclass selection, fallback on invalid values, response note) that the schema alone doesn't convey.

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 (sets the WidgetTree root to a UCommonActivatableWidgetStack, creating one if absent) and clearly distinguishes it from siblings like push_common_ui_widget, scaffold_menu_screen, and create_widget_blueprint.

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

Usage Guidelines3/5

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

Explains what the tool does in detail but gives no explicit when-to-use versus alternatives (e.g. when to use this vs scaffold_menu_screen or push_common_ui_widget). Usage is implied by the operation name rather than routed.

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