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

With no annotations provided, the description carries the full disclosure burden, and it does so exceptionally well. It reveals that output is normalized HTML rather than a machine-readable original, that `_нормализация` is always present, that editorial inserts may appear unchecked, that `_предупреждение` can indicate either incomplete or redundant text, and that exact verbatim comparison is not guaranteed. This is far beyond typical behavioral disclosure.

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 description is long, but almost every sentence adds necessary context for a high-stakes legal citation tool. It is front-loaded with the core purpose and then adds dense, non-redundant caveats. The meta-comment about not repeating `_нормализация` details is slightly verbose but serves a real purpose in preventing instruction drift.

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 complex tool with response warnings, normalization caveats, and chain requirements, the description covers nearly all critical operational context: when to use it, how the cut is made, what the two response keys mean, and what the tool cannot guarantee. The only notable omission is doc_id semantics, but the output schema exists and the most subtle behaviors are already explained.

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 description gives article thorough semantics: it is a number like '97', '109', or '5', and it explains how the cut is assembled. However, doc_id is never mentioned or described; only its name and schema title indicate it is a document identifier. Since schema description coverage is 0%, the description partially compensates but leaves one required parameter under-specified.

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 opening phrase 'Дословный текст конкретной статьи или пункта' clearly identifies the tool's function: returning verbatim text of a specific article or point. The later phrase 'Основной инструмент сверки цитат' adds a clear functional role. It lacks an explicit verb like 'returns', and it does not explicitly differentiate from sibling tools, 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?

The description explicitly positions the tool as the main citation-verification step before submitting a document and instructs the user not to truncate a quote mid-sentence. It also explains the chain assembly and notes that no separate 'article' endpoint exists. However, it does not name sibling tools to exclude or give explicit 'use X instead' guidance, so it is clear but not fully directive.

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?

With no annotations available, the description carries the full burden of behavioral disclosure and does so thoroughly: it exposes the always-present `_нормализация`, the caveat that 'полный текст' means page coverage rather than verbatim markup, the provenance fields, and the exact meaning of `_предупреждение` in both failure modes.

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 description is front-loaded with the core purpose and remains dense throughout, but the same 'второго его написания здесь нет намеренно' explanation appears twice and some meta-commentary could be tightened. Still, the length is justified by the tool's complexity and the absence of annotations.

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 tool with an output schema, the description covers purpose, alternatives, parameter semantics, response keys (`страниц`, `страниц_в_документе`, `_предупреждение`, `_нормализация`), and edge-case behavior. Nothing an agent needs to decide whether to call this tool is missing.

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%, so the description must explain the parameters. It clearly ties doc_id to the target document and gives max_pages a full treatment: what it controls, why it was exposed, what happens when omitted, and why a second prose copy was deliberately avoided.

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 and resource: 'Полный текст документа по doc_id + provenance', clearly stating it returns the full act text plus editorial metadata. It also distinguishes itself from garant_article by positioning this tool as the one to use when the whole act is needed.

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 explicitly states when to use the tool ('Использовать, когда нужен весь акт') and names the alternative for a single article/punkt ('Для одной статьи/пункта — garant_article (дешевле и точнее)'). It also explains how to react to the warning conditions, including retrying with a larger max_pages.

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?

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.

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It goes beyond a basic summary by revealing that results are deliberately incomplete, that court filtering is client-side substring matching, that only the first page is returned, and that the `_предупреждение` key signals this. It also explains the unreliable meaning of `номер_в_заголовке` and the removal of the misleading status field.

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 description is long but exceptionally information-dense. It is front-loaded with the core purpose, then logically organized into server behavior, parameter semantics, output limitations, and field caveats. Every sentence contributes meaningful guidance or a caveat necessary for correct use.

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 the tool's complexity, lack of annotations, and zero schema description coverage, the description is notably complete. It explains the filtering architecture, subscription limitations, incomplete-result semantics, parameter meanings, and even warns against drawing incorrect conclusions from empty output. The presence of an output schema reduces the need to describe return values.

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 schema has 0% description coverage, so the description correctly compensates by explaining `kind`, `court`, `date_from`, and `date_to` in detail, including defaults, client-side behavior, and date format. However, the required `query` parameter is not explicitly described, and `limit` is only indirectly mentioned as a truncation mechanism. This is a minor gap given the tool's search-oriented purpose.

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 and resource: 'Поиск судебной практики' (search of judicial practice), explicitly naming the courts covered. It is clearly distinguishable from sibling tools like garant_search or garant_document because it is scoped to court practice and court-specific filtering.

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 description gives explicit when-to-use and when-not-to-use guidance: it states that cassation court acts are unavailable in the subscription and that searching for them here is pointless, and it identifies the only working channel as the 'Высшие суды' kind. It also directs users to garant_kinds for the full list of kinds.

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?

