Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

add_get_component_by_class_node

Add a typed Get Component by Class node to a Blueprint graph, setting ComponentClass before reconstruction so the return pin is the requested class and connects without a cast.

Instructions

Add a GetComponentByClass node BORN TYPED: the ComponentClass pin is set before the node is reconstructed, so ReturnValue comes out as that component class instead of the generic ActorComponent and no cast is needed. Use it instead of add_graph_node + a pin_defaults entry: inside build_blueprint_graph the defaults are applied AFTER the connections, so a still-generic node fails to connect ("Actor Component Object Reference is not compatible with ...") and, with stop_on_error's default true, takes the whole batch down with it.

Returns: { node_id, class, title, pins:[...], blueprint_name, graph_name, component_class, return_pin_type } -- return_pin_type is the ORACLE: if it does not name the requested component class, the pin stayed generic and connecting it will fail.

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.
graph_nameNoTarget graph; 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)
node_positionNoNode canvas position as [x, y]; takes precedence over position_x/position_y
blueprint_nameNoBlueprint 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`.
component_classYesComponent class to fetch: short name, /Script/Module.Class, or a /Game Blueprint component path. Must be a UActorComponent subclass or the call errors.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only mark it non-readonly/non-idempotent; the description adds the actual mechanism (pin set before reconstruction), the concrete error message on failure, and the stop_on_error batch-kill behavior. The PIE refusal detail lives in the schema rather than the description, so it earns strong but not maximal credit.

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-loads the core behavior and the alternative-routing in the first sentence, with the returns/oracle as a distinct trailing block. It is dense and fairly long, but each sentence (mechanism, failure mode, oracle) carries real information, so little is wasted.

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 supplies the return shape (node_id, class, pins, component_class, return_pin_type) and explains that return_pin_type is the oracle for verifying the pin stayed typed. For an 8-param mutating node, an agent has everything needed to call and verify it.

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 coverage is 100%, so parameter semantics are already fully documented (component_class, force, blueprint_path alias, positions). The description adds conceptual meaning to component_class via the 'born typed' mechanism but no syntax or format detail beyond the schema. 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?

States a specific verb+resource (add a GetComponentByClass node) plus the distinguishing behavior: the pin is 'BORN TYPED' so ReturnValue is the component class with no cast. It explicitly names the sibling alternative (add_graph_node) and why this exists, so an agent can tell them apart without opening 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?

Explicitly says to use this instead of add_graph_node + a pin_defaults entry, and gives the concrete reason: inside build_blueprint_graph defaults apply AFTER connections, so a generic node fails to connect and, with stop_on_error's default true, kills the whole batch. Clear when-to-use plus when-not.

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