Skip to main content
Glama

build_blueprint_graph

Destructive

Build multiple Blueprint nodes, wire their pins, and set pin defaults in one undo transaction, avoiding create-connect round-trips.

Instructions

Build several nodes, wire their pins, and set pin defaults in one pass, wrapped in a single undo transaction -- the way to author a whole graph shape without create -> get_graph_nodes -> connect round-trips (get_function_pins gives you the pin names up front). THE ORDER IS FIXED AND MATTERS: every node first, then ALL connections, then pin_defaults -- so a node whose TYPE depends on a pin default (a generic GetComponentByClass) is connected while still untyped, fails with "... is not compatible with ..." and, under stop_on_error's default true, takes the whole call down; use add_get_component_by_class_node, which is born typed. add_comment_node has no pins at all, so a pin_defaults entry aimed at one also kills the batch. Self-contained: each sub-step runs its command directly, never through the bridge (only these: add_graph_node, add_custom_event_node, add_timeline_to_blueprint, add_cast_node, add_branch_node, add_sequence_node, add_component_bound_event, add_input_action_event_node, add_enhanced_input_action_node, add_actor_begin_overlap_event, add_call_library_function, add_reroute_node, add_comment_node, add_select_node, add_make_struct_node, add_break_struct_node, add_parent_call_node, add_get_component_by_class_node, add_broadcast_node, add_object_bound_event, add_macro_instance_node). add_component_event is NOT usable here; create it with its own call.

Returns: { blueprint_name, graph_name, nodes: [{index, id, command_type, ok, node_id?, custom_event_node_id?, error?}], connections: [{index, ok, error?}], pin_defaults: [{index, ok, error?}], stopped_early, rollback_required, rolled_back, transaction_opened, undo_queue_len_before, undo_queue_len_after, top_transaction_title, rollback_refused_reason?, warning? }. rolled_back reports whether the undo ACTUALLY ran, not the intention: the rollback is refused (rolled_back:false + rollback_refused_reason + warning) whenever the top of the editor's undo stack is not this call's own transaction, because GEditor->UndoTransaction is global and would otherwise revert another agent's or another session's work in memory while the disk stays clean. A payload that fails pre-validation returns instead { success:false, error, validation_errors: [{section, index, id?, error}], transaction_opened:false, blueprint_name, graph_name } and never opens a transaction.

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.
nodesYes[{id: string, command_type: string, params?: object}, ...] (required, non-empty). 'id' is a caller-chosen local key used to reference the node from 'connections'/'pin_defaults'; 'params' is that command's own param object (blueprint_name/graph_name are auto-filled if omitted). WORKED EXAMPLE (print "hi" on BeginPlay, one call): nodes=[{"id":"beg","command_type":"add_graph_node","params":{"node_type":"event","event_name":"ReceiveBeginPlay"}},{"id":"print","command_type":"add_graph_node","params":{"node_type":"print_string"}}], connections=[{"from_node":"beg","from_pin":"then","to_node":"print","to_pin":"execute"}], pin_defaults=[{"node":"print","pin":"InString","value":"hi"}]. Pin names for a call_function node are knowable up front via get_function_pins (so no create->get_graph_nodes->connect round-trips). Child-override canonical shape (call the parent first), one call: nodes=[{"id":"evt","command_type":"add_graph_node","params":{"node_type":"event","event_name":"ReceiveBeginPlay"}},{"id":"super","command_type":"add_parent_call_node","params":{"function_name":"ReceiveBeginPlay"}}], connections=[{"from_node":"evt","from_pin":"then","to_node":"super","to_pin":"execute"}]. NOTE on add_object_bound_event: it creates TWO nodes; the step's local 'id' resolves to the UK2Node_AddDelegate (wire the external instance into its 'self' pin and the exec flow into 'execute'), while the handler custom event is addressable as "<id>.custom_event" and its real NodeGuid is echoed back as custom_event_node_id.
graph_nameNoTarget graph name; defaults to the Blueprint's event graph when omitted
connectionsNo[{from_node, from_pin, to_node, to_pin}, ...]; from_node/to_node may be a local 'id' from 'nodes' (or "<id>.custom_event" for an add_object_bound_event step's handler event) or a pre-existing real NodeGuid.
pin_defaultsNo[{node, pin, value}, ...]; node may be a local 'id' from 'nodes' (or "<id>.custom_event") or a pre-existing real NodeGuid.
stop_on_errorNoStop (and try to roll back the whole transaction) on the first failing step; defaults to true, unlike batch's default false, since connections/pin_defaults depend on earlier nodes existing. With stop_on_error:false there is NO rollback at all -- the editor's global undo is never touched, every step is attempted, and whatever half-built shape remains is cleaned up with delete_node/disconnect_pin. That is the safer mode when other work is live in the editor's undo buffer.
blueprint_nameNoBlueprint name or path.
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.8/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnly=false, destructive=true): discloses the FIXED ordering constraint, the failure mode where an untyped generic node errors and takes down the batch, that add_comment_node has no pins so a pin_defaults entry kills the batch, that components run directly rather than through the bridge, and detailed rollback-refusal semantics tied to the global undo stack.

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 and the key ordering rule, then details. It is dense and very long for a description, and the full 21-item sub-command enumeration plus the inline return-shape dump could be trimmed, but most sentences carry actionable constraints for a genuinely complex tool.

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 high-complexity batch mutation tool with no output schema, the description supplies the return shape, the pre-validation failure shape, the rollback/refusal behavior, the PIE refusal, and ordering constraints -- enough for an agent to call it correctly and interpret both success and failure.

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 schema already documents most params, making 3 the baseline. The description still adds cross-parameter semantics not in the schema: the mandatory node->connections->pin_defaults ordering and the prerequisite that referenced nodes exist first, which materially affects how the params must be composed.

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: 'Build several nodes, wire their pins, and set pin defaults in one pass, wrapped in a single undo transaction.' It explicitly distinguishes itself from the create -> get_graph_nodes -> connect round-trip flow and from sibling `batch`, so an agent can select it without opening other schemas.

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?

Explicit when-to-use (authoring a whole graph shape atomically) plus multiple when-not/alternative calls: get_function_pins for pin names up front, add_get_component_by_class_node for typed generic nodes, and 'add_component_event is NOT usable here; create it with its own call.' It also explains stop_on_error:true vs :false tradeoffs.

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