Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

connect_anim_graph_pins

Destructive

Connect AnimGraph pins (including pose links) using the graph's own schema. Use instead of generic connect_pins; saves the blueprint but does not recompile.

Instructions

Wire two AnimGraph pins (pose links AND data pins) using the graph's OWN schema. USE THIS INSTEAD OF connect_pins inside an AnimGraph: the generic connect_pins uses the K2 schema, which does not understand FPoseLink/FComponentSpacePoseLink pose pins, whereas this goes through UAnimationGraphSchema::TryCreateConnection so pose links connect correctly. Saves the ABP but does NOT recompile it -- run compile_anim_blueprint after your edits for runtime effect.

Returns: { connected, source_node_id, target_node_id, saved }

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 (optional, default the top-level AnimGraph).
source_pinYesOutput pin name on the source node.
target_pinYesInput pin name on the target node.
blueprint_nameNoAlias of `anim_blueprint_path` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `anim_blueprint_path`.
source_node_idYesNodeGuid of the source node.
target_node_idYesNodeGuid of the target node.
anim_blueprint_pathNoPath/name of the UAnimBlueprint.

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 already flag destructive/not-idempotent, and the description adds real context beyond them: it saves the ABP but explicitly does NOT recompile it, and it discloses the return payload. The PIE-refusal/kill behavior is documented only in the force parameter, not the description, so it stops short of the full behavioral picture.

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 most decision-relevant clause (use this instead of connect_pins), then the compile caveat, then the return shape. Every sentence carries distinct information with no repetition of structured fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating graph-editing tool with no output schema, the description supplies the return shape and the critical save-vs-compile distinction. The outstanding gap is that the Play-in-Editor refusal (a fatal editor-kill risk) lives only in the optional force parameter rather than the description body.

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%, so all eight parameters are already explained in the schema, including the PIE warning and the blueprint_name alias. The description adds only the note that pins may be pose links or data pins, which is marginal beyond what the schema provides. Baseline 3 is appropriate.

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 concrete verb (wire) and precise resource (AnimGraph pins, pose links AND data pins), and explicitly differentiates itself from the sibling connect_pins by naming the schema it uses. An agent can tell exactly what this does and when it beats the generic alternative without opening a 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?

Gives explicit routing: 'USE THIS INSTEAD OF connect_pins inside an AnimGraph' with the reason (K2 schema cannot handle FPoseLink/FComponentSpacePoseLink). It also states the required follow-up ('run compile_anim_blueprint after your edits'), so the ordering of operations 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