Skip to main content
Glama

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

Kalkulačka úroků a úroků z prodlení

uroky
Read-onlyIdempotent

Spočítá úroky podle českého práva s rozpisem po úsecích: zákonný úrok z prodlení ve všech režimech podle dne vzniku prodlení (od 15. 7. 1994: dvojnásobek diskontní sazby, pohyblivá sazba pro prodlení 28. 4. 2005 až 30. 6. 2010, repo sazba ČNB + 7 nebo + 8 procentních bodů; mezi podnikateli od prodlení vzniklého 1. 1. 2001, kdy § 369 obchodního zákoníku začal odkazovat na občanskoprávní sazbu), sjednaný úrok z prodlení (roční nebo denní sazba, se zákonnou variantou a stropem podle § 122 zákona o spotřebitelském úvěru), smluvní úrok ze zápůjčky nebo úvěru (jednoduchý, roční sazba, konvence dní) a úrok z dlužného výživného (2,5 promile denně u nezletilého dítěte od 1. 1. 2026). Více pohledávek a částečných plateb s datem připsání: den platby se do prodlení počítá (R 79/2010), platby se započítají podle § 1932 a 1933 občanského zákoníku (spotřebitel v prodlení nejdřív jistina, u smluv od 1. 7. 2021). Mezi podnikateli paušál 1 200 Kč za pohledávku. Upozorní na § 1805 odst. 2 (úroky ve výši jistiny, jen u závazku vzniklého od 1. 1. 2014) a na dobré mravy; je-li sjednaný úrok z prodlení víc než 4× vyšší než zákonný a zároveň vyšší než 36,5 % ročně, dá zásadní upozornění (§ 580 a 588 občanského zákoníku, signál podle NS 32 Cdo 1490/2019, ne závěr o neplatnosti) a zákonnou variantu uvede přímo v hlavním výsledku. Sazbu ČNB, kterou nezná, nenahrazuje: výsledek pak neobsahuje číslo. EN: Calculates Czech interest with a period-by-period breakdown: statutory default interest in every regime since 1994, agreed default interest, contractual loan interest and interest on unpaid maintenance; several claims and dated part payments allocated under Sections 1932 and 1933 of the Civil Code; the CZK 1,200 flat fee between businesses.

Input Schema

