Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

add_state_tree_binding

DestructiveIdempotent

Bind a UStateTree root parameter to a state or global node input property so the node reads it at runtime; choose task, condition, consideration, evaluator, or global task targets.

Instructions

Bind a UStateTree root parameter (source) to a target node's input property (target), so the node reads the parameter at runtime. The target defaults to a state Task, but target_kind selects any FStateTreeEditorNode list: enter_condition/consideration (on the state) or global_task/evaluator (on the tree) — the binding anchor (FStateTreeEditorNode::ID) is identical for every kind. Authors an FStateTreePropertyPathBinding in the editor data's property bindings (idempotent per target path — re-binding the same target replaces it); validate it resolves with compile_state_tree.

Returns: { tree_path: string, state_name: string?, target_kind: string, target_index: int, target_property: string, source_parameter: string, source_struct_id: string, target_struct_id: string, bound: bool, binding_count: int, saved: bool }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tree_pathYesAsset path to the UStateTree.
state_nameNoName of the state owning the target node (required for target_kind task|enter_condition|consideration; ignored for global_task|evaluator, which live on the tree).
target_kindNoWhich node list holds the target: "task" (default) | "enter_condition" | "consideration" | "global_task" | "evaluator".
target_indexNoOptional index into the selected node list (default 0).
target_propertyYesName of the target node's input property to bind (the binding target), e.g. "BindableText".
source_parameterYesName of the root parameter to bind from (the binding source; add it with add_tree_parameter first).

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 declare idempotentHint=true and destructiveHint=true, and the description usefully adds that re-binding the same target path replaces the existing binding, that the anchor ID is identical across kinds, and that it writes editor data. It could say more about what the 'destructive' replacement means or permission requirements, but it adds real context beyond the annotations.

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, then target_kind semantics, then idempotency, then the inline return shape. Dense but every clause earns its place; the long em-dash clause and the full Returns enumeration make it slightly heavy, but nothing is filler.

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 6-parameter mutation tool with no output schema, the description covers the required vs optional parameters, the idempotency/replacement behavior, and enumerates the return object fields inline. An agent has everything needed to call it correctly and interpret the result.

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 already 100% (baseline 3), but the description adds semantics the schema does not spell out: how target_kind selects the node list, that the binding anchor is the same for every kind, and that state_name is only relevant for state-scoped kinds. That is genuine added meaning over the property docs.

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 ('Bind a UStateTree root parameter (source) to a target node's input property') with the runtime effect ('so the node reads the parameter at runtime'). It clearly distinguishes itself from add_tree_parameter (which adds the source) and remove_tree_binding/list_tree_bindings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear prerequisites and follow-up: 'add it with add_tree_parameter first' and 'validate it resolves with compile_state_tree'. It also states the default target_kind and that state_name is ignored for global_task/evaluator. It stops short of naming explicit when-not conditions or a sibling alternative selection rule, so it falls short of 5.

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