Skip to main content
Glama
Sign In

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

by cz.iustoria
OverviewDiscussionsAdmin

Účetní jednotka: kategorie, audit a sbírka listin

ucetni_jednotka
Read-onlyIdempotent

Určí kategorii účetní jednotky (mikro, malá, střední, velká) podle hraničních hodnot § 1b zákona o účetnictví (nepřekročení aspoň 2 ze 3 hodnot k rozvahovému dni, roční úhrn obratu přepočtený podle počtu měsíců): pro účetní období započatá od 1. 1. 2024 a skončená od 31. 12. 2024 ve znění zákona č. 316/2025 Sb., pro období započatá od 1. 1. 2016 a pro období započatá v roce 2024 a skončená dřív ve znění zákona č. 221/2015 Sb. (u druhých nabídne i nové hodnoty). Dále povinný audit (od období započatých 1. 1. 2026 jen střední a velké; za dřívější období podle dřívějšího § 20, u malé jednotky dosahující hodnot podle právní formy a hodnot předchozího období, jsou-li zadány, jinak nutno posoudit), lhůtu pro uložení závěrky do sbírky listin (12 měsíců od rozvahového dne), zda se zveřejňuje výkaz zisku a ztráty, sankce a konec doby archivace (10 a 5 let). Období započatá před rokem 2016 nepočítá. Pro obchodní společnosti a družstva. EN: Determines the Czech accounting entity category (micro, small, medium, large) under the 2026 thresholds, or the 2016 thresholds for periods started 2016–2023, the statutory audit duty, the deadline to file financial statements in the Collection of Documents, penalties and record retention.

Input Schema

NameRequiredDescriptionDefault
obratYesČistý obrat za účetní období v Kč. EN: Net turnover for the period in CZK.
aktivaYesAktiva celkem k rozvahovému dni v Kč. EN: Total assets in CZK.
mesicuNoDélka účetního období v započatých měsících. Bez zadání 12. EN: Length of the accounting period in months.
zamestnanciYesPrůměrný přepočtený počet zaměstnanců v účetním období. EN: Average number of employees.
pravni_formaNoJen pro audit za účetní období započatá před 1. 1. 2026 (dřívější § 20 odst. 1): as = akciová společnost, sverensky_fond = svěřenský fond (malé stačí dosáhnout 1 hodnoty), jina = s. r. o., družstvo a jiné (2 hodnoty). EN: Legal form, for the audit duty in periods started before 2026.
rozvahovy_denYesRozvahový den (poslední den účetního období, zpravidla poslední den měsíce), RRRR-MM-DD; účetní období započaté od 1. 1. 2016, rozvahový den nejpozději 31. 12. 2030. EN: Balance sheet date.
predchozi_obdobiNoJen pro audit za účetní období započatá před 1. 1. 2026: hodnoty k rozvahovému dni bezprostředně předcházejícího účetního období (dřívější § 20 odst. 1 je vyžaduje k oběma rozvahovým dnům). EN: Values at the previous balance sheet date, for the audit duty in periods started before 2026.
subjekt_verejneho_zajmuNoSubjekt veřejného zájmu (vždy velká účetní jednotka). EN: Public-interest entity.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / pravni_forma
      Added value: +{
+  "description": "Jen pro audit za účetní období započatá před 1. 1. 2026 (dřívější § 20 odst. 1): as = akciová společnost, sverensky_fond = svěřenský fond (malé stačí dosáhnout 1 hodnoty), jina = s. r. o., družstvo a jiné (2 hodnoty). EN: Legal form, for the audit duty in periods started before 2026.",
+  "enum": [
+    "as",
+    "sverensky_fond",
+    "jina"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / predchozi_obdobi
      Added value: +{
+  "additionalProperties": false,
+  "description": "Jen pro audit za účetní období započatá před 1. 1. 2026: hodnoty k rozvahovému dni bezprostředně předcházejícího účetního období (dřívější § 20 odst. 1 je vyžaduje k oběma rozvahovým dnům). EN: Values at the previous balance sheet date, for the audit duty in periods started before 2026.",
+  "properties": {
+    "aktiva": {
+      "description": "Aktiva celkem k předchozímu rozvahovému dni v Kč.",
+      "maximum": 1000000000000,
+      "minimum": 0,
+      "type": "number"
+    },
+    "obrat": {
+      "description": "Roční úhrn čistého obratu za předchozí účetní období v Kč (u období jiné délky než 12 měsíců přepočtený na rok).",
+      "maximum": 1000000000000,
+      "minimum": 0,
+      "type": "number"
+    },
+    "zamestnanci": {
+      "description": "Průměrný přepočtený počet zaměstnanců v předchozím účetním období.",
+      "maximum": 1000000,
+      "minimum": 0,
+      "type": "number"
+    }
+  },
+  "type": "object"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / rozvahovy_den / description
      Previous value: -"Rozvahový den (poslední den účetního období, zpravidla poslední den měsíce), RRRR-MM-DD; nejpozději 31. 12. 2030. EN: Balance sheet date."New value: +"Rozvahový den (poslední den účetního období, zpravidla poslední den měsíce), RRRR-MM-DD; účetní období započaté od 1. 1. 2016, rozvahový den nejpozději 31. 12. 2030. EN: Balance sheet date."
  3. Changed1 schema field changed
    • changedInput schema / properties / rozvahovy_den / description
      Previous value: -"Rozvahový den (poslední den účetního období), RRRR-MM-DD. EN: Balance sheet date."New value: +"Rozvahový den (poslední den účetního období, zpravidla poslední den měsíce), RRRR-MM-DD; nejpozději 31. 12. 2030. EN: Balance sheet date."
  4. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds substantial behavioral context beyond that: which legal regime applies by period, that pre-2016 periods are unsupported, and which secondary outputs (audit, deadline, retention) are produced.

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 and every clause references a concrete legal rule, but the Czech body is extremely dense with nested conditions, and the appended English recap partially duplicates it. Structure is serviceable rather than clean, and an agent must parse heavy legal prose.

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 statutory calculator with 8 parameters, a nested object and no output schema, the description covers the computation rules, the applicable law by period, exclusions and the set of derived results. It is close to complete, though the precise output shape must be inferred.

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 all 8 parameters, giving a baseline of 3. The description adds some interpretive context (turnover recalculated by month count, previous-period values needed for the old § 20 audit test) but does not restate parameter formats or units beyond what the schema provides.

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?

Specifies a precise verb+resource: determines the Czech accounting entity category, audit duty, filing deadline, penalties and retention period. It is clearly distinguishable from siblings like lhuta, danove_sankce, or danovy_kalendar, and even names the legal basis (§ 1b) that defines the computation.

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?

States the applicable scope (obchodní společnosti a družstva) and an explicit exclusion ('Období započatá před rokem 2016 nepočítá'), and routes periods to the correct legal version. It does not name a sibling alternative, but the domain is narrow enough that implied usage is unambiguous.

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