Предпросмотр комиссии

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

Despite the annotations already declaring readOnly, idempotent, and non-destructive behavior, the description adds crucial non-obvious behaviors: pointerType:ACCOUNT causes the bank to return INVALID_REQUEST_DATA, unfinishedFlag:true means the result is not a valid quotable commission, and the accompanying «комиссия не взимается» message is not a reliable indicator of anything. It also discloses that paymentType is required here even though it must be omitted from the actual transfer.

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 key message (preview, no money movement) is front-loaded, and every subsequent line earns its place by covering a real callability or interpretation trap. The embedded JSON template with comments is an efficient way to describe a one-string-parameter API that is actually structured, and nothing extraneous is included.

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?

Because an output schema exists, the description does not need to restate the whole return shape, but it still explains the most important output interpretation rule about unfinishedFlag. It also ties the tool to its upstream dependencies, list_accounts() and transfer_sbp_resolve(), making the description sufficient for correct invocation without digging elsewhere.

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 only exposes a generic body string with zero description coverage, so the entire parameter semantics burden falls on the description. The description fully compensates by giving the exact JSON body shape: account, moneyAmount, currency, paymentType, provider, and providerFields, including concrete accepted values and the rule to copy providerFields whole from transfer_sbp_resolve().

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 preview/resource statement that also explicitly disclaims side effects. This distinguishes the tool from execution-style siblings like transfer or pay_bill, so an agent immediately understands this is a quote-only helper and not a funds-moving operation.

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 text clearly frames the tool as a commission preview and notes that money does NOT move, which tells the agent to use it before an actual transfer/payment. It also gives valuable usage context by requiring providerFields to be copied verbatim from a transfer_sbp_resolve() candidate. It does not explicitly name a sibling alternative like transfer for actually executing the payment, so it falls short of a 5.

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