NameRequiredDescriptionDefault
druhNoCo počítat: zakonny = Zákonný úrok z prodlení (Dlužník platí pozdě a výše úroku není ve smlouvě.); smluvni_prodleni = Sjednaný úrok z prodlení (Smlouva určuje vlastní sazbu, třeba 0,05 % denně.); kapitalovy = Úrok ze zápůjčky nebo úvěru (Sjednaná odměna za půjčené peníze, ne sankce za prodlení.); vyzivne = Úrok z dlužného výživného (U nezletilého dítěte od roku 2026 prvních šest měsíců 2,5 promile denně.). Bez zadání zakonny. EN: What to calculate.
komuNoJen u druh=vyzivne: nezletile = nezletilé dítě (zvýšený úrok 2,5 promile denně prvních šest měsíců u prodlení od 1. 1. 2026), jine = zletilé dítě nebo manžel. Bez zadání nezletile. EN: Maintenance: minor child or other.
sazbaNoJen u druh=smluvni_prodleni a kapitalovy: sjednaná sazba (číslo, jednotka podle pole jednotka). EN: Agreed rate.
vztahNoKdo komu dluží: b2b = Podnikatel podnikateli (U zboží a služeb paušál 1 200 Kč za každou pohledávku.); b2c = Podnikatel spotřebiteli (Dlužník je spotřebitel. Platba jde nejdřív na jistinu.); c2c = Člověk člověku (Třeba půjčka mezi známými. Dlužník tu spotřebitelem není.); verejny_zadavatel = Podnikatel veřejnému zadavateli (Dodávka zboží nebo služby státu, obci nebo jiné veřejné instituci.). Rozhoduje o paušálu 1 200 Kč a o pořadí započtení plateb. Bez zadání b2b; u výživného se nepoužije. EN: Relationship between creditor and debtor.
ke_dniNoDen, ke kterému se úrok počítá (včetně), RRRR-MM-DD. Bez zadání dnešek (Praha). EN: Reference date YYYY-MM-DD; defaults to today (Prague).
platbyNoČástečné platby. Rozhodný je den připsání na účet věřitele (§ 1957). EN: Part payments.
delitelNoKonvence dní: 365 = Skutečné dny / 365 (Bez ujednání ve smlouvě.); skutecny = Skutečné dny / skutečné dny v roce (V přestupném roce dělí 366.); ACT/360 = Skutečné dny / 360 (Jen když to smlouva výslovně určuje.); 30E/360 = 30/360 (evropská) (Každý měsíc 30 dní, rok 360. Jen podle smlouvy.). Bez zadání 365. ACT/360 a 30E/360 jen u kapitalovy. EN: Day-count convention.
predmetNoJen mezi podnikateli: zbozi_sluzba = dodávka zboží nebo služby za úplatu (paušál 1 200 Kč náleží), jine = zápůjčka nebo jiné plnění (paušál ne). Bez zadání zbozi_sluzba. EN: Between businesses: goods or services, or other.
jednotkaNoJednotka sjednané sazby: procent_rocne = % ročně, procent_denne = % denně, promile_denne = ‰ denně. Bez zadání procent_rocne; u kapitalovy jen procent_rocne (§ 1803 občanského zákoníku). EN: Unit of the agreed rate.
pohledavkyYesPohledávky (faktury, dávky výživného, zápůjčky), každá zvlášť. EN: Claims, each separately.
obvykla_sazbaNoJen u kapitalovy, nepovinné: obvyklá sazba v % ročně (statistika ČNB) pro srovnání se sjednanou, nejvýše 100. EN: Usual market rate for comparison.
uroky_z_urokuNoÚroky z úroků jsou sjednané (§ 1806). Nástroj je nepočítá, jen upozorní, že výsledek je spodní hranicí. EN: Interest on interest was agreed.
pausal_uplatnenNoDen, kdy věřitel uplatnil paušál 1 200 Kč. Od něj ho nástroj bere jako náklad již určený a platby jdou nejdřív na něj. EN: Date the flat fee was claimed.
uver_fyzicke_osobeNoSpotřebitelský úvěr nebo zápůjčka či úvěr, kde je dlužníkem fyzická osoba (§ 122 zákona o spotřebitelském úvěru): úrok z prodlení nejvýš v zákonné výši. EN: Consumer credit or loan to an individual (cap under Section 122).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / pohledavky / items / properties / datum_smlouvy / description
      Previous value: -"Den uzavření smlouvy, RRRR-MM-DD. Rozhoduje o znění § 1932 (před 1. 7. 2021 staré, i u spotřebitele nejdřív úroky). U spotřebitele bez data se bere nové znění. EN: Contract date."New value: +"Den uzavření smlouvy, RRRR-MM-DD. Rozhoduje o znění § 1932 (před 1. 7. 2021 staré, i u spotřebitele nejdřív úroky); u spotřebitele bez data se bere nové znění. Smlouva před 1. 1. 2014 se řídí dřívějšími předpisy, a proto u ní nástroj neuplatní pravidlo § 1805 odst. 2 o úrocích ve výši jistiny. EN: Contract date."
  2. Changed5 schema fields changed
    • changedInput schema / properties / obvykla_sazba / description
      Previous value: -"Jen u kapitalovy, nepovinné: obvyklá sazba v % ročně (statistika ČNB) pro srovnání se sjednanou. EN: Usual market rate for comparison."New value: +"Jen u kapitalovy, nepovinné: obvyklá sazba v % ročně (statistika ČNB) pro srovnání se sjednanou, nejvýše 100. EN: Usual market rate for comparison."
    • addedInput schema / properties / obvykla_sazba / maximum
      Added value: +100
    • addedInput schema / properties / platby / items / properties / castka / maximum
      Added value: +100000000000
    • changedInput schema / properties / pohledavky / items / properties / castka / description
      Previous value: -"Částka (jistina) v Kč. EN: Principal in CZK."New value: +"Částka (jistina) v Kč, nejvýše 100 miliard. EN: Principal in CZK."
    • addedInput schema / properties / pohledavky / items / properties / castka / maximum
      Added value: +100000000000
  3. Added

TDQS

A4.2/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnly, idempotent, non-destructive), so the description must carry behavioral disclosure – and it does: it warns it will NOT substitute an unknown ČNB rate (result then contains no number), refuses to compute interest on interest, flags § 1805/§ 580/§ 588 signals without concluding invalidity, and applies the § 1932/1933 payment ordering. These are material behaviors 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded, but the body is an extremely dense single run-on sentence packed with statutory citations and parentheticals, which makes it hard to scan. Given the domain complexity some length is warranted, but it is far from tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter, output-schema-less legal calculator the description is remarkably complete: it explains the regimes, the flat fee, the payment-allocation rules, and even what the tool will and won't output. It stops short of describing return structure (no output schema exists), keeping it from a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema itself documents every field including enums and date patterns, so the description's parameter discussion largely restates legal background rather than adding invocation syntax. Baseline 3 is appropriate 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource ("Spočítá úroky podle českého práva s rozpisem po úsecích") and enumerates the exact interest regimes it handles, so an agent can immediately tell it apart from the other legal-calculator siblings (odmena_advokata, danove_sankce, etc.). The scope is concrete and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives rich context for when each mode applies (statutory vs agreed default interest, contractual loan interest, maintenance interest, B2B flat fee), effectively telling the agent which regime maps to which situation. However, it never states exclusions or explicitly routes to any alternative tool, so it falls short of a full when/when-not statement.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources