Skip to main content
Glama
Sign In
UEAgent

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

set_pin_default_value

DestructiveIdempotent

Set an unconnected input pin's literal default in Blueprints, MetaSounds and Control Rigs, then read the value back to confirm what actually landed on the pin.

Instructions

Write the literal default of an UNCONNECTED input pin and return the value read BACK off the pin, in a Blueprint graph, a MetaSound Source or a Control Rig.

Blueprint: struct pins are canonicalized -- a bare GameplayTag name becomes (TagName="X"), and an UNREGISTERED tag is rejected up front instead of silently landing as an empty tag; value_json nativizes any struct and is the only way to put SEVERAL tags in a GameplayTagContainer; a plain string is fine for an FText pin. Refused: array, set and map pins (use a MakeArray/MakeSet/MakeMap node), pins split into sub-pins (recombine_blueprint_pin first), and any call while Play-in-Editor runs (see force). TRAP: on a FormatText "Format" pin the literal IS written but the {argument} pins are NOT created, leaving a valid, useless node -- build the string with Concat_StrStr / Conv_StringToText instead.

MetaSound: value is read as the input's type ("440", "true", "Hello"), node_id=@input sets a graph input's default, and the asset is saved. Control Rig: value is export text such as (X=1.0,Y=0.0,Z=0.0); the rig is compiled and saved. Material expressions, sound cue nodes and PCG nodes keep such values as properties: write them with set_properties on the node's object_path from get_graph_nodes.

Returns: { node_id, pin_name, default_value, graph_kind? } -- default_value is re-read from the pin AFTER the write, so it is the oracle for what actually landed (a rejected value shows up as the old one); for a MetaSound or Control Rig the reply is its editor's own, with the value read back.

Input 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.
valueNoLiteral default in the pin's exported-text form; empty string allowed (clears it). For a Blueprint struct pin, "()" clears and a leading "(" is passed through untouched.
node_idYesnode_id of the node owning the pin (from add_graph_node / get_graph_nodes), or @input on a MetaSound
pin_nameYesPin name; in a Blueprint an INPUT pin of that name is preferred, any pin with the name is the fallback
asset_pathNoThe graph asset: a Blueprint by name or path, or the path of a MetaSound Source or Control Rig.
graph_nameNoBlueprint only: the graph, default the event graph. The other assets have one graph: leave it out.
value_jsonNoOptional JSON object nativized into the struct's export-text form, for Blueprint STRUCT pins only. For an FGameplayTagContainer it must carry a "GameplayTags" array (["A","B"] or [{"TagName":"A"}]) and every tag is validated; takes precedence over 'value'.
blueprint_nameNoOlder name of asset_path, still accepted.
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. Changed7 schema fields changedv2.5.0
    • addedInput schema / properties / asset_path
      Added value: +{
+  "description": "The graph asset: a Blueprint by name or path, or the path of a MetaSound Source or Control Rig.",
+  "type": "string"
+}
    • changedInput schema / properties / blueprint_name / description
      Previous value: -"Blueprint asset name or path"New value: +"Older name of asset_path, still accepted."
    • changedInput schema / properties / graph_name / description
      Previous value: -"Target graph name; defaults to the Blueprint's event graph when omitted"New value: +"Blueprint only: the graph, default the event graph. The other assets have one graph: leave it out."
    • changedInput schema / properties / node_id / description
      Previous value: -"NodeGuid of the node owning the pin"New value: +"node_id of the node owning the pin (from add_graph_node / get_graph_nodes), or @input on a MetaSound"
    • changedInput schema / properties / pin_name / description
      Previous value: -"Pin name; an INPUT pin of that name is preferred, any pin with the name is the fallback"New value: +"Pin name; in a Blueprint an INPUT pin of that name is preferred, any pin with the name is the fallback"
    • changedInput schema / properties / value / description
      Previous value: -"Literal default in the pin's exported-text form; empty string allowed (clears it). For a struct pin, \"()\" clears and a leading \"(\" is passed through untouched."New value: +"Literal default in the pin's exported-text form; empty string allowed (clears it). For a Blueprint struct pin, \"()\" clears and a leading \"(\" is passed through untouched."
    • changedInput schema / properties / value_json / description
      Previous value: -"Optional JSON object nativized into the struct's export-text form, for STRUCT pins only. For an FGameplayTagContainer it must carry a \"GameplayTags\" array ([\"A\",\"B\"] or [{\"TagName\":\"A\"}]) and every tag is validated; takes precedence over 'value'."New value: +"Optional JSON object nativized into the struct's export-text form, for Blueprint STRUCT pins only. For an FGameplayTagContainer it must carry a \"GameplayTags\" array ([\"A\",\"B\"] or [{\"TagName\":\"A\"}]) and every tag is validated; takes precedence over 'value'."
  2. First observedv1.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations, the description discloses critical behavior: the write is refused during PIE unless `force=true`, MetaSound and Control Rig writes save/compile assets, struct values are canonicalized and invalid tags are rejected, and the read-back value is the oracle for what actually landed. It also warns about the FormatText trap where the literal is written but `{argument}` pins are not created.

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?

The description is long but appropriately sized for a complex, multi-asset mutation tool, and it is front-loaded with the core action and return semantics. The Blueprint/MetaSound/Control Rig structure makes dense constraints scannable, and each sentence carries operational value rather than restating schema fields.

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?

Given 9 parameters, a dangerous write/compile/save operation, no output schema, and sibling alternatives, the description is complete: it covers asset-type differences, refusals, traps, return shape, and read-back behavior. An agent has enough context to call this correctly or avoid it when another tool is appropriate.

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, but the description adds meaningful semantics beyond the schema: MetaSound values are read as the input type, Control Rig values use export text like `(X=1.0,Y=0.0,Z=0.0)`, `node_id=@input` sets a graph input default, and `value_json` is the only way to put several tags in a GameplayTagContainer. It does not fully document every alias/parameter, but it materially improves parameter understanding.

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 states a specific verb and resource: write the literal default of an unconnected input pin and read it back, across Blueprint, MetaSound Source, and Control Rig. It distinguishes the tool from `set_properties` by routing material expressions, sound cue nodes, and PCG nodes to that sibling, so an agent can identify the correct tool without schema inspection.

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 gives explicit when-to-use and when-not-to-use guidance, including refusal cases such as array/set/map pins, split sub-pins, and Play-in-Editor sessions. It also names concrete alternatives: use a MakeArray/MakeSet/MakeMap node, call `recombine_blueprint_pin` first, or use `set_properties` for material/sound cue/PCG node values.

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