Skip to main content
Glama

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

by cz.iustoria
OverviewDiscussionsAdmin

DPP a DPČ: limity, pojištění a daň

dpp_dpc
Read-onlyIdempotent

U dohody o provedení práce (DPP) a dohody o pracovní činnosti (DPČ) zkontroluje limity rozsahu (DPP nejvýš 300 hodin v roce u téhož zaměstnavatele, § 75; DPČ v průměru nejvýš polovina stanovené týdenní doby, § 76), odměnu proti hodinové minimální mzdě a doplatek (§ 111), určí účast na nemocenském a důchodovém pojištění (2026: DPP od 12 000 Kč za měsíc, DPČ od 4 500 Kč), pojistné zaměstnance (u pracujícího poživatele starobního důchodu po slevě 6,5 %, § 7d a 7e zákona č. 589/1992 Sb.), daňový režim (2026: bez prohlášení pod hranicí 15% srážková daň; od výplat 1. 1. 2027 bez prohlášení pod hranicí záloha ze samostatného základu, srážková daň končí; s prohlášením záloha se slevou 2 570 Kč) a orientačně čistou odměnu. Pro výplaty v roce 2027 dopočítá z nařízení vlády č. 177/2026 Sb. (průměrná mzda 51 663 Kč) hranici účasti u DPP 12 500 Kč (25 % průměrné mzdy dolů na pětisetkoruny, § 7a odst. 1 zákona o nemocenském pojištění) i rozhodný příjem DPČ 5 000 Kč (§ 6 odst. 2) a řekne, že jde o výpočet před oficiálním vyhlášením. Pod minimální mzdou upozorní na doplatek zdravotního pojištění do minimálního vyměřovacího základu (§ 3 odst. 10 zákona č. 592/1992 Sb.); při doplatku do minimální mzdy uvede i čistou odměnu s ním. EN: For Czech agreements to complete a job (DPP) or to perform work (DPČ): checks hour limits and the minimum wage, determines social insurance participation (2026: DPP from CZK 12,000 a month, DPČ from CZK 4,500; for 2027 both thresholds are derived from Government Decree No. 177/2026 Coll. before the official announcement: DPP CZK 12,500, DPČ CZK 5,000), employee contributions and the tax regime for 2026 and 2027, with an indicative net pay.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typYesdpp = dohoda o provedení práce, dpc = dohoda o pracovní činnosti. EN: DPP or DPČ.
rok_vyplatyNoRok, ve kterém se odměna vyplácí (rozhoduje o daňovém režimu). Bez zadání letošní. Ověřené: 2026, 2027 (hranice pojištění dopočtené z nařízení vlády č. 177/2026 Sb.). EN: Year of payment.
hodin_v_roceNoJen DPP: hodiny ze všech DPP u téhož zaměstnavatele za kalendářní rok (limit 300). EN: DPP hours in the year.
hodin_v_mesiciNoOdpracované hodiny v měsíci (kontrola minimální mzdy). EN: Hours worked in the month.
odmena_mesicneYesOdměna zúčtovaná za kalendářní měsíc v Kč; při více dohodách téhož druhu u téhož zaměstnavatele jejich součet. EN: Monthly pay in CZK.
prohlaseni_k_daniNoZaměstnanec podepsal u tohoto zaměstnavatele prohlášení poplatníka daně (sleva na poplatníka). EN: Tax declaration signed.
starobni_duchodceNoZaměstnanec pobírá po celý měsíc starobní důchod v plné výši a dosáhl důchodového věku: sleva na pojistném na důchodové pojištění 6,5 % z vyměřovacího základu (§ 7d a 7e zákona č. 589/1992 Sb.), uplatňuje se u zaměstnavatele. EN: Employee draws a full old-age pension (6.5 % contribution discount).
hodin_tydne_prumerNoJen DPČ: průměrný týdenní rozsah za dobu dohody, nejdéle 52 týdnů (limit polovina stanovené týdenní doby). EN: DPČ average weekly hours.
stanovena_tydenni_dobaNoJen DPČ: stanovená týdenní pracovní doba u zaměstnavatele. Bez zadání 40. EN: Statutory weekly hours.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / rok_vyplaty / description
      Previous value: -"Rok, ve kterém se odměna vyplácí (rozhoduje o daňovém režimu). Bez zadání letošní. Ověřené: 2026, 2027 (u DPP bez hranice pojištění). EN: Year of payment."New value: +"Rok, ve kterém se odměna vyplácí (rozhoduje o daňovém režimu). Bez zadání letošní. Ověřené: 2026, 2027 (hranice pojištění dopočtené z nařízení vlády č. 177/2026 Sb.). EN: Year of payment."
  2. Changed2 schema fields changed
    • changedInput schema / properties / rok_vyplaty / description
      Previous value: -"Rok, ve kterém se odměna vyplácí (rozhoduje o daňovém režimu). Bez zadání letošní. Ověřené: 2026, 2027 (bez hranice pojištění). EN: Year of payment."New value: +"Rok, ve kterém se odměna vyplácí (rozhoduje o daňovém režimu). Bez zadání letošní. Ověřené: 2026, 2027 (u DPP bez hranice pojištění). EN: Year of payment."
    • addedInput schema / properties / starobni_duchodce
      Added value: +{
+  "description": "Zaměstnanec pobírá po celý měsíc starobní důchod v plné výši a dosáhl důchodového věku: sleva na pojistném na důchodové pojištění 6,5 % z vyměřovacího základu (§ 7d a 7e zákona č. 589/1992 Sb.), uplatňuje se u zaměstnavatele. EN: Employee draws a full old-age pension (6.5 % contribution discount).",
+  "type": "boolean"
+}
  3. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare the safe read-only, idempotent, closed-world profile, so the description is not needed to establish safety. It does add valuable behavioral context beyond that: the 2026 vs 2027 tax-regime switch, the derived 2027 thresholds, the pensioner contribution discount, and the explicit caveat that 2027 figures are computed before official announcement. It does not describe the returned result shape, which matters slightly given 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.

Conciseness3/5

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

The purpose is front-loaded, but the body is very long and dense, packed with statutory citations and exact figures, and then largely restated in an English paragraph. For a legal-rule calculator much of this earns its place, yet the duplication and citation density push it below an efficient, tightly-structured description.

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 complex, 9-parameter legal calculator the description covers the rule set, year-dependent behavior, and edge cases (health-insurance top-up to the minimum base, minimum-wage shortfall) thoroughly. It never spells out the returned values, and with no output schema that is a minor remaining gap, but nothing essential for correct invocation is missing.

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%, so the schema already documents every parameter with Czech and English glosses. The description restates the same rules (300-hour DPP limit, 2026/2027 thresholds) but adds no syntax or format detail the schema lacks, so the baseline 3 is appropriate.

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 states specific verbs (checks limits, determines insurance participation, computes net pay) applied to a precisely named resource (DPP and DPČ agreements). It enumerates exactly which legal checks it performs (§ 75/76 hour limits, § 111 minimum wage, § 7d/7e insurance, tax regime), making it clearly distinguishable from generic siblings.

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

Usage Guidelines3/5

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

The scope is implied by the described calculations, so an agent can infer this is the tool for DPP/DPČ pay and insurance questions. However, it never explicitly states when to prefer this over close siblings such as minimalni_mzda_a_priplatky, nor does it name any alternative or exclusion. No explicit when-to-use or when-not guidance is given.

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

All IUSTORIA – průvodci a právní kalkulačky toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources