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

Annotations already declare a safe read-only, idempotent, non-destructive profile, so the bar is lower. The description adds real behavioral context beyond that: it returns a reason instead of a result for 2027 cases above the first threshold, returns historical terms without a calculation for pre-2018 cases, and caps the sum at 380 days.

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 purpose and rates, and every legal detail (thresholds, rate changes, 2027 caveat, excluded low-income employees) is task-relevant. It is nonetheless a very dense single paragraph that repeats some year/threshold data already present in the schema, slightly hurting scannability.

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 an 8-parameter calculator with no output schema, the description supplies the full legal context an agent needs: formula components, rate schedule, threshold versioning, edge-case fallbacks, the alternative tool, and the 380-day cap. Nothing material for correct invocation 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 %, so per the rules the baseline is 3. The description earns above baseline by explaining that the year of onset determines the applicable reduction thresholds and rates, and by tying the calculation to the 12-month assessment base and reduction bands, which enriches interpretation of rok and the income parameters.

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+resource in Czech and EN: it calculates Czech sickness benefit (nemocenská) from day 15 of incapacity, including rates and reduction thresholds. It explicitly distinguishes itself from the sibling nahrada_mzdy_pri_nemoci, which handles the first 14 days, so an agent can route correctly without opening either 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?

Gives explicit scope (day 15 onward, employee or OSVČ), valid years (2018–2026 fully, 2027 conditionally), and names the alternative tool for the first 14 days. It also states when-not: employees with gross wage below the reference income are not computed, and earlier disabilities get historical rules without calculation.

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