Skip to main content
Glama

remove_tree_binding

Destructive

Remove a property binding on a StateTree node to clear it like the editor and save the asset. Returns removal status and remaining bindings.

Instructions

Remove the property binding whose target is target_property on one node of a StateTree asset (and any binding to a sub-property of it), the way the StateTree editor clears a binding, then save the asset. Nothing bound there is not an error: removed is false and the asset is not saved. Returns removed, removed_count and remaining (bindings left in the tree); list them with list_tree_bindings.

Returns: { tree_path, target_kind, state_name?, target_index, target_property, target_struct_id, removed, removed_count, remaining, saved }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tree_pathYesAsset path of the StateTree, e.g. "/Game/AI/ST_Guard".
state_nameNoName of the state that owns the target node; needed for the task, condition, consideration and transition kinds.
target_kindYesNode list of the binding target: "task", "condition" (a state enter condition; "enter_condition" also works), "consideration", "transition" (a transition condition), "global_task" or "evaluator".
target_indexNo0-based index of the target node in its list, default 0; for the transition kind, the index into the Conditions of that transition.
target_propertyYesProperty path of the binding target on that node, as list_tree_bindings shows it in target_path, e.g. "BindableText".
transition_indexNo0-based index into the state transitions; used only by the transition kind.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.2.0
    • changedInput schema / properties / state_name / description
      Previous value: -"Required if target_kind in {task, condition, transition}."New value: +"Name of the state that owns the target node; needed for the task, condition, consideration and transition kinds."
    • changedInput schema / properties / target_index / description
      Previous value: -"0-based node index (task/condition/global_task/evaluator) — required for non-transition kinds."New value: +"0-based index of the target node in its list, default 0; for the transition kind, the index into the Conditions of that transition."
    • changedInput schema / properties / target_kind / description
      Previous value: -"\"task\" | \"condition\" | \"global_task\" | \"evaluator\" | \"transition\"."New value: +"Node list of the binding target: \"task\", \"condition\" (a state enter condition; \"enter_condition\" also works), \"consideration\", \"transition\" (a transition condition), \"global_task\" or \"evaluator\"."
    • changedInput schema / properties / target_property / description
      Previous value: -"Property path string on the target struct."New value: +"Property path of the binding target on that node, as list_tree_bindings shows it in target_path, e.g. \"BindableText\"."
    • changedInput schema / properties / transition_index / description
      Previous value: -"Required if target_kind=transition."New value: +"0-based index into the state transitions; used only by the transition kind."
    • changedInput schema / properties / tree_path / description
      Previous value: -"Asset path."New value: +"Asset path of the StateTree, e.g. \"/Game/AI/ST_Guard\"."
  2. First observedv1.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false. The description adds genuinely useful behavior beyond them: no-op yields removed=false and the asset is NOT saved, and it discloses the resulting saved/remaining state. That is richer than the annotations alone.

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?

The purpose and no-op rule are front-loaded and earn their place. The trailing 'Returns:' line is somewhat list-like, but with no output schema it compensates usefully rather than merely restating structured data.

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 destructive mutation with no output schema, the description covers effect, save behavior, no-op outcome, and the return shape an agent needs to branch on. Missing only sibling-level routing and permission/prerequisite notes, which are minor here.

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 all six parameters, including target_kind enum-like values and index semantics. The description reinforces target_property and sub-property handling but adds little parameter-level detail beyond the schema, so 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 specific verb (Remove) and resource (property binding of a given target_property on a StateTree node), plus scope ('and any binding to a sub-property of it'). Distinguishes itself from sibling list_tree_bindings, which it names as the complementary read tool.

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?

Explains the semantics clearly ('the way the StateTree editor clears a binding, then save the asset') and gives the important edge case that nothing bound is not an error. It routes to list_tree_bindings for inspection but does not contrast with near-neighbor removal tools (remove_transition, remove_state, etc.) or state 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