garant_kinds

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

With no annotations, the description carries the full behavioral burden and covers it well: the tool is a tree browser where node_id=0 is the top level (21 nodes) and each call expands one branch. It also discloses a taxonomy quirk (only RF Constitutional Court and Supreme Court live under «Высшие суды»). It does not explicitly state read-only semantics, but that is strongly implied by the browse-and-expand framing.

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 dense sentences, each earning its place: identity, purpose plus parameter semantics, and a practical domain gotcha. The final common-case sentence is slightly tangential but genuinely useful for the most frequent agent task, so there is no real waste.

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?

The tool is simple (one optional parameter, output schema present), and the description covers what it is, how to navigate it, and why to call it. Remaining gaps are minor: no statement about error behavior for invalid node ids and no explicit distinction from the tree-like sibling garant_toc.

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 meaning — and it does: node_id selects a tree node, the special value 0 means the top level with 21 nodes, and passing an id opens that branch. For the tool's single parameter this is near-complete semantics; only invalid-id behavior is left unstated.

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 the resource clearly — a tree of GARANT information kinds with concrete examples («Акты органов власти», «Высшие суды») — and anchors the purpose to supplying exact kind names for garant_practice(kind=...). The action verb is implicit ('подставьте id узла, чтобы раскрыть ветку') rather than explicit, and differentiation from siblings is partial, so it stops short of a 5.

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?

Explicitly says the tool exists to discover the precise kind value needed by the sibling garant_practice, which tells an agent when to reach for it. It adds a concrete common-case walkthrough (cassation court acts are absent from «Высшие суды»). It never contrasts with guarantee_toc or garant_search, but naming its consumer sibling is enough to place it in context.

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