Банковские данные по разделам

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

The annotations already indicate read-only, idempotent, non-destructive behavior, and the description substantially enriches the behavioral model: it discloses that invalid sections produce a refusal, that seven sections error without arg rather than returning empty, that obrezanie is unique to statements, and that response truncation is explicitly marked. This goes far beyond what annotations provide.

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 because it must enumerate a large section set and special cases, but the structure with bold caveats, a list of arg-requiring sections, and clear exclusions keeps it scannable. Every sentence earns its place; the slight lack of conciseness comes from the inherent breadth of the tool, not from redundancy or filler.

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 coverage of subtitle data and a large section list, the description is unusually complete: it considers edge cases, error behavior, response truncation, alternative tools, and ambiguous data location issues. The existence of an output schema means return value formats do not need to be encoded in the description. Agents can call this tool correctly with the information provided.

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 input schema has no parameter descriptions (0% coverage), and the description fully compensates for this: section is mapped to its full valid value set, arg is refined per section with concrete meanings and examples, days is specified as the statement window with default 30 and no effect on others, and max_chars semantics including the 0 default are explained. This is a model of parameter-level documentation.

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 identifies the tool as a universal getter for bank data organized by sections, and enumerates the supported section values. It also explicitly names sibling tools that handle certain cases (payment_qr, transfer_sbp_resolve, account_requisites), preventing confusion with nearby tools. The scope and purpose are unambiguous despite the breadth of the tool.

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 provides explicit guidance on when to use this tool and when to prefer alternatives: payment QR goes to payment_qr, recipient search belongs to transfer_sbp_resolve, and own account requisites belong to account_requisites. It also instructs agents to check both invoices and subscription_bills before concluding no unpaid bills exist. Required arg usage and error behavior are precisely defined.

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