No annotations exist, so the description carries full responsibility, and it delivers: it discloses absent fields (no text/provenance), inclusive edge-date behavior, the _предупреждение key and its intentionally incomplete branches, and an unverified possibility about id_редакции as documentId. It openly labels unchecked assumptions with 'не проверено' and 'МОЖЕТ приниматься'.

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 first line states the core function and the no-text caveat; subsequent sections are clearly delimited (response shape, edge dates, usage, text retrieval) and each paragraph carries non-redundant information. Despite length, no filler is present given the complexity.

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 nuanced legal-history tool with no annotations and an output schema, the description covers input format, response semantics, edge-case warnings, when to use it, and how to (not) obtain revision text. It even tells the agent what to tell the user when direct text retrieval is impossible.

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 0% schema coverage, the description compensates for on_date by specifying the format 'ДД.ММ.ГГГГ' and explaining how the date maps to period boundaries. doc_id is less explicitly described—it is only sensible by context and a later reference to documentId—so a small semantic gap remains.

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 'КАКАЯ редакция действовала на дату' and immediately clarifies it does not return the norm text. It names the response content (revision record with status, period, amending act, id) and distinguishes itself from garant_article, garant_document, and garant_revisions, so an agent can disambiguate.

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?

Explicit usage context is given: 'Применять, когда норма цитируется применительно к прошлому событию' with a concrete example. The 'ЧЕМ ВЗЯТЬ ТЕКСТ ТОЙ РЕДАКЦИИ' section explicitly states that garant_article and garant_document do not accept a revision parameter and cannot be used for past-date citation, telling when not to use alternatives.

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?

With no annotations, the description carries the full burden and succeeds. It discloses that cache is not used, period adjacency is counted by dates, boundaries are read inclusively, live-base behavior is unverified, and gaps between periods do not imply the norm was inactive. It also points to the `_предупреждение` key for additional warning branches.

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 text is very long and includes meta-commentary such as 'Перечислить их здесь не устаревая описание не может' and a philosophical aside about where the description ends and the record continues. While the caveats are relevant, the presentation is rambling and harder to scan than necessary.

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 the tool's complexity and the presence of an output schema, the description is nearly complete: it covers statuses, period semantics, multiple periods, null periods, warning keys, and monitoring logic. It falls short only by not documenting doc_id and not routing the agent to garant_revision_on_date, but these are secondary to the extensive behavioral detail.

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 schema has one required parameter, doc_id, with 0% schema description coverage. The description never explains what doc_id should be, its format, or how to obtain it, only referring to 'документа' generically. Low coverage means the description should compensate, but it does not.

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 opening sentence 'Список редакций документа и изменяющих актов' clearly states the tool's deliverable and resource. It is distinguishable from siblings like garant_document or garant_article by its focus on revisions and amending acts, though it does not explicitly name any sibling.

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 final paragraph provides an explicit monitoring use case: if the current revision is newer than the revision in which a norm was cited, the citation should be rechecked. This gives clear context for when to use the tool, but it does not contrast it with garant_revision_on_date or state 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?

With no annotations to rely on, the description fully carries the behavioral burden. It discloses that GARANT treats queries as a conjunction of words, that result lists are cached while text is not, that cached responses include provenance fields, and that documents added after cache entry will not appear. This is substantial, non-obvious behavioral context.

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 description is information-dense but well-structured: purpose, query constraints with examples, return shape, downstream use, then cache mechanics. Every sentence earns its place and the most critical usage pitfall is front-loaded.

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 description covers the essential operational context: what the tool returns, how to phrase queries, how caching affects freshness, and how to route the resulting doc_id into sibling tools. Given the tool's moderate complexity and absence of annotations, this is complete enough for an agent to invoke it correctly.

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 provides rich semantics for query (3–5 keywords, conjunction behavior, good/bad examples) and for use_cache (freshness behavior and provenance). Page and limit are not explained but their names, defaults, and the returned 'страница'/'всего_страниц' fields make their meaning reasonably inferable.

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 and resource: 'Поиск документов в базе ГАРАНТ по реквизитам или контексту.' It makes the search behavior immediately clear and distinguishes it from sibling document-retrieval tools by noting that doc_id is used downstream in garant_document / garant_article / garant_revisions.

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 description gives strong usage guidance for the query parameter and the cache: use_cache=False is recommended when today's completeness matters. It also implicitly explains the tool's role in the pipeline via 'doc_id использовать дальше в garant_document / garant_article / garant_revisions,' though it does not explicitly state when not to use this tool versus each sibling.

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?

No annotations are provided, so the description carries the behavioral disclosure burden. It discloses the return structure (sections, articles, element IDs) and the useful fallback scenario, but it does not mention error behavior, prerequisites, or how the tool behaves when doc_id is invalid.

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 description is two concise sentences, front-loaded with the core purpose and followed by a practical usage note. Every sentence adds value with no redundancy.

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 with one required parameter and an output schema already present, so return values do not need elaboration. The description provides purpose and a concrete use case, but the undocumented doc_id parameter and lack of behavioral notes keep it slightly short of fully complete.

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 description does not compensate: doc_id is never explained in terms of format, origin, or how to obtain it. The word 'document' in the description hints at the parameter's role, but an agent is left to infer the ID source and expected value.

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 clearly states the tool returns a document's table of contents: sections and articles with element identifiers. It also distinguishes itself from the sibling garant_article by describing a specific fallback scenario, making the tool's purpose unambiguous.

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 description explicitly says this tool is useful when garant_article does not find an article, providing clear when-to-use guidance and naming an alternative. It lacks explicit 'when not to use' exclusions, but the stated context is sufficient for most agent decisions.

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