garant_practice

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.