Баланс терминала

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

No annotations are provided, so the description carries the full burden. It discloses the date constraint and server rejection behavior, which is valuable. However, it doesn't mention response structure or potential side effects beyond the date restriction, though for a balance read it likely suffices.

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 a single sentence that front-loads the purpose, then states the constraint, and concludes with the alternative tool. Every clause adds value, with no redundant information. It is efficient and well-structured.

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 one parameter, no output schema, and no annotations, the description covers the essential aspects: purpose, constraint, and alternative for other dates. It lacks explicit detail about the response format, but for a simple balance query, this is likely sufficient. The pointer to wata_finance_daily fills context for historical needs.

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 already documents the date parameter with format and allowed values, and coverage is 100%. The description adds the specific constraint that only today's or yesterday's UTC date is accepted and that other values are rejected, which goes beyond the schema's baseline and helps the agent correctly construct the parameter.

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 the terminal balance for a given date ('Баланс терминала на дату'). It distinguishes itself from sibling tools like wata_finance_daily by specifying the date constraint and explicitly naming the alternative for earlier periods, so an agent can tell them apart.

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 usage guidance: the date is mandatory and can only be today or yesterday in UTC, with other values rejected by the server. It also instructs to use wata_finance_daily for earlier periods, providing a clear when-to-use vs. when-not-to-use and an alternative.

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