Skip to main content
Glama

list_widget_bound_events

Read-onlyIdempotent

List every event-dispatcher binding in a Blueprint, including component/widget and actor bound events, before wiring new ones to avoid duplicate handlers.

Instructions

List every event-dispatcher BINDING wired in a Blueprint, across the three node kinds that make one in practice: UK2Node_AddDelegate (from add_object_bound_event / add_graph_node node_type="add_delegate"), UK2Node_ComponentBoundEvent (from add_component_bound_event -- a component's dispatcher OR a UMG widget's, e.g. a Button's OnClicked) and UK2Node_ActorBoundEvent (a level actor's, bound from the Level Blueprint). Each entry reports which kind it is (binding_kind), what it is bound ON (bound_to: the component/widget variable, or the actor), the delegate's owner class and name, and the handler on the other end. Despite the name it works on ANY Blueprint -- but it only walks Ubergraph pages and FunctionGraphs, so a binding inside a macro or interface graph is out of scope. Run it BEFORE add_object_bound_event / add_component_bound_event: double-binding one delegate to two handlers compiles fine and silently runs BOTH. A reader that cannot see what the writer wrote is worse than no reader: a 0 reads as "not wired" and sends you to re-wire what is already there.

Returns: { blueprint_name, bindings:[{ graph_name, node_id, binding_kind, bound_to, delegate_owner_class, delegate_name, delegate_resolved, wired, custom_event_name, custom_event_node_id }], binding_count, kind_counts:{add_delegate,component_bound_event,actor_bound_event} } -- binding_kind names the node class behind the entry. bound_to is the component/widget variable name (component_bound_event), the actor name (actor_bound_event), or empty for add_delegate, whose target pin is left unconnected by design. delegate_resolved=false means the delegate no longer resolves live (renamed/removed). wired=false is a DANGLING add_delegate bind (its Delegate pin has no handler); the two *BoundEvent kinds ARE their own handler, so they are always wired and custom_event_name is the generated BndEvt__ function.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
blueprint_nameNoBlueprint asset name or path (Actor Blueprint, Widget Blueprint or Level Blueprint).
blueprint_pathNoAlias of `blueprint_name` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `blueprint_name`.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds substantial behavior beyond them: only Ubergraph pages and FunctionGraphs are walked, delegate_resolved=false means a rename/removal, wired=false is a dangling add_delegate bind, and *BoundEvent kinds are their own handler. These are non-obvious traits that would otherwise be invisible.

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 purpose, then caveat, then the before-writing rationale, then the return shape. Every sentence carries information, but the single dense paragraph plus a long Returns block is heavy reading; minor tightening is possible without losing meaning.

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?

There is no output schema, so the description must carry return semantics and it does exhaustively: full JSON shape, meaning of binding_kind, bound_to, delegate_resolved, wired, and custom_event_name. Nothing an agent needs to interpret the result correctly 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%, and both parameters (blueprint_name and its blueprint_path alias) are documented in the schema, including the note that the alias exists only for consistency with siblings. The description adds no parameter-level meaning, so the baseline 3 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 (List) and resource (event-dispatcher bindings wired in a Blueprint), then enumerates the three concrete node kinds it covers (add_delegate, component_bound_event, actor_bound_event) with their originating tools. An agent can distinguish it from add_object_bound_event / add_component_bound_event without opening either schema, and the description even notes the name is broader than the behavior ('works on ANY Blueprint').

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

Usage Guidelines5/5

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

Explicitly says to run it BEFORE add_object_bound_event / add_component_bound_event and explains why: double-binding one delegate to two handlers compiles and silently runs BOTH. It also declares exclusions (macro and interface graphs are out of scope) and warns that a misleading 0 would send the agent to re-wire existing bindings. This is textbook when/when-not/alternative guidance.

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