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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safe-read profile needs no restating. The description adds genuine non-annotation context: the eligibility gate and its fallback behavior (eligible=false plus reason), the mid-year surcharge rule, and the default assumptions baked into the cost model.

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 front-loaded with the comparison logic and eligibility rule before the args block, which is the right order. It is somewhat long and the Args section largely restates the 89%-covered schema, but each line carries a default or semantic gloss rather than being pure duplication.

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 9 parameters and no output schema, the description carries the burden of explaining results, and it does so exhaustively: eligible, reason, verdict, surcharge_czk, evidence_cost_czk, difference_czk sign convention, months, flat_tax_monthly_2027_czk, and the rules block. Nothing needed to call or interpret the tool 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 89%, so the schema already documents most parameters and the baseline would be 3. The description goes beyond it by decoding ambiguous values ('0 = not in the flat-rate regime', '1 = whole year') and explaining defaults with business meaning ('pos_cost_monthly_czk default 0 – the EvidujZdarma POS is free', hardware 'spread over 3 years').

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 states a precise verb and resource: it compares the EET OFF surcharge (1 400 Kč/month) against the modeled real cost of registering sales (time × hourly rate + POS + hardware amortization). This is a specific computational purpose that no sibling tool (check_ico, classify_payment, get_facts) shares, so an agent can route to it unambiguously.

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?

It gives clear context for when the tool applies: 'only for natural persons in band 1 of the flat-rate tax with income up to 1,000,000 CZK; for others the tool returns eligible=false with the reason,' plus mid-year start handling. It does not name alternative tools, but none of the siblings compute this comparison, so exclusions are effectively covered by the eligibility rule.

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