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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's job is to say what gets changed and how failures behave. It does add real value: raw text is parsed through Item Lua, the item is added, and equipping only happens when a slot is given, gated by IsItemValidForSlot validation. It omits whether an item already in that slot is replaced, which build is affected, and what happens when validation fails — significant gaps for a destructive tool.

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?

A single sentence with no filler, and the core action plus the conditional equip behavior are front-loaded. It is dense with internal jargon (Item Lua, IsItemValidForSlot) that could obscure meaning for an agent without that domain context, but nothing is wasted.

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 destructive, no-output-schema mutation tool with two undocumented parameters, the definition leaves out what the caller most needs: which build receives the item, whether an existing slot item is overwritten, and what a success or validation failure looks like. The mechanics of parsing and validation are covered, but the operational picture is incomplete.

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 burden, and it partially does: 'raw' is understood to be item text in a copyable in-game format, and 'slot' is the optional target equipment slot with validation. However, it never specifies the expected text format, the slot naming convention (e.g. 'Helmet', 'Ring 2'), or why raw allows up to 65536 characters. Useful but incomplete compensation.

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 names a concrete verb chain and resource: recognize item text via Item Lua, add the item, and optionally equip it into a slot. That is far more specific than the name alone and lets an agent distinguish it from siblings like pob_add_skill_group or pob_catalog. It stops short of explicitly contrasting with those siblings, so it is clear but not fully differentiated.

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?

There is no guidance on when to use this versus alternatives such as pob_import_xml (bulk import) or pob_catalog (lookup), and no stated prerequisites such as an active build. The only conditional hint is that supplying 'slot' triggers equipping, which is behavioral rather than usage guidance. An agent must infer the calling context entirely.

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

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

Annotations declare destructiveHint=true and readOnlyHint=false, so the agent knows this mutates state, but the description never explains what is destroyed or replaced — the name says 'add', which suggests append-only while the annotations say destructive. Beyond the check_build pointer, it adds no context on limits (12 gems max), defaults, or failure behavior, so it does not close the gap the annotations open.

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?

Two short sentences with zero waste; the mutation purpose is front-loaded and the validation requirement follows immediately.

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 destructive mutation tool with a nested array of four per-gem fields, no output schema, and no schema descriptions, the definition is thin. An agent still cannot tell what happens to existing skill groups, what the defaults for level/quality/enabled are, or how errors are surfaced.

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 compensate. It does clarify the single most important semantic — that 'id' values must be exact IDs from the gems catalog — but says nothing about level, quality, enabled, or label, nor about the 1–12 item bounds, leaving most of the nested object's fields undocumented.

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 states a specific verb and resource: adding a group of gems from exact catalog IDs. This distinguishes it from siblings such as pob_add_item (items) and pob_catalog (lookup). It stops short of naming what kind of group or which catalog is authoritative, leaving a little inference to the agent.

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 clear workflow guidance by naming pob_check_build as the required follow-up for compatibility and error validation, which is a genuinely useful routing instruction. It does not, however, say when to prefer this tool over other add tools or what prerequisites must hold before calling it.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds that results are paginated and that the catalog can be read prior to build creation, which is genuinely beyond the annotations. It does not describe rate limits, result size, or what a catalog entry contains.

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?

Two short, front-loaded sentences with no filler. The catalog content comes first and the operational notes second, which is the right ordering for a lookup tool.

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?

With read-only annotations and no output schema, the description should say something about the shape of returned entries or how to page through results. It flags pagination but leaves the return payload and the 'query' filtering behavior undefined, which leaves an agent guessing on a 4-parameter tool.

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 parameter meaning and largely does not. It lists categories matching the 'kind' enum but omits the 'bases' value entirely and never explains 'query', 'limit', or 'offset' beyond the single word 'pagination'.

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 names a concrete resource (the source Lua catalog) and enumerates what it holds: exact IDs of gems, classes, nodes, configs, and slots. That tells an agent precisely what lookup data is available. It does not, however, distinguish itself from siblings like pob_node_tooltip or pob_check_build beyond the loose phrase 'available before creating a build'.

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?

