Skip to main content
Glama

add_graph_node

Create a single Blueprint event or function graph node and return it with its newly allocated pins, enabling immediate wiring without an extra node lookup.

Instructions

Create ONE node in a Blueprint's event/function graph (node_type selects the kind) and return it WITH its freshly allocated pins, so connect_pins / set_pin_default_value can wire it immediately without a follow-up get_graph_nodes. Use build_blueprint_graph instead when several nodes must be created AND wired in a single undo transaction, and get_function_pins to learn a call_function's pin names BEFORE creating anything. node_type='event' creates a REAL override (the declaring interface/parent class is resolved automatically and bOverrideFunction is set; target_class is ignored here) and fails loudly for a name that is not an overridable event -- an interface method WITH a return value is not an event, use implement_interface_function.

Returns: { node_id, class, title, pos_x, pos_y, comment, pins:[{name, direction:'input'|'output', type, linked_to, default}], blueprint_name, graph_name } -- the created node WITH its freshly-allocated pins. The pin names are already here, so you can wire the node via connect_pins/set_pin_default_value WITHOUT a follow-up get_graph_nodes. Read "class" as a sanity check: a node_type that was expected to produce an async/latent node and comes back as "K2Node_CallFunction" is a mute no-op that still compiles 0/0.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
casesNoOptional string array of case pins for switch_int/switch_string/switch_name
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.
scopeNoOptional scope hint for variable_get/variable_set: 'auto' (default; a function-local variable declared in the target graph wins, else a self/member variable), 'local' (function-local variable ONLY), or 'member' (member variable only -- self, or on target_class when supplied). Ignored by other node types.
argumentsNoOptional string array of argument names for format_text
enum_pathYesEnum path or name; required for switch_enum and enum_literal nodes
node_typeYesOne of event, custom_event, call_function, print_string, variable_get, variable_set, branch, sequence, self, cast, spawn_actor (alias spawn_actor_from_class), create_widget, make_struct, break_struct, get_array_item, select, make_array, make_set, make_map, switch_int, switch_string, switch_name, switch_enum, enum_literal, format_text, foreach, foreach_with_break, do_once, gate, flipflop, for_loop, while_loop, is_valid, add_delegate, macro_instance
dispatcherYesEvent-dispatcher (multicast delegate) name; required for add_delegate node type. Must already exist in the COMPILED class (add_event_dispatcher + compile_blueprint), and it binds on self only -- for a dispatcher on another class use add_object_bound_event.
event_nameYesEvent name; required for event and custom_event node types
graph_nameNoTarget graph name; defaults to the Blueprint's event graph when omitted
num_inputsNoOptional input-pin count for make_array/make_set/make_map (added after spawn)
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)
struct_typeYesStruct type; required for make_struct and break_struct nodes
macro_sourceNoSet to "standard_macros" to skip this Blueprint's own MacroGraphs and resolve macro_graph_name only in the engine StandardMacros library. Only read for node_type=macro_instance.
target_classYesClass owning the function or cast/spawn target class. For variable_get/variable_set it names the class that owns the variable, producing a non-self member-access node (with a 'target' pin) instead of a self-context node. For create_widget it names the widget class to construct (e.g. WBP_Foo_C, a full asset path, or the widget Blueprint short name); the node exposes that widget's Expose-On-Spawn pins.
function_nameYesFunction to call; required for call_function node type
node_positionNoNode canvas position as [x, y]; takes precedence over position_x/position_y
variable_nameYesVariable to get/set; required for variable_get and variable_set
blueprint_nameNoBlueprint name (resolved under /Game/Blueprints) or full asset path. Pass the FULL path when the short name is ambiguous: a bare name that matches two assets resolves to one of them silently.
blueprint_pathNoAlias of `blueprint_name` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `blueprint_name`.
macro_graph_nameYesMacro graph name; required for node_type=macro_instance. Resolved against this Blueprint's own MacroGraphs first, then the engine StandardMacros.

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 give readOnly/destructive/idempotent/openWorld hints; the description adds substantial behavior: node_type='event' creates a REAL override with automatic interface/parent resolution and bOverrideFunction set, target_class is ignored, non-overridable names fail loudly, and reading the returned 'class' detects a mute no-op (K2Node_CallFunction). That is well beyond what the annotations convey.

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 action and routing, and the Returns block is dense and useful. It is somewhat repetitive, restating the 'freshly allocated pins / no follow-up get_graph_nodes' point twice, which costs a little against full marks.

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 carries the full return-value burden — and it does, enumerating the full return object and pin shape. For a 21-parameter, 9-required mutation tool it covers creation semantics, failure modes, and wiring follow-up adequately.

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 the schema itself explains nearly every parameter (node_type list, target_class, dispatcher, force/PIE warning, etc.), so the baseline is 3. The description adds interpretation for node_type='event' (target_class ignored, override semantics) but nothing about syntax or formats the schema doesn't already supply.

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 ('Create ONE node in a Blueprint's event/function graph') and immediately names the sibling it is not (build_blueprint_graph). An agent can distinguish it from connect_pins, get_graph_nodes and get_function_pins 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?

Explicitly gives when-to-use-this vs alternatives: use build_blueprint_graph when several nodes must be created AND wired in one undo transaction, and get_function_pins to learn call_function pin names BEFORE creating. Also explains the downstream sequence (connect_pins/set_pin_default_value) and that no follow-up get_graph_nodes is needed.

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