Skip to main content
Glama

get_condition_info

Read-onlyIdempotent

Retrieve a StateTree condition node as JSON to inspect its class, instance ID, and properties without modifying the asset. Supports state enter conditions and transition conditions.

Instructions

Dump one condition node of a StateTree state as JSON without changing the asset: an enter condition of the state or, with target_kind "transition", a condition of one of its transitions. Returns class, instance_id and properties, the node struct fields (instance data is not included).

Returns: { tree_path, state_name, target_kind, transition_index, condition_index, class, instance_id, properties: {...} }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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 to read: "state" (default, the state EnterConditions) or "transition" (the Conditions of transition transition_index); any other value reads the enter conditions.
condition_indexYes0-based index into the selected condition list, as counted by list_conditions or list_transitions.
transition_indexNo0-based index into the state transitions; required when target_kind is "transition" and ignored otherwise.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.2.0
    • changedInput schema / properties / condition_index / description
      Previous value: -"0-based index into the resolved condition array."New value: +"0-based index into the selected condition list, as counted by list_conditions or list_transitions."
    • changedInput schema / properties / state_name / description
      Previous value: -"Name of the state."New value: +"Name of the state that owns the condition; the command fails without it."
    • changedInput schema / properties / target_kind / description
      Previous value: -"\"state\" (EnterConditions) or \"transition\" (transition.Conditions)."New value: +"Which list to read: \"state\" (default, the state EnterConditions) or \"transition\" (the Conditions of transition transition_index); any other value reads the enter conditions."
    • changedInput schema / properties / transition_index / description
      Previous value: -"Required only if target_kind=transition (0-based)."New value: +"0-based index into the state transitions; required when target_kind is \"transition\" and ignored otherwise."
    • changedInput schema / properties / tree_path / description
      Previous value: -"Asset path."New value: +"Asset path of the StateTree, e.g. \"/Game/AI/ST_Guard\"."
    • changedInput schema / required
      Previous value: -[
      -  "tree_path",
      -  "transition_index",
      -  "condition_index"
      -]New value: +[
      +  "tree_path",
      +  "state_name",
      +  "condition_index"
      +]
  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 readOnly/idempotent/non-destructive, but the description adds real context: the read does not change the asset, and it explicitly warns that instance data is not included while the node struct fields are. That negative disclosure is exactly the kind of trait an agent needs and cannot get from schema or 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 action and scope, then the return shape. Slightly redundant in that it enumerates 'class, instance_id and properties, the node struct fields' and then repeats them in the JSON literal, but the extra bytes are cheap and the ordering is sensible.

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?

There is no output schema, so the description correctly carries the return contract by spelling out the JSON object and the instance-data omission. Combined with 100% schema coverage and read-only annotations, an agent has everything needed to call it correctly.

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 the schema already documents tree_path, state_name, target_kind, condition_index and transition_index. The description echoes the state-vs-transition semantics of target_kind but adds no syntax, format, or default detail beyond it. Baseline 3 is correct.

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 ('Dump one condition node of a StateTree state as JSON') and distinguishes the two read modes (state EnterConditions vs a transition's conditions). It does not name sibling tools such as list_conditions or get_condition_property to sharpen the boundary, but the resource is unambiguous.

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?

Usage is implied rather than stated: the description explains the target_kind switch and how to reach a transition condition, but gives no when-to-use vs when-to-call list_conditions / get_condition_property guidance and no prerequisites. Adequate but with clear gaps.

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