The phrase 'available before creating a build' implies this is a prerequisite lookup step ahead of pob_create_build, which is useful sequencing guidance. There is no explicit statement of when not to use it, nor a direct pointer to an alternative tool for the same data.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. Beyond that the description discloses the report's sections and an honest limitation (targets does not validate build legality), which is useful context. It says nothing about output format, size/verbosity despite calling itself 'подробный', or behavior on an invalid/empty build.

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?

Two compact sentences, the content list is front-loaded and the caveat closes the definition, with no filler. Density comes at some cost of readability, since the noun stack ('камни/ошибки, предметы/неподдержанные строки') requires interpretation.

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?

Given one optional parameter, no output schema and read-only annotations, the definition supplies the report's content inventory plus the key limitation, which is most of what an agent needs. Remaining gaps are how the target build is selected (no build identifier parameter is mentioned) and the return format.

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 does add real meaning for `targets` (it compares numbers against goal values, and is not a legality check), which the bare `stat`/`min`/`max` schema does not convey. However, it never explains what valid `stat` keys/units look like or the 100-item cap, leaving the most error-prone part undocumented.

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 states a concrete verb+resource ('Подробный отчёт Lua') and enumerates the report's content areas (stats, conditions, gems/errors, items, slots, nodes, warnings), so an agent knows this is a read-only detailed dump rather than a mutation. It also scopes the `targets` feature ('сравнивает числа с целями, не доказывает легальность сборки'). It stops short of naming which build it reports on relative to siblings like pob_node_tooltip or pob_catalog.

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?

Usage is only implied: the shape of the description suggests 'call this to get a full diagnostic report of a build', and the closing clause sets a boundary (targets does not prove legality). There is no explicit 'use this instead of X when Y' and no statement of prerequisites, e.g. that a build must be loaded/imported first.

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

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

Annotations already declare destructiveHint=true and openWorldHint=false, so the safety profile is covered. The description does add real value by disclosing that the current session is replaced, which is consistent with the destructive hint, but it omits what exactly is lost (unsaved work), whether confirmation or persistence is needed, and what the result looks like. 'Уровень задаётся в ручном режиме' is ambiguous about behavior.

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?

It is short and the creation action is front-loaded, which is good. However, the internal jargon 'оригинальным newBuild' and the ambiguous 'ручном режиме' consume the limited space without conveying actionable information to an agent.

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 destructive, all-optional-parameter build-creation tool with no output schema and zero schema descriptions, the description should clarify default behavior when no parameters are supplied, the meaning of classId, and how a newly created build relates to the previously active session. None of that is present beyond the session-replacement note.

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% and all three parameters (name, level, classId) are undocumented in the schema. The description only touches 'level' with the vague phrase 'задаётся в ручном режиме' and says nothing about what name or classId mean, how classId relates to game classes, or what happens when all optional params are omitted.

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 states a specific verb and resource — 'Создать новую сборку' (create a new build) — and adds the scope note that it replaces the current session. It does not contrast itself with siblings such as pob_import_xml, and the phrase 'оригинальным newBuild' exposes an internal API name rather than user-facing meaning.

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?

There is no explicit guidance on when to pick this over pob_import_xml or when to start a fresh build instead of editing an existing one. The closest thing to routing information is the implicit hint that this is a from-scratch creation path, which the agent must infer.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context: it uses the native SaveDB serializer (output fidelity) and does not write a file, which is exactly the side-effect an agent might otherwise assume. Return transport (how the XML is delivered) remains unstated.

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?

A single compact sentence with the operation front-loaded, followed by the two facts that matter most (native serializer, no file write). Nothing is redundant or padded.

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 zero-parameter tool with no output schema, the description covers what it does and its main side-effect guarantee, which is close to sufficient. It does not state what exactly is exported (the whole current build?) or how the XML is returned, leaving a gap given there is no output schema to explain the response.

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?

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The schema is closed (additionalProperties=false) and empty, consistent with the description's parameterless framing.

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 names a specific verb (export) and resource (XML), and clarifies that it uses the original SaveDB serializer, which distinguishes it from the inverse sibling pob_import_xml. It does not explicitly name a sibling, so differentiation is inferred rather than stated.

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?

