Skip to main content
Glama

get_pie_focused_widget

Read-onlyIdempotent

Report which UMG widget has focus in a running PIE session, mapping Slate focus back to its owning User Widget for testable gamepad navigation assertions.

Instructions

Report which UMG widget currently has FOCUS in the running PIE session -- the assertion that makes gamepad navigation testable instead of eyeballed. Resolves FSlateApplication's focused SWidget and maps it back to the UMG UWidget that created it, by walking up to the owning SObjectWidget and matching cached widgets: the same route the engine's own navigation component uses, and it has to walk up because the widget holding focus is usually an internal SButton, not the one that maps 1:1 to a UWidget. Pair it with inject_key_input route="slate", the only input path that moves focus at all: press Down, read this, assert. Returns has_focus:false as an honest success (not an error) when nothing is focused -- which is itself the finding when a menu opens with no focus and every navigation key then appears to do nothing.

Returns: { has_focus: bool, slate_widget_type: string, widget_name: string, widget_class: string, owning_user_widget: string, owning_user_widget_class: string, resolved_to_umg: bool, note? } -- resolved_to_umg:false together with has_focus:true means something in Slate holds focus but it is not a UMG widget (the viewport, a native Slate panel); slate_widget_type still names it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
user_indexNoOptional Slate user index (default 0). Local co-op players are separate Slate users, so player 2 is user 1.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial behavior beyond them: the widget-focus resolution route, why the walk-up is necessary, and the meaningful distinction that has_focus:false is an honest success rather than an error. It also explains resolved_to_umg:false semantics for non-UMG Slate focus.

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 purpose before the mechanism and the pairing guidance. It is on the verbose side with some narrative phrasing ('instead of eyeballed'), but the structure is logical and the return-shape summary is useful rather than filler.

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?

No output schema exists, but the description fully enumerates the return fields and their meanings, including the null/absent cases. Combined with the mechanism explanation, an agent has everything needed to call and interpret this tool correctly.

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 coverage is 100% and the single user_index parameter is fully documented in the schema (default 0, local co-op players as separate Slate users). The description adds no parameter details, so the baseline 3 for high coverage applies.

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: report which UMG widget currently has focus in the running PIE session. It also describes the resolution mechanism (FSlateApplication focused SWidget mapped back to the owning UWidget), which distinguishes it from the many widget siblings. An agent knows exactly what this returns.

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?

Provides an explicit workflow pairing: 'Pair it with inject_key_input route="slate"... press Down, read this, assert', naming the only input path that moves focus. This is strong context, though it stops short of explicitly stating when not to use it or naming a sibling to avoid.

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