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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real behavioral substance beyond that: the rate regime by due date (CNB repo rate at the first day of the half-year + 8 points, or government regulation 142/1994 for older delays), the flat fee applied per claim, that the partial-payment day counts toward delay, and the § 1932 application order differing for businesses vs consumers. It does not say what the response looks like, which matters since there is no output schema.

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?

Purpose and the B2B fee are front-loaded, and every sentence carries legal or computational content. It is dense but long for a tool description, and the trailing EN one-liner duplicates rather than extends the Czech text.

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 fairly complex calculator with nested claim/payment arrays and no output schema, the description covers input logic and legal rules well. It is silent on output structure, however — whether it returns per-claim interest, totals, day counts, or the applied rate — which is exactly the gap an output schema would otherwise fill.

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, and the description genuinely earns more: it explains why the claim's due date selects a rate regime, why vztah=b2b triggers the per-claim flat fee, and why the consumer-contract date changes how a payment is applied. These are consequences of parameter values that the schema alone does not convey.

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 concrete verb and resource ("Spočítá zákonný úrok z prodlení s placením peněžitého dluhu") and shows the tool's distinctive behavior (per-claim calculation, CZK 1,200 flat fee for B2B). Differentiation from siblings is attempted but muddled: it says it shares "tímtéž jádrem jako nástroj uroky" without saying which one an agent should pick, so the boundary with uroky remains fuzzy.

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?

Usage is implied rather than stated: the agent can infer this is for overdue money debts, and the B2B/consumer payment-application rules are sketched. There is no explicit when-to-use/when-not guidance, no mention of the related sibling urok_z_vyzivneho or uroky as the alternative, and no prerequisites or limits are stated.

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