pob_tree_action

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

The annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds useful sourcing rules for IDs and mastery, but does not say which of the five actions are the destructive ones (refund/toggle), nor what happens to downstream nodes on refund — context it could supply 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with no filler, and the core purpose plus the two ID-sourcing rules come first. The action list is slightly elliptical — four of five enum values are named in compressed noun form — which costs a point.

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

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

For a five-parameter, destructive, multi-action mutation tool with no output schema and zero schema descriptions, this is adequate but not complete: two enum actions and one parameter stay opaque, and there is no indication of what a successful call returns or whether a build must be loaded first.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the parameter burden. It partially does: it maps attribute values 1/2/3 to strength/agility/intelligence, names the node catalog as the id source, and explains mastery's dependency — but the text parameter, and the meaning of the toggle and right actions, are left unexplained.

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

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

The description opens with a specific verb+resource ("Действие оригинального дерева") and enumerates the operations it covers: path allocation, refund, attribute and note. An agent can tell it mutates the passive tree rather than reading it, though it does not explicitly contrast itself with pob_tree_options or pob_node_tooltip.

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

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

It gives prerequisite guidance — take IDs from the nodes catalog, and mastery from the node catalog entry — which steers correct invocation. But it never says when to pick this tool over pob_tree_options or why a caller would choose toggle versus allocate, leaving usage implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.