Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

add_macro_instance_node

Adds a macro instance node from a specified library asset to a Blueprint graph, enabling third-party or project macros. Defaults to the Blueprint's own macros if no library is given.

Instructions

Instantiate a macro from a macro LIBRARY asset ("/Game/Lib/ML_X.ML_X:MyMacro", or the library path plus macro_graph) -- the only way to reach a third-party or project macro library, since add_graph_node's macro aliases (foreach, do_once, gate, is_valid...) only look inside the engine StandardMacros. With no library path it falls back to this Blueprint's own MacroGraphs and then StandardMacros. Does NOT compile. Its pins start WILDCARD and only re-type once something is connected, which connect_pins handles by reconstructing the node.

Returns: { node_id, input_pins:[string], output_pins:[string], blueprint_name, graph_name } -- pin NAMES only, split by direction (no types or defaults); use get_node_pin_info on the node_id when the types matter.

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.
macroYesMacro identifier: "<macro-library-path>:<MacroGraphName>" (e.g. "/Game/Lib/ML_X.ML_X:MyMacro"), OR just the library asset path with the graph name in 'macro_graph', OR a bare graph name to resolve against this Blueprint's own MacroGraphs and then the engine StandardMacros.
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)
macro_graphNoMacro graph name, used when 'macro' is a library path with no ":<GraphName>" suffix.
node_positionNoNode canvas position as [x, y]; takes precedence over position_x/position_y
blueprint_nameNoName (or full object path) of the Blueprint to add the node to.
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.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation profile is covered. The description adds meaningful non-obvious behavior: it does NOT compile, pins start WILDCARD and re-type on connection, and connect_pins reconstructs the node as a result. The PIE-refusal/force semantics live in the schema, not the description, leaving a minor gap here.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the what and the why-it-matters (only route to external macro libraries), then covers behavior and returns in dense, load-bearing sentences. No filler; every clause informs invocation or downstream steps.

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?

With no output schema, the description fully documents the return shape (node_id, pin name lists by direction, blueprint/graph names) and routes the agent to get_node_pin_info when types matter. Combined with schema-side PIE guidance, 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description still adds value by explaining the identifier resolution chain (explicit 'path:Graph', path+macro_graph, or bare name against MacroGraphs then StandardMacros), which clarifies the relationship among the macro, macro_graph, and graph_name parameters beyond their individual schema text.

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 (instantiate) and resource (a macro from a macro library asset), and explicitly distinguishes itself from sibling add_graph_node by explaining that add_graph_node's aliases only resolve inside StandardMacros. An agent can identify exactly what this tool does versus its nearest neighbor.

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 names the alternative (add_graph_node) and the condition that selects this tool: reaching third-party or project macro libraries. It also states the fallback resolution order when no library path is given, so when-to-use is unambiguous.

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