IUSTORIA – české právní kalkulačky a průvodci

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

Annotations already establish the safe read-only profile, so the description adds real value beyond them: it discloses the temporal branching rule (mandate before/after 1.1.2026), the deliberate exclusion of the záloha due to § 12 odst. 2 ambiguity, and that both readings are surfaced in a warning. This is meaningful behavioral context a caller could not infer from annotations alone.

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-loads the purpose and then packs the enumeration of sub-cases and the exclusion note into a dense but information-carrying paragraph. Every clause maps to an actual computation rule, though the density is on the edge of being hard to scan.

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 six-parameter calculator with no output schema, the description covers the decision space (situations, mandate versions, flat-rate tiers, DPH) and flags the one intentional omission with a warning, which is the key output-relevant fact. It is essentially complete, with the minor gap that it does not sketch the returned figures.

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 the schema already documents all six parameters in detail. The description summarizes some drivers (band-based odměna, 50% for early payment, 3,500/4,500 flat rate, increases for multiple parties, DPH) but adds no syntax or semantics beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 precise verb and resource (computes executor's fee and flat expense reimbursement in a money-collection execution) and anchors it to a specific legal regulation (vyhláška 330/2001). This clearly separates it from siblings like naklady_sporu and soudni_poplatky, which cover different cost types.

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 clear context for use (exekuce na zaplacení peněz), distinguishes pre-/post-2026 mandates, and explicitly states a limitation (záloha na náklady se nepočítá). It does not, however, name sibling tools or give explicit when-not conditions relative to them, so 4 rather than 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 readOnly, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds useful behavioral context beyond that: it caps results at five pages, notes the expert-guarantee curation, and describes the return shape (short answer, related questions, link). It stops short of covering rate limits or empty-result behavior.

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?

A single, well-structured paragraph that front-loads what the tool searches before describing the return and the sibling hand-off. No filler sentences, though it packs several distinct facts into one long sentence.

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 no output schema, the description correctly carries the return-value burden, describing the five-page cap and the answer/question/link payload. Parameters are fully covered by the schema, so the definition is complete enough to invoke the tool 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 description coverage is 100%, so both parameters are already documented in the schema, establishing a baseline of 3. The description reinforces the topic scope but its example list is partial and includes 'rozvod', which is not one of the eight enum hub values, adding little beyond the schema.

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 specific verb and resource ('Vyhledá stránky českých právních průvodců IUSTORIA') and scopes the searchable topics with concrete examples. It also names the sibling nacist_stranku as the tool for the full text, so an agent can distinguish this search tool from retrieval without opening any 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?

It clearly signals the retrieval boundary by pointing to nacist_stranku for the full page text, which tells the agent when this tool alone is insufficient. It does not, however, describe when to prefer this tool over the other legal siblings (lhuta, promlceni, exekutorsky_tarif), so routing among those 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 it as read-only, idempotent and non-destructive, so the safety profile is covered. The description adds substantial domain behavior the schema/annotations do not: event day excluded, weekend/holiday roll-forward, month-end handling for Feb 29 / day 31, deemed-delivery via data box and post office including the ten-day roll, and the 'dřívější den jako rezerva' output. It also discloses a boundary ('Den právní moci nepočítá').

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 verb and scope, then dense but purposeful sentences, each carrying a distinct legal rule or edge case. It is long and reads as one block, but nothing is filler; a slight structural tightening (e.g., grouping the delivery-fiction clauses) would earn a 5.

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 7 parameters, no output schema, and a rich domain, the description covers inputs (which deadline types, fiction-delivery starting points) and even sketches the output ('rozepíše výpočet krok po kroku', 'ukáže dřívější den jako rezervu', 'Řekne, co lhůtu zachová'). Nothing an agent needs to invoke and rely on it appears 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 the schema already documents every parameter including the enums. The description reinforces the statutory basis (druh, lhuta, pocatek) but adds no syntax or format detail beyond what the schema states; baseline 3 is correct.

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 (spočítá poslední den lhůty, rozepíše výpočet) and resource (legal deadline end date), then enumerates exactly which deadline regimes it covers (§ 57 OSŘ procedural, § 605–607 OZ substantive). An agent can immediately tell this is the deadline-computation tool, distinct from promlceni and the fee/calculation siblings.

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 makes the applicable context clear: procedural deadlines, substantive-law deadlines, and delivery-by-fiction scenarios, plus an explicit exclusion ('Den právní moci nepočítá'). It does not name an alternative tool or state when-not-to-pick-this beyond the legal-force limitation, so it stops short of a full routing statement.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely useful behavior beyond them: the 30000-character chunking limit and the fact that continuation is driven by od_znaku, plus the Markdown structure of the payload. Authorization is not discussed, but for a read-only public-page fetch the remaining gap is minor.

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?

Three dense sentences, front-loaded with what is returned, then scope, then pagination mechanics. No filler and nothing repeated from the title or annotations.

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 no output schema, the description carries the return contract and does so: Markdown format, included sections, chunk size, and how to fetch subsequent chunks. An agent has everything needed to call this correctly and interpret the response.

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. The description goes further by tying the two parameters together into a pagination protocol ('nejvýše 30000 znaků, další část přes od_znaku'), which is meaning the schema alone does not convey about how od_znaku relates to truncated output.

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 ('Vrátí celý text stránky průvodce IUSTORIA jako Markdown') and enumerates the returned sections (summary, FAQ, sources). It is clearly distinct from the sibling hledat_v_pruvodcich, which it names as the discovery tool rather than a retrieval 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?

Gives explicit routing ('adresy najde nástroj hledat_v_pruvodcich') and a hard scope constraint (only www.iustoria.cz pages approved by the guarantor), which tells the agent when this tool is applicable. It does not state a when-not-to-use case beyond that scope bound, so it stops short of a 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?

The annotations already declare the tool as read-only, idempotent, non-destructive, and closed-world, so the description's main added value is the crucial caveat that it calculates the statutory tariff fee, not the actual contractual attorney fee. It also specifies which cost components are included, giving good behavioral context beyond the 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 sentences, front-loaded with the core purpose followed by a precise limitation. Every phrase earns its place: the first sentence enumerates outputs and the second clarifies the statutory-tariff basis.

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 eight-parameter estimator with full schema coverage and read-only annotations, the description is nearly complete: it states what is calculated and the statutory-tariff caveat. The main gap is the lack of explicit guidance on when to choose this tool over sibling calculators, but that is a usage-guideline concern rather than missing essential context for 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 description coverage is 100%, so all eight parameters are fully documented in the input schema. The description mentions some parameter-relevant concepts (court fee, attorney tariff, VAT), but adds no syntax or meaning beyond what the schema already provides; baseline 3 is appropriate.

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 specific verb ('Odhadne') and resource ('náklady sporu o zaplacení peněz'), then enumerates the cost components it covers (court fee, attorney tariff, VAT, winner/loser outcomes). This clearly defines the tool, but does not explicitly differentiate it from the sibling tool 'soudni_poplatky' or explain why one would choose this over that one.

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 context is implied by the title and the stated calculation scope, but the description does not say when to use this tool versus alternatives like 'soudni_poplatky' or 'exekutorsky_tarif'. It also gives no prerequisites or exclusions beyond the caveat about using statutory rather than contractual fees.

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 establish readOnly, idempotent and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it shifts the deadline past weekends and holidays, reports what suspends the period, and returns the earlier date where the interpretation is uncertain — real output semantics an agent could not infer from 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?

Three tight sentences: the first defines what is computed and the scope, the second covers weekend/holiday shifting and suspending events, the third covers the uncertainty fallback. Front-loaded and waste-free, especially good given the dense legal domain.

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 12-parameter legal calculator with no output schema, the description supplies the key behavioral outcomes (adjusted end date, suspending events, conservative earlier date on doubt). It does not explain that most parameters are conditional per typ, but the schema documents that fully, so the gap is minor.

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 the baseline is 3. The description's enumeration of claim types loosely mirrors the typ enum, and it names the qualifying conditions 'typ' and 'usmysl'... rather, 'typ' and 'umysl', but adds no syntax or date-formatting information beyond what the schema already documents thoroughly.

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: computes when a claim becomes time-barred under the Czech civil code, and enumerates the exact claim types covered (pohledávka, faktura, škoda, újma na zdraví, obohacení, rozhodnutí, uznaný dluh). This separates it cleanly from siblings like lhuta or exekutorsky_tarif.

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 makes the domain of use evident (limitation/expiry of a claim) but never says when to choose this tool over lhuta or the other legal siblings, nor states prerequisites or exclusions. Usage is implied rather than guidance given.

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 readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond the annotations: it discloses an additional output ('Řekne také, kolik se vrátí při smíru nebo zpětvzetí'), which the agent cannot infer from the structured fields.

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 calculating verb, then a compact enumeration of case types, then the refund behavior. The enumeration is long but each item earns its place by defining scope; only minor trimming would be possible.

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 no output schema, the description correctly compensates by stating that a fee amount is computed and that refund-on-settlement/withdrawal is also returned. Given a read-only stateless calculator with fully documented parameters, this is nearly complete; a note on output format would close the remaining gap.

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% and all seven parameters carry detailed enum/default documentation, so the baseline is 3. The description largely maps onto the same case types already in the schema and adds only marginal detail (e.g. 'elektronický platební rozkaz'), not new parameter semantics.

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 ('Spočítá soudní poplatek podle zákona o soudních poplatcích') and enumerates the exact case types covered (žaloba o peníze, rozvod, vypořádání, určení vlastnictví, odvolání, dovolání). The scope is unambiguous, though it never names the neighboring tools (e.g. naklady_sporu) to differentiate itself explicitly.

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 list of covered proceedings implicitly signals when the tool applies, and the mention of appeals/cassation widens that context. However, there is no explicit when-to-use vs a sibling like naklady_sporu (court costs vs fees), and no prerequisites or exclusions are stated.

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?

Anotace již deklarují readOnlyHint, idempotentHint a destructiveHint=false, takže bezpečnostní profil je pokrytý. Popis nad to přidává konkrétní chování: které složky se počítají, jaké situace se zohledňují a že pro rok bez ověřených hodnot nástroj výsledek nevydá a sdělí důvod.

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?

Jde o jeden hustý odstavec, ale informace jsou řazeny od hlavního účelu k dílčím režimům a omezením. Vzhledem ke složitosti právního výpočtu je text přiměřeně dlouhý, i když by mu prospělo členění do odrážek.

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?

Nástroj je komplexní, má 10 parametrů a nemá výstupní schéma. Popis však vypočítává očekávané výstupy, pokrývá oba režimy, právní podmínky i chybový stav pro neověřený rok, takže pro správné volání je dostatečně úplný.

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?

Schéma má 100% popisnou pokrytost, takže všechny parametry jsou již srozumitelně dokumentovány. Popis sice shrnuje klíčové vstupy, ale nepřidává k parametrům žádnou syntaxi ani význam nad rámec schématu.

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?

Stáčí konkrétní sloveso i předmět: spočítá srážky z čisté mzdy při exekuci a v oddlužení, s uvedením právního základu. Je zřejmé, že jde o specializovanou kalkulačku odlišnou od sourozeneckých nástrojů, i když žádný sourozenec není jmenován.

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?

Popis jasně vymezuje, kdy se nástroj použije: v režimu exekuce nebo oddlužení, podle roku výplaty a podle zohledňovaných okolností. Neuvádí však explicitně, kdy místo něj použít některý ze sourozeneckých nástrojů.

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