Skip to main content
Glama

add_object_bound_event

Bind an external BlueprintAssignable event dispatcher to a custom event handler, so you can react to a widget or actor instance held in a variable.

Instructions

Bind a BlueprintAssignable event dispatcher of an EXTERNAL object (not self, not a component) to a handler custom event -- the editor's right-click "Assign" flow (FEdGraphSchemaAction_K2AssignDelegate). Use this to react to a dispatcher on a widget/actor instance held in a variable (e.g. a UMG widget's "On Radial Menu Item Selected"): it spawns a UK2Node_AddDelegate bound to target_class' dispatcher with its self/target pin LEFT UNCONNECTED (you wire the instance) and a UK2Node_CustomEvent whose OUTPUT pins mirror the dispatcher's params (e.g. the segment-data struct), already wired to the AddDelegate's Delegate pin. Unlike the add_delegate node_type (self-context only), this reaches a dispatcher on a foreign class. Does NOT compile the Blueprint (mirrors the engine action); compile afterward.

Returns: { blueprint_name, graph_name, target_class, dispatcher, add_delegate_node_id, custom_event_node_id, custom_event_name, wired, node_id, pins:[...] (the AddDelegate node's pins -- wire 'self'/Target = the widget instance and 'execute'/'then' into your exec flow), custom_event:{ node_id, pins:[...] } (hang handler logic off its 'then'/'output_delegate' and read the dispatcher's param output pins) }

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.
event_nameNoOptional desired name for the handler custom event; made unique in the Blueprint. Defaults to "<Dispatcher>_Event".
graph_nameNoTarget graph name; defaults to the Blueprint's event graph when omitted.
position_xNoNode X position on the graph canvas (ignored when node_position is set)
position_yNoNode Y position on the graph canvas (ignored when node_position is set)
target_classYesThe EXTERNAL class that owns the dispatcher. Accepts a Blueprint/widget short name, a full asset path, a full class path (/Game/.../WBP.WBP_C), a native /Script path, or the generated "..._C" class name. Prefer a full path or the "_C" class for reliable resolution.
node_positionNoNode canvas position as [x, y]; takes precedence over position_x/position_y
blueprint_nameNoName (or full object path) of the Blueprint being edited (the object that will bind the event, e.g. the hub component BP).
blueprint_pathNoAlias of `blueprint_name` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `blueprint_name`.
dispatcher_nameYesThe multicast delegate (event dispatcher) property to assign. Matched tolerantly: exact name, spaces stripped, or the display name (so "On Item Selected" resolves to the spaceless FName). On failure the error lists the assignable delegates found on target_class.

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 only declare it is a non-readonly, non-destructive, non-idempotent write; the description adds rich behavior beyond that: the exact nodes spawned, that the AddDelegate self/target pin is deliberately LEFT UNCONNECTED and must be wired by the caller, that the custom event's output pins mirror the dispatcher params, and that it mirrors the engine action without compiling. These are non-obvious side effects an agent must know.

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?

Purpose is front-loaded in the first clause, followed by the sibling distinction, the mechanics, and the wiring contract. It is dense and long, but nearly every sentence carries signal; the parenthetical editor-symbol references and the extended Returns block could be trimmed slightly 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?

For a complex graph-mutation tool with no output schema, the description compensates fully: it narrates the two nodes created, the wiring the caller must perform, the compile requirement, and a detailed shape of the return object including which pins to connect. An agent has everything needed to call and follow up 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 description coverage is 100%, so every one of the 10 parameters (including the PIE-refusal semantics of `force` and the tolerant matching of `dispatcher_name`) is already documented in the schema. The description references target_class' dispatcher and the wiring of returned pins but adds no new parameter-level syntax or defaults, 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?

The description opens with a precise verb+resource ("Bind a BlueprintAssignable event dispatcher of an EXTERNAL object") and immediately scopes it against siblings: "not self, not a component" and "Unlike the add_delegate node_type (self-context only), this reaches a dispatcher on a foreign class." An agent can distinguish this from the component-bound and self-context event tools without opening any schema.

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?

It states exactly when to reach for it (reacting to a dispatcher on a widget/actor instance held in a variable, with a concrete UMG example) and names the alternative it is not (add_delegate node_type, self-context only). It also flags the post-condition ("Does NOT compile the Blueprint... compile afterward"), which functions as explicit follow-up 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