Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

get_condition_property

Read-onlyIdempotent

Read a property from a StateTree condition node by reflection, for enter or transition conditions, without changing the asset. Returns JSON with value, C++ type, and has_value.

Instructions

Read one property of a condition node on a StateTree state by reflection, without changing the asset: an enter condition, or a transition condition with target_kind "transition". Returns the value as JSON with its C++ type and has_value; only node struct properties are reachable, not instance data.

Returns: { tree_path, state_name, target_kind, transition_index, condition_index, property, type, value, has_value }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
propertyYesName of a property on the condition node struct, e.g. "bInvert" on a compare condition; case-insensitive.
tree_pathYesAsset path of the StateTree, e.g. "/Game/AI/ST_Guard".
state_nameYesName of the state that owns the condition; the command fails without it.
target_kindNoWhich list holds the condition: "state" (default, EnterConditions) or "transition" (Conditions of transition transition_index); any other value means "state".
condition_indexNo0-based index into the selected condition list; omitting it fails as out of range.
transition_indexNo0-based index into the state transitions; used only when target_kind is "transition", where omitting it fails.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.2.0
    • changedInput schema / properties / condition_index / description
      Previous value: -"0-based index into the selected condition list."New value: +"0-based index into the selected condition list; omitting it fails as out of range."
    • changedInput schema / properties / property / description
      Previous value: -"Name of the property to read off the condition's script struct."New value: +"Name of a property on the condition node struct, e.g. \"bInvert\" on a compare condition; case-insensitive."
    • changedInput schema / properties / state_name / description
      Previous value: -"Name of the state that owns the condition."New value: +"Name of the state that owns the condition; the command fails without it."
    • changedInput schema / properties / target_kind / description
      Previous value: -"Which condition list to read from: \"state\" (EnterConditions, default) or \"transition\"."New value: +"Which list holds the condition: \"state\" (default, EnterConditions) or \"transition\" (Conditions of transition transition_index); any other value means \"state\"."
    • changedInput schema / properties / transition_index / description
      Previous value: -"0-based index into the state's Transitions; required when target_kind is \"transition\"."New value: +"0-based index into the state transitions; used only when target_kind is \"transition\", where omitting it fails."
    • changedInput schema / properties / tree_path / description
      Previous value: -"Asset path to the UStateTree."New value: +"Asset path of the StateTree, e.g. \"/Game/AI/ST_Guard\"."
    • changedInput schema / required
      Previous value: -[
-  "tree_path",
-  "property"
-]New value: +[
+  "tree_path",
+  "state_name",
+  "property"
+]
  2. First observedv1.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotent/destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: reads happen 'by reflection, without changing the asset' and only node struct properties are reachable (not instance data), which constrains what an agent can retrieve.

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 action and constraint, and appropriately brief. The explicit return-key list partially repeats the earlier 'value as JSON with its C++ type and has_value' sentence, a minor redundancy given no output schema is declared.

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 6-param read tool with full schema coverage and no output schema, the definition supplies the return shape and the node-struct-only limitation. It is complete enough to call correctly, though it omits failure modes such as how a missing/invalid property is reported.

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 six parameters are already documented in the schema. The description reinforces the target_kind duality and the node-struct-only reachability, but adds no syntax or format detail beyond what the schema already states. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Read one property of a condition node on a StateTree state by reflection'. It clarifies the scope (enter condition or transition condition) and distinguishes it from mutation tools, but it never names the sibling that returns condition metadata (e.g. get_condition_info) to sharpen the boundary.

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

Usage Guidelines3/5

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

There is implied usage ('or a transition condition with target_kind "transition"') and the constraint that only node struct properties are reachable, not instance data. But it doesn't say when to prefer this over get_condition_info or list_conditions, nor any preconditions/prerequisites.

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