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

Annotations already declare a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds genuinely non-obvious behavior: the 100 000 EUR per-client-per-bank aggregation rule ('several products of one bank share one limit'), the ČNB rate default and the eur_czk override, and the fact that eligibility flags gate which accounts are considered. It does not describe how yield is computed (taxes, bonuses, rate tiers), which is the main remaining gap.

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?

Front-loaded with the core action and the binding constraint, followed by the eligibility rule and one concrete example. Every sentence carries information an agent needs (limit semantics, currency handling, condition gating) and nothing is repeated from the schema.

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?

With an output schema present, the description needn't explain return values, and it covers the domain constraints, currency behavior and eligibility model well. It stops short of defining 'net yield' or noting that results are estimates subject to rate changes, but no blocking information is missing for a correct invocation.

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?

Schema coverage is 100%, so the baseline is 3, but the description earns above that by explaining eur_czk's role ('converted at today's ČNB rate unless eur_czk is given') and, more importantly, by clarifying that the four boolean capability flags act as eligibility filters over the product universe rather than simple preferences. The example also pins amount and max_banks to a realistic call.

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?

States a specific verb and resource ('Split a sum across Czech savings accounts') plus the optimization objective ('highest net yield') and the hard constraint (deposit insurance limit). This is clearly a planning/allocation tool, distinct from the sibling compare_* tools, and the Czech term plus the example query make the intent unambiguous.

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 conveys when to use it ('Mám 6 milionů, jak je rozložit, aby byly pojištěné?') and establishes the precondition that only accounts whose conditions the client meets are used. It does not explicitly route the agent away from hlidac_compare_savings or hlidac_compare_term_deposits, so there is no stated exclusion, but the usage context is clear.

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