Skip to main content
Glama

get_widget_blueprint_tree

Read-onlyIdempotent

Retrieve a Widget Blueprint's widget tree with optional typed property and slot values to verify styles without launching a PIE session.

Instructions

Return a Widget Blueprint's widget tree as nested {name, class, children[]} AND, on request, the actual VALUES of its widgets and slots -- which is what makes verifying a style a cheap read instead of a PIE session. Off by default (a bare tree is what name-only callers want); three switches turn it on: property_paths reads exact dotted paths ("WidgetStyle.Normal.TintColor") on every node whether or not they still hold the default -- this is the oracle that closes a set_widget_property; include_properties reports only what DIFFERS from each widget's archetype, i.e. what this Widget Blueprint actually changed, instead of the ~120 inherited properties nobody reads; include_slot adds each widget's UPanelSlot class plus its own non-default values (position, anchors, padding, row/column). Values come back as TYPED JSON, not UE export-text. widget_name dumps one subtree instead of the whole asset.

Returns: { widget_bp_path: string, asset_path: string, widget_count: int, root_widget: string, dumped_root: string, include_properties: bool, include_slot: bool, include_navigation: bool, property_paths: [string], tree: {name, class, properties?, unresolved_property_paths?, non_default_properties?, slot?, children: [...], children_omitted?} }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
max_depthNoOptional recursion limit (-1 = unlimited, the default). A panel cut off by the limit reports "children_omitted" instead of passing for a leaf.
widget_nameNoOptional: dump only this widget and its descendants instead of the whole tree.
include_slotNoEmit each widget's UPanelSlot class and its non-default slot values under "slot" (default false).
blueprint_nameNoAlias of `widget_bp_path` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `widget_bp_path`.
property_pathsNoOptional list of property names or dotted paths read on EVERY node, emitted under "properties" even when the value is still the default. A path that does not exist on a given widget is listed in that node's "unresolved_property_paths" (normal: a WidgetStyle has no meaning on a TextBlock), never silently dropped.
widget_bp_pathNo/Game path of the Widget Blueprint asset
include_navigationNoEmit each widget's six gamepad/keyboard navigation directions under "navigation" (default false). A widget with no authored navigation reports all six as Escape with has_authored_navigation:false -- which is what it will actually do in game, rather than an empty object the caller has to interpret. Author them with set_widget_navigation.
include_propertiesNoEmit each widget's editable properties that DIFFER from its archetype, under "non_default_properties" (default false).

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?

Annotations already cover read-only/idempotent safety, yet the description adds substantial behavioral context: values are typed JSON rather than UE export-text, include_properties reports only archetype diffs rather than ~120 inherited props, and widget_name narrows to a subtree. It also flags that paths not present on a node surface in unresolved_property_paths rather than being silently dropped.

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 core purpose in the first sentence, then groups the switches logically. It is dense and long, with occasional rhetorical phrasing ('the oracle that closes a set_widget_property', 'nobody reads'), but nearly every clause carries functional 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 8-parameter tool with no output schema, the description supplies the full return shape including tree node fields and the three value switches, so an agent knows both how to invoke it and what comes back. Nothing essential is missing.

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 meaningfully interprets the three switches (what 'default vs non-default' means, why property_paths differs from include_properties) and clarifies the off-by-default posture. This adds rationale beyond the schema's field-level text.

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 (return a Widget Blueprint's widget tree) and precisely delineates scope: nested {name, class, children[]} by default, with three opt-in switches for values. It clearly distinguishes itself from value-oriented siblings by describing exactly what it returns and in what shape.

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?

Explains when each mode applies: 'off by default (a bare tree is what name-only callers want)', property_paths as 'the oracle that closes a set_widget_property', and include_properties for archetype diffs. It frames the style-verification use case compellingly but does not name a specific alternative sibling to use instead.

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