Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

scaffold_menu_screen

Build a styled Widget Blueprint menu screen with a centred panel, optional title, and buttons wired to OnClicked handlers, then compile and save.

Instructions

Build a styled menu screen: create or reuse the Widget Blueprint at package_path/name with a centred panel, optional title and one button per entry bound to an event-graph OnClicked handler, then compile and save. Re-runs reuse widgets and bindings. Returns contrast_ratio_normal_text; the default colors pass audit_widget_accessibility. Layout is not measured (long labels can clip) and text is inline, not String Table.

Returns: { widget_bp_path, asset_path, created, already_existed, root_widget, panel_widget, box_widget, title_widget, entries: [{label, button_widget, text_widget, handler_name, bound, already_bound, error}], entry_count, buttons_bound, colors: {panel, button, text}, contrast_ratio_normal_text, contrast_required, contrast_passes, contrast_note, theme_source, compiled, saved, save_error }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesAsset name, e.g. WBP_OptionsMenu.
saveNoCompile + save when done (default true).
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.
titleNoOptional heading text above the buttons. Omitted or empty = no title widget at all (not an empty one).
entriesYesREQUIRED, the buttons top to bottom. Each item is either a plain string (the label) or an object {label, handler_name?}. handler_name names the generated event-graph function; omitted, it becomes On<Label>Clicked. Order is preserved.
backgroundNoDraw the background panel (default true). false leaves the buttons floating on nothing -- which is what makes contrast unjudgeable, so it also drops contrast_ratio_normal_text from the payload.
text_colorNoLabel colour for title and buttons, same formats. Default white.
bind_eventsNoWire each button's OnClicked to a handler in the event graph (default true). false builds the visuals only.
panel_colorNoBackground panel colour. "#RRGGBBAA", [r,g,b,a] (LINEAR 0..1) or {R,G,B,A}. Default is a near-black panel.
panel_widthNoPanel width in pixels (default 480).
button_colorNoButton resting colour, same formats. If you override this, you own the contrast: the returned ratio tells you what you got.
package_pathYes/Game folder for the new Widget Blueprint (e.g. /Game/MyGame/UI).
panel_heightNoPanel height in pixels (default 560).
parent_classNoParent UUserWidget subclass (default "UUserWidget"). Pass a CommonUI activatable class here to scaffold a screen for a CommonUI stack.
theme_source_bpNoOptional /Game path of a Widget Blueprint holding a reference Button whose style is copied onto every generated button INSTEAD of the built-in defaults (same idea as apply_widget_style_preset's theme mode: one widget is the single source of truth).
title_font_sizeNoTitle text size in Slate font points, truncated to a whole number; default 36. Unused when title is empty.
button_font_sizeNoButton label size in Slate font points, truncated to a whole number; default 20. It also sets the contrast floor checked (3:1 at 18 or more, else 4.5:1); under 12 is what audit_widget_accessibility flags as small_text.
theme_source_widgetNoName of the reference Button inside theme_source_bp. Required with it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.2.0
    • changedInput schema / properties / button_font_size / description
      Previous value: -"Default 20. Anything under 12 is what audit_widget_accessibility flags as small_text."New value: +"Button label size in Slate font points, truncated to a whole number; default 20. It also sets the contrast floor checked (3:1 at 18 or more, else 4.5:1); under 12 is what audit_widget_accessibility flags as small_text."
    • changedInput schema / properties / title_font_size / description
      Previous value: -"Default 36."New value: +"Title text size in Slate font points, truncated to a whole number; default 36. Unused when title is empty."
  2. First observedv1.1.0

TDQS

A4/5.0
Behavior4/5

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

The description adds meaningful behavior beyond the generic annotations: it discloses that re-runs reuse existing widgets/bindings, that layout is not measured so long labels can clip, that text is baked inline rather than in a String Table, and that the default colors pass audit_widget_accessibility. The serious PIE-refusal hazard lives only in the schema's force param rather than the description body, so it is not a full 5.

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?

The opening sentence is dense and front-loaded with the verb, resource, and full output scope. The trailing returns block is verbose, but since there is no output schema it earns its place by documenting the payload; only minor redundancy keeps it from a 5.

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 18-parameter mutation tool with no output schema, the description compensates by enumerating the full return shape (widget paths, per-entry bound flags, contrast metrics, compile/save status) alongside its two known limitations. An agent has everything needed to call and interpret it.

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 schema already carries all 18 parameters with detailed semantics; the description adds little parameter guidance beyond restating title/entries behavior. Baseline 3 is appropriate 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 and resource ("Build a styled menu screen: create or reuse the Widget Blueprint") and enumerates exactly what it produces — panel, optional title, one button per entry bound to an OnClicked handler, plus compile/save. It is clearly distinguishable from siblings like create_widget_blueprint, add_widget_to_blueprint, or build_blueprint_graph, which do not do end-to-end menu scaffolding.

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?

Usage is implied rather than stated: "Re-runs reuse widgets and bindings" tells the agent it is safe to iterate, and the theme/parent_class parameters point at apply_widget_style_preset and CommonUI stacks. However, there is no explicit when-to-use-this-vs-alternatives statement (e.g., versus create_widget_blueprint + manual assembly), which an agent must infer.

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