Usage is only implied: the phrase 'без записи файла' (no file write) suggests this is the choice when the agent wants XML in-band rather than a file artifact. No explicit when-to-use/when-not, no prerequisites, and no named alternative such as pob_import_xml or a file-writing path.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and 'Заменяет текущую сборку' restates rather than extends that. It does add one genuinely new behavioral fact – that the XML is parsed and computed through the Lua engine – but is silent on failure behavior, whether a partially valid XML leaves the build in a broken state, and whether the current build is recoverable.

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?

Two short sentences, front-loaded with the action and immediately followed by the side effect. There is no filler, though the phrasing is so terse that some useful detail was likely cut rather than tightening.

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 destructive whole-build replacement with no output schema, the description should say what comes back after the Lua calculation (build stats, validation errors) and whether the old build can be restored. The compute-through-Lua note helps, but the return/outcome picture remains unclear.

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?

Only one parameter exists and its schema coverage is 0%, so the description carries the burden. 'Полный XML' adds the useful semantic that the entire document is expected rather than a fragment, but nothing is said about the 4 MB size limit, encoding, or what an invalid XML looks like.

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 names a specific verb pair ('Загрузить ... и рассчитать') and a specific resource ('полный XML PathOfBuilding2'), and the phrase 'Заменяет текущую сборку' distinguishes it from the granular siblings like pob_add_item or pob_set_config. It falls short of a 5 because it does not name the most confusable sibling, pob_export_xml, or pob_create_build explicitly as the alternative path.

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?

'Загрузить полный XML' implies this is for whole-build import rather than incremental edits, which de facto routes agents away from the add/set tools. However, there is no explicit when-to-use statement, no guidance on where a valid PathOfBuilding2 XML comes from, and no stated alternative or precondition.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only a vague hint that computed changes are returned, without saying what triggers that computation or what the response contains — and there is no output schema to fill the gap.

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?

It is a single short sentence with no padding beyond the unhelpful word 'Оригинальный'. Brevity here comes at the cost of substance rather than from efficiency.

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 two-parameter inspection tool with no output schema, the description should identify the node id parameter and the meaning of the compare flag. Neither is covered, and the Russian-only wording diverges from the English naming used across sibling tools, adding friction.

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 carries the full burden, yet it never explains that 'id' is the tree node identifier or what the boolean 'compare' toggles. The phrase 'расчётные изменения' loosely gestures at 'compare' but leaves the semantics ambiguous.

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 names a resource (a passive-tree node tooltip) and lists what it exposes: properties, path, and calculated changes. However, 'Оригинальный AddNodeTooltip' is an internal API reference rather than a user-facing verb, and nothing distinguishes it from siblings like pob_tree_action or pob_tree_options, which also operate on tree nodes.

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?

There is no when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. An agent must infer from the tool name alone that this is the per-node inspection call versus the tree mutation calls.

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

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

The annotations declare readOnlyHint=false and destructiveHint=true, so this tool mutates state. The description's wording 'Выбрать' (select) reads as a benign choice and says nothing about the existing main-skill selection being replaced or overwritten. With annotations carrying the safety profile, the description should at least explain what state changes, but it does not.

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?

It is a single front-loaded sentence with no filler. The brevity is almost too tight for the amount of behavior that is left unexplained, but the sentence itself wastes nothing.

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?

This is a destructive mutation tool with no output schema and no annotation context in the description. Given that, the definition should state what gets replaced, whether it requires an imported build, and what happens on an invalid id. It covers none of these.

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 compensate. It does partially: 'основную группу или активное умение' maps to the control enum (groups vs skills), and 'по id из snapshot.buildInfo' tells where the id space comes from. It still doesn't explain what the ids refer to or how they are obtained.

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 names a specific verb (Выбрать/Select) and a resource (основную группу или активное умение), and it cites the id source (snapshot.buildInfo отчёта). However, it doesn't clarify what 'selecting a main skill' functionally means for the build, and it draws no boundary against siblings such as pob_add_skill_group or pob_tree_action, so an agent must infer the distinction.

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?

There is no guidance on when this tool should be used instead of alternatives. It mentions neither prerequisites (for example, that a build/report must already exist and contain buildInfo) nor exclusions.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's job is to explain what is destroyed or replaced — it says nothing about whether existing config entries are overwritten, whether the call is all-or-nothing, or what validation errors look like. The only extra sentence, "Выполняет ConfigTab:BuildModList", is an internal implementation detail that conveys no agent-facing behavior.

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?

