Прочитать точную настройку счетов расчётов

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

Beyond the readOnly/openWorld annotations, it discloses two important behavioral traits: inherited settings are never substituted (so the result is exact, not inherited), and a missing or incompatible schema blocks the operation entirely. It doesn't discuss permissions or side conditions such as default database resolution, which the schema handles separately.

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?

Seven short sentences, front-loaded with purpose and scope rules, with the legacy-name note sensibly placed last. Some sentences are dense with domain jargon (Контрагент_Key, 'независимый регистр') that an agent without 1C context must infer, but nothing is redundant.

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 six-parameter read tool with an output schema, the description covers the non-obvious selection rules, the conditional requirement that the schema cannot express, and the failure mode. The only gaps are the meaning of the database parameter and the settlement-kind enum values, both documented in the schema itself.

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 schema description coverage at 17%, the description carries most of the burden and does so for the critical logic: the conditional contract requirement not expressed by the schema's required list, the shared counterparty field for counterparty/group scopes, and the empty-GUID organization meaning 'all organizations' while the subject stays exact. Settlement-kind enum values and the database parameter are left to the schema.

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 ('Читает точную настройку независимого регистра') and immediately scopes it by 'scope' values, which lets an agent distinguish it from write.accounting.set_settlement_settings and from the legacy read.accounting.get_contract_settlement_settings, whose narrower behavior is explicitly 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?

It gives per-scope eligibility rules: contract requires a договор, while counterparty/group use the same Контрагент_Key field without a contract. It also flags the legacy alternative as contract-only. It stops short of an explicit 'use X instead when Y' routing instruction, which keeps it from a 5.

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