Hlídač spoření

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds substantive context beyond that: the effective rate is computed for the whole amount because headline rates are capped per bank (with a concrete Česká spořitelna example), the 15% tax is applied, and the optional filters drop conditioned accounts. It stops short of noting result ordering/output shape, but the output schema covers returns.

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 purpose and the key ranking mechanism, then examples, then sibling routing. Every sentence carries information an agent would otherwise have to guess; no filler or restatement of the title.

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 7-parameter read-only ranking tool with a full output schema, the description covers the computation model, tax treatment, filter semantics and sibling routing. Returns need not be described since an output schema exists, so nothing essential is missing.

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 description coverage is 100%, so all seven parameters are already documented in the schema and the baseline is 3. The description adds modest value by explaining why 'amount' matters (band caps) and by giving example mappings for amount and no_conditions, but it does not elaborate on the other filters beyond what the schema says.

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 ('Rank Czech savings accounts by the effective interest rate for a given deposit') and immediately clarifies the net-of-tax and whole-amount basis. The final paragraph explicitly differentiates it from hlidac_get_product (single account bands/conditions) and hlidac_plan_allocation (splitting a large sum).

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?

Explicitly names the two relevant alternatives and the condition that selects them, and supplies two worked natural-language examples mapping to concrete parameter values (amount=800000; amount=1000000, no_conditions=true). Nothing about when to reach for this tool versus its siblings is left to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so safety is covered. The description adds real value beyond them: it discloses the 15% tax netting in the returned yield and, importantly, that banks failing the amount limits are surfaced separately in outside_limits rather than silently dropped.

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 ranking criterion and net-yield rule are front-loaded in the first sentence, and the optional-parameter semantics follow compactly. The bilingual glosses and duplicate examples add slight bulk but each clarifies a term an agent would otherwise have to guess.

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 and annotations covering safety, the description only needs to explain the ranking model and option effects, which it does. The outside_limits behavior is called out precisely so the agent can interpret results correctly.

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 extra by interpreting the parameters: it glosses need_early_withdrawal as withdrawal 'without the bank's consent' and supplies two intent-to-argument examples (amount=200000, term_months=12; term_months=3, client='new') that show how a user query becomes a 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?

Opens with a specific verb and resource ('Rank Czech term deposits... by the rate'), states the ranking criterion and the net-of-15%-tax yield. This clearly separates it from hlidac_compare_savings, which covers a different product class, so an agent can pick correctly without opening the schema.

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 concrete selection conditions for the optional parameters (only count new-client offers with client='new', drop promotions, require early withdrawal) and two worked query examples that map natural language to arguments. It does not explicitly contrast itself against the savings sibling, so it is strong context rather than full when/when-not routing.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior, but the description adds concrete context: the response covers rate bands, conditions, promotion end, deposit insurance, early withdrawal, tax, verification, and unknowns. It also discloses that an unknown id returns valid ids, which is useful behavioral information beyond annotations.

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?

Two paragraphs, front-loaded with the purpose; the field list and ID-source note both earn their place. The first sentence is long but remains scannable and does not waste much space.

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 one-parameter lookup with a full output schema and rich annotations, the description supplies what remains: what detail is returned, where product_id comes from, and fallback behavior for unknown ids. Nothing needed to invoke it correctly is missing.

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% and the single product_id parameter already has a pattern and example. The description adds meaning beyond the schema by naming the two source comparison tools and describing the unknown-id behavior, though it does not add syntax details.

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 ('Full detail') and resource ('one product'), scoped to savings accounts and term deposits, and distinguishes from comparison siblings by singular-product focus and by naming where product_id comes from. An agent can identify it as the detail lookup rather than a comparison 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?

Explicitly routes product_id from hlidac_compare_savings or hlidac_compare_term_deposits and gives examples, so the intended sequence is clear. It stops short of an explicit when-not statement or naming hlidac_plan_allocation, so it is not full 5.

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

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.