The definition is short and front-loads the intent, which is good, but the second sentence about ConfigTab:BuildModList does not earn its place for an agent caller, and the remaining text is too compressed to be actionable.

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?

This is a destructive, closed-world mutation taking an untyped free-form object with no output schema and no annotations beyond hint flags, so the description should explain the accepted structure, the catalog dependency, and overwrite semantics. It omits all three, leaving an agent unable to call it safely.

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 coverage is 0% and the sole parameter is a free-form nested object with additionalProperties=false, so the description carries the full burden. Saying values must use "exact names, types and values of the config catalog" gives a hint about valid keys and typing, but no shape, key names, or example of the object is provided, leaving the agent unable to construct a valid payload.

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 names a specific verb ("Установить", set) and resource (config calculation conditions), but the qualifier "по точным именам, типам и значениям каталога config" is opaque without knowing what the config catalog is, and the reference to an internal method ("ConfigTab:BuildModList") adds no distinguishing information. It does not clearly separate this tool from the sibling pob_set_custom_mods, which also mutates build configuration.

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?

There is no when-to-use or when-not-to-use guidance and no mention of the natural prerequisite of calling pob_catalog first to obtain valid names/types. The agent must infer that this tool applies configuration discovered elsewhere and must choose it over pob_set_custom_mods without any stated rule.

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

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

Annotations already declare a destructive, non-read-only write, which "Заменить" (replace) is consistent with. The description adds real context beyond annotations - that the stored content is the author's assumptive modifiers and should be surfaced in reports - but says nothing about whether prior text is overwritten irreversibly, persistence, or validation.

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?

Two short clauses, front-loaded with the action and followed by the disambiguation and disclosure note; nothing is padded. Minor cost: the second and third ideas are compressed into one long semicolon clause rather than cleanly separated.

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 one-parameter mutation with a clear annotation profile and no output schema, the description covers what the tool does and its semantic caveat. It remains incomplete on the practical question an agent must answer before calling: what the accepted text format and constraints are.

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% and the single parameter 'text' carries only a type and maxLength. The description names it as custom modifier text but gives no format, syntax, line structure, or size expectations, so it barely compensates for the undocumented parameter.

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?

States a specific verb and resource ("Заменить текст пользовательских модификаторов" - replace custom modifier text) and adds a disambiguating clarification that these are author assumptions rather than items, which separates it from pob_add_item. It is not, however, tied to any other sibling explicitly.

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?

Usage is only implied: the note that these are assumptions, not items, tells the agent not to confuse it with item-adding tools, and the instruction to disclose them in the report hints at workflow context. There is no explicit when-to-use/when-not statement or named alternative.

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

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.

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

Annotations already flag this as non-read-only and destructive, and the description usefully adds the precondition that class changes with allocated nodes require `connect` or `reset`. It still never states what data is lost when `reset` is triggered or when specAction=delete is used, which is a notable gap for a destructiveHint=true tool.

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?

The definition is a single short sentence with no wasted words, but it is telegraphic and verbless, making the primary action hard to parse. Front-loading exists in the sense that affected options come first, though the key constraint is buried after a semicolon.

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 9-parameter, destructive, no-output-schema tool, the description is far too thin: most parameters and the spec-management lifecycle (new/clone/rename/delete) are undocumented, and there is no description of the outcome or state changes.

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?

With 9 parameters and 0% schema description coverage, the description must carry full semantic load, yet it only glosses class, ascendancy, spec, mode, connect and reset. The `name`, `compare` and especially the four-valued `specAction` enum (new/clone/rename/delete) are completely 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 lists affected build options (class, ascendancy, set, weapon mode via PassiveSpec) but omits a clear action verb, so it is unclear whether the tool sets, switches, or generates these options. It hints at the resource domain but gives no explicit differentiation from siblings such as pob_tree_action.

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?

One genuine usage constraint is stated: changing class while tree nodes are allocated requires `connect` or `reset`. However, there is no guidance on when to use this tool versus pob_tree_action or pob_set_config, and no prerequisites for the other operations are given.

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