Read-only European tax, salary and benefit calculators with official sources and unknowns.
Scored across 11 tools
Each tool targets a distinct country-plus-topic calculator (e.g. serbia_vat, malta_vacation_leave, greece_unemployment_benefit), so boundaries are unambiguous. The only superficially similar tools (Latvia/Malta/Greece leave and vacation calculators) are cleanly separated by country and purpose.
Nearly all tools follow a predictable country_topic pattern (greece_annual_leave, slovakia_severance_pay, luxembourg_unemployment_benefit). The lone meta tool list_calculators is the only minor deviation from the convention.
11 tools is well within the healthy range, with each tool representing a distinct calculator that earns its place. The list_calculators discovery tool complements rather than bloats the set.
Within each calculator the coverage seems self-contained, and list_calculators aids discovery, but the overall surface spans only a handful of countries and one or two topics each, leaving obvious gaps (e.g. no general income-tax or VAT calculators for most countries). No generic dispatch or update/create operations exist, but they are not really expected for a read-only calculator suite.
Czech taxable benefit for private use of a company car in 2026: 1 %, 0.5 % or 0.25 % of the vehicle's input price including VAT by emission category, and the resulting monthly increase in the income-tax advance and the employee's social and health insurance. Rules year 2026, last updated 2026-09-29. Page: https://kalkulo.eu/cs/kalkulacka-firemni-auto/. Returns result rows (page language), raw engine outputs, sources with lastChecked dates and a disclaimer. Inputs marked "Only used when" are needed only in that case.
| Name | Required | Description | Default |
|---|---|---|---|
| hrubaMzda | Yes | Hrubá měsíční mzda Hrubá mzda bez auta — určuje mezní sazbu daně (15/23 %) a využití stropu pojistného | |
| inputPrice | Yes | Vstupní cena vozidla (vč. DPH) Pořizovací (vstupní) cena auta u zaměstnavatele nebo leasingové společnosti, vždy včetně DPH | |
| emisniKategorie | No | Emisní kategorie vozidla Běžné 1 %, nízkoemisní (do 50 g CO2/km) 0,5 %, bezemisní (elektromobil, vodík) 0,25 % Options: ordinary = Běžné vozidlo (1 %); low = Nízkoemisní vozidlo (0,5 %); zero = Bezemisní vozidlo (0,25 %). Default if omitted: ordinary. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: the rules year and last-updated date, the source page URL, the returned structure (result rows, raw engine outputs, sources with lastChecked dates, disclaimer) and the output language. It stops short of richer disclosure, but for a pure computation tool this is solid.
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 core purpose is front-loaded in the first sentence, with versioning, URL and return-shape details following. The prose is dense but every clause carries information; only the trailing 'Only used when' note is dead weight because no such marker exists in this schema.
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 takes on the burden of describing returns, and it does so (result rows, raw engine outputs, sources with lastChecked dates, disclaimer) as well as naming the year and rules version. Required inputs and the emission-category enum are covered by the schema, so the only residual gap is the mismatched conditional-input note.
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 hrubaMzda, inputPrice and emisniKategorie are already fully documented, including the emission-category enum values and their rates. The description restates the rate-by-emission-category mapping but adds no syntax, format, or dependency detail beyond the schema. The closing note about 'Only used when' inputs references a marker that does not appear in this schema, so it adds no usable parameter meaning here.
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 names a very specific resource — the Czech taxable benefit for private use of a company car for 2026 — and even enumerates the applicable rates (1 %, 0.5 %, 0.25 %) and what the output expresses (monthly increase in tax advance plus social/health insurance). Sibling tools are all different country/benefit calculators, so differentiation is implicit in the country+benefit naming rather than stated. It lacks an explicit verb but is otherwise unmistakable.
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?
No explicit when-to-use, when-not-to-use, or alternative-routing sentence is present; the usage is only implied by the highly specific computation described. Because every sibling is a distinct country/benefit calculator, there is little ambiguity to resolve, but the description still does not tell the agent when this tool is the right pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Statutory redundancy compensation in Estonia: the employer's one month of average wages (Employment Contracts Act § 100(1)), the Unemployment Insurance Fund (Töötukassa) benefit by length of employment, and compensation for missing notice days. Each part is shown separately; the total only when every part is known. Optional net view. Rules year 2026, last updated 2026-09-26. Page: https://kalkulo.eu/et/kalkulaator-koondamishuvitis/. Returns result rows (page language), raw engine outputs, sources with lastChecked dates and a disclaimer. Inputs marked "Only used when" are needed only in that case.
| Name | Required | Description | Default |
|---|---|---|---|
| tooLopp | Yes | Töösuhte viimane päev Töölepingu lõppemise päev. Täpselt 10 aastat annab Töötukassalt 1 kuu, üle 10 aasta 2 kuud. Kui viimane päev langeb 5 või 10 aasta piirile, näitab kalkulaator seda eraldi. Näitväärtus 30.09.2026. Date as YYYY-MM-DD, or "" if unknown. | |
| iiSammas | No | Kogumispensioni (II samba) makse määr Määra näed Pensionikeskuse kontolt. Kui sa ei ole II sambaga liitunud või oled sellest lahkunud, vali 0%. Only used when netoVaade = jah. Options: teadmata = Ei tea; 0 = 0% (ei ole liitunud); 2 = 2%; 4 = 4%; 6 = 6%. Default if omitted: teadmata. | |
| tooAlgus | Yes | Töösuhte algus selle tööandja juures Katkematu töösuhte esimene päev. Näitväärtus 01.09.2014. Date as YYYY-MM-DD, or "" if unknown. | |
| netoVaade | No | Kas näidata ka kättesaadavat summat (neto)? Bruto on vaikimisi. Neto arvutatakse eraldi tööandja ja Töötukassa väljamakse kohta. Kui II samba määr või maksuvaba tulu kasutus on teadmata, näidatakse väikseimat ja suurimat võimalikku summat. Options: ei = Ei, ainult bruto; jah = Jah, näita ka neto. Default if omitted: ei. | |
| keskmiseViis | No | Kuidas tööandja keskmine töötasu on teada? Kui tööandja on keskmise juba arvutanud (näiteks lõpparve kavandis), sisesta see. Muidu saab selle arvutada kuue eelneva kalendrikuu andmetest (määrus nr 91 § 3). Options: summa = Sisestan tööandja arvutatud keskmise; arvuta = Arvutan perioodi töötasust ja tööpäevadest. Default if omitted: summa. | |
| perioodiKuud | No | Perioodi kalendrikuude arv Tavaliselt 6. Kui töötasid selle tööandja juures vähem kui kuus kalendrikuud, loe kuud, mille eest töötasu muutus sissenõutavaks (määrus nr 91 § 2 lg 3). Only used when keskmiseViis = arvuta. | |
| perioodiTasu | No | Perioodi arvesse minev töötasu (bruto) Kuue eelneva kalendrikuu jooksul välja teenitud ja sissenõutavaks muutunud töötasu (määrus nr 91 § 2 lg 2). Kui arvad päevi välja, jäta välja ka nende päevade tasu. Näitväärtus 12 600 €. Only used when keskmiseViis = arvuta. | |
| tooPaevaTasu | No | Keskmine tööpäevatasu (bruto) Tööandja arvestatud keskmine ühe tööpäeva tasu (määrus nr 91 § 3 lg 1). Kuu keskmisest seda ei tuletata, sest jagaja (perioodi kuu keskmine kalendaarsete tööpäevade arv, § 3 lg 6) sõltub perioodist. Kui arvutad keskmise perioodi andmetest, võetakse tööpäevatasu sealt. Only used when lopetamiseAlus = koondamine and etteteatamine = puudulik or teadmata and keskmiseViis = summa. Default if omitted: unknown. | |
| etteteatamine | No | Kas tööandja teatas ülesütlemisest piisavalt ette? Seaduses nõutud aeg: alla 1 tööaasta 15, 1–5 aastat 30, 5–10 aastat 60, 10 ja enam aastat 90 kalendripäeva (TLS § 97 lg 2); kollektiivleping võib ette näha teisiti (§ 97 lg 4). Kui vastad „Ei tea“, näitab kalkulaator vahemikku 0-st kuni summani, mis tuleks siis, kui ette ei teatatud üldse. Only used when lopetamiseAlus = koondamine. Options: teadmata = Ei tea; piisav = Jah, piisavalt; puudulik = Ei, vähem kui nõutud. Default if omitted: teadmata. | |
| maksuvabaJaak | No | Kasutamata maksuvaba tulu sel kuul Summa, mida tööandja saab selle kuu väljamaksel veel maha arvata (kuni 700 €, vanaduspensionieas kuni 776 €). Only used when netoVaade = jah and maksuvabaTooandja = saadaval. Default if omitted: unknown. | |
| lopetamiseAlus | No | Töösuhte lõppemise alus Kalkulaator arvutab koondamise (TLS § 89) ja töötaja ülesütlemise pärast töötasu vähendamist (TLS § 37 lg 5). Muudel juhtudel kehtivad teised reeglid ja summat ei näidata. Options: koondamine = Koondamine tähtajatu lepingu korral (TLS § 89); s37 = Ütlesin lepingu üles töötasu vähendamise tõttu (TLS § 37 lg 5); tahtajaline = Tähtajaline leping lõpetati majanduslikul põhjusel; avalik = Avalik teenistus (ametnik); muu = Muu või vaidlustatud alus. Default if omitted: koondamine. | |
| maksuvabaTkSumma | No | Töötukassa väljamaksel maha arvatav maksuvaba tulu Avalduses märgitud ja sel kuul kasutamata summa, kuni 700 € (vanaduspensionieas kuni 776 €). Kui ei tea, jäta tühjaks: kalkulaator näitab vahemikku 0 kuni 776 €. Only used when netoVaade = jah and maksuvabaTootukassa = jah. Default if omitted: unknown. | |
| tooandjaKeskmine | No | Tööandja arvestatud keskmine kuutöötasu (bruto) Keskmine töötasu määruse nr 91 järgi: tavaliselt kuue eelneva kalendrikuu väljateenitud töötasu põhjal. See ei pruugi võrduda lepingujärgse palgaga. Näitväärtus 2000 €. Only used when keskmiseViis = summa. | |
| maksuvabaTooandja | No | Maksuvaba tulu tööandja väljamaksel Maksuvaba tulu on kuni 700 € kuus (vanaduspensionieas 776 €) ja seda saab kasutada ühe korra kuus. Kui sama kuu töötasu on selle juba ära kasutanud, ei saa seda hüvitiselt uuesti maha arvata. Only used when netoVaade = jah. Options: teadmata = Ei tea; kasutatud = Juba kasutatud või ei rakendata; saadaval = Osa või kõik on veel kasutamata. Default if omitted: teadmata. | |
| perioodiTooPaevad | No | Perioodi kalendaarsed tööpäevad Tööpäevad tööpäevade kalendri järgi (esmaspäevast reedeni, riigipühad välja arvatud), mitte ainult päevad, mil töötasid. Näitväärtus 126. Only used when keskmiseViis = arvuta. | |
| puuduvadTooPaevad | No | Tööpäevad, mille võrra vähem ette teatati Loe tööpäevi, mitte kalendripäevi (TLS § 100 lg 5). Only used when lopetamiseAlus = koondamine and etteteatamine = puudulik. Default if omitted: unknown. | |
| tootukassaKeskmine | Yes | Töötukassa arvutusalus: keskmine kuutöötasu (bruto) Töötukassa arvutab selle ise oma andmetest (viimasele kolmele kuule eelnenud üheksa kuu tasud), seega võib see tööandja keskmisest erineda. Vaja ainult siis, kui staaž on vähemalt 5 aastat. Näitväärtus 2000 €. | |
| valjaArvatudPaevad | No | Välja jäetavad tööpäevad Ainult päevad, mille määrus välja jätab: tööst keeldumine TLS § 19 alusel, töötasu vähendamise päevad TLS § 37 alusel ja haigusleht töötervishoiu ja tööohutuse seaduse § 12^4–12^5 järgi. Tavalist puhkust ega haiguslehte siia ei loeta. Kui selliseid päevi ei olnud, sisesta 0. Only used when keskmiseViis = arvuta. Default if omitted: 0. | |
| etteteatamisTahtaeg | No | Milline etteteatamistähtaeg sinu kohta kehtib? Kollektiivleping võib ette näha seadusest erineva tähtaja (TLS § 97 lg 4). Kui kollektiivlepingut ei ole või see tähtaega ei muuda, vali seadus: tähtaeg leitakse töösuhte kuupäevadest. Vaja ainult vahemiku ülempiiriks. Only used when lopetamiseAlus = koondamine and etteteatamine = teadmata. Options: teadmata = Ei tea; seadus = Seaduse järgi (TLS § 97 lg 2); kollektiivleping = Kollektiivlepingu järgi (sisestan päevad). Default if omitted: teadmata. | |
| maksuvabaTootukassa | No | Maksuvaba tulu Töötukassa väljamaksel Töötukassa arvab maksuvaba tulu maha ainult sinu avalduse alusel. See on kuni 700 € (vanaduspensionieas 776 €) väljamakse kalendrikuu kohta, ka siis, kui hüvitis on 2 kuu eest ja makstakse korraga (TuMS § 42 lg 1). Kui tööandja kasutas samal kuul maksuvaba tulu, jääb Töötukassale ainult kasutamata osa. Only used when netoVaade = jah. Options: teadmata = Ei tea; ei = Ei, Töötukassa maksuvaba tulu ei arvesta; jah = Jah, olen avalduse esitanud. Default if omitted: teadmata. | |
| kollektiivlepinguPaevad | No | Kollektiivlepingu etteteatamistähtaeg (kalendripäevi) Kollektiivlepingus sinu töösuhte kestuse kohta kokku lepitud etteteatamise aeg kalendripäevades. Only used when lopetamiseAlus = koondamine and etteteatamine = teadmata and etteteatamisTahtaeg = kollektiivleping. Default if omitted: unknown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: rules year 2026, a last-updated date, the rule that the total is only shown when every part is known, and the optional net view.
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?
Five compact sentences, front-loaded with what is computed, then the conditional-output rules, then the return shape. Every sentence carries information, though the middle sentence is dense enough that slightly tighter phrasing would help.
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 21-parameter tool with no output schema, the description usefully discloses the return shape (result rows in page language, raw engine outputs, sources with lastChecked dates, a disclaimer) and the total/net output rules. Combined with 100% schema coverage and full annotations, little an agent needs 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 description coverage is 100%, so the baseline is 3 and the schema itself carries the semantics of all 21 parameters. The description's only added parameter insight is the general note that 'Only used when' inputs are conditional, which mirrors what the schema already states per field.
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 names a specific resource (statutory redundancy compensation in Estonia) and enumerates its three component parts: the employer's one month of average wages under § 100(1), the Töötukassa benefit by length of employment, and compensation for missing notice days. Against siblings that are all country/jurisdiction-specific calculators, the scope is unambiguous.
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 is implied by the domain, but the description never states when to prefer this tool over a sibling or when it is inapplicable. The clause about 'Only used when' inputs is parameter-level guidance, not tool-selection guidance, so an agent must infer applicability from the name and title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Statutory annual leave days in Greece for 2026 (5- or 6-day week, with seniority increments) and the gross leave allowance for monthly-salaried employees in at least their third calendar year with the employer. Uncovered cases are reported instead of given a number. Rules year 2026, last updated 2026-09-25. Page: https://kalkulo.eu/el/ypologistis-adeias/. Returns result rows (page language), raw engine outputs, sources with lastChecked dates and a disclaimer. Inputs marked "Only used when" are needed only in that case.
| Name | Required | Description | Default |
|---|---|---|---|
| amoivi | No | Τρόπος αμοιβής Για ημερομίσθιους και ωρομίσθιους το όριο του επιδόματος είναι 13 ημερομίσθια και το ποσό δεν υπολογίζεται εδώ. Options: misthos = Μηνιαίος μισθός; imeromisthio = Ημερομίσθιο ή ωρομίσθιο. Default if omitted: misthos. | |
| etiSynolika | No | Συνολικά έτη υπηρεσίας (όλοι οι εργοδότες, μαζί με τον τρέχοντα) Περιλαμβάνει και τα έτη στον τρέχοντα εργοδότη, οπότε δεν μπορεί να είναι λιγότερα από αυτά. Με 12 έτη η άδεια γίνεται 25 ή 30 ημέρες, με 25 έτη 26 ή 31. Only used when etosProslipsis = 2024_nwritera and proypiresiaAllou = nai. | |
| etiYpiresias | No | Συμπληρωμένα έτη στον τρέχοντα εργοδότη Ακέραια έτη. Η βάση των 20 (πενθήμερο) ή 24 (εξαήμερο) ημερών αυξάνεται κατά μία ημέρα ανά έτος έως 22 ή 26· με 10 έτη στον ίδιο εργοδότη η άδεια γίνεται 25 ή 30 ημέρες. Only used when etosProslipsis = 2024_nwritera. | |
| etosProslipsis | No | Πότε προσληφθήκατε στον τρέχοντα εργοδότη; Κρίνει ποιο ημερολογιακό έτος απασχόλησης είναι το 2026. Στο 1ο και στο 2ο ημερολογιακό έτος η άδεια είναι αναλογική του χρόνου απασχόλησης (άρθρο 221 Π.δ. 62/2025) και ο υπολογιστής δεν τη βγάζει· ολόκληρη η ετήσια άδεια οφείλεται από το 3ο ημερολογιακό έτος. Options: 2024_nwritera = Το 2024 ή νωρίτερα (3ο ή επόμενο ημερολογιακό έτος); 2025 = Το 2025 (2ο ημερολογιακό έτος); 2026 = Το 2026 (1ο ημερολογιακό έτος). Default if omitted: 2024_nwritera. | |
| imeresEvdomada | No | Σύστημα εβδομαδιαίας εργασίας Πενθήμερο: 20 έως 22 ημέρες (25 ή 26 με αρχαιότητα). Εξαήμερο: 24 έως 26 (30 ή 31). Η εκ περιτροπής απασχόληση έχει δικό της κανόνα και δεν υπολογίζεται εδώ. Options: 5 = 5 ημέρες (πενθήμερο); 6 = 6 ημέρες (εξαήμερο); allo = Εκ περιτροπής ή άλλο σύστημα. Default if omitted: 5. | |
| miniaiosMisthos | No | Τακτικές μηνιαίες μικτές αποδοχές Ο μικτός μηνιαίος μισθός μαζί με τα επιδόματα και τις προσαυξήσεις που καταβάλλονται τακτικά (άρθρο 222 Π.δ. 62/2025). Αν δηλώσετε μόνο τον βασικό μισθό ενώ παίρνετε και τακτικά επιδόματα, το επίδομα αδείας βγαίνει μικρότερο από το πραγματικό. Only used when amoivi = misthos. | |
| proypiresiaAllou | No | Έχετε προϋπηρεσία σε άλλους εργοδότες; Τα όρια των 12 και των 25 ετών μετρούν τη συνολική υπηρεσία σε όλους τους εργοδότες (ΕΓΣΣΕ 2000–01 άρθρο 6, ΕΓΣΣΕ 2008–09 άρθρο 3). Αν δεν τη γνωρίζετε, οι ημέρες εμφανίζονται ως εύρος. Only used when etosProslipsis = 2024_nwritera. Options: ochi = Όχι; nai = Ναι — γνωρίζω τα συνολικά έτη; agnosto = Δεν γνωρίζω. Default if omitted: ochi. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world profile, so the safety surface is covered. The description adds genuinely new behavior: uncovered inputs are reported rather than numerically guessed, rules are pinned to 2026 with a last-updated stamp, and results come back as page-language rows plus raw engine outputs, sources and a disclaimer.
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?
Purpose and scope are front-loaded in the first sentence, with provenance (rules year, last updated, page URL) and return format following. Every sentence carries information, though the trailing 'Inputs marked Only used when' note is somewhat meta and the metadata sentence is borderline padding.
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?
No output schema exists, and the description compensates by describing the return payload (result rows, raw engine outputs, sources with lastChecked dates, disclaimer). Combined with 100% schema coverage across all 7 parameters and annotations covering the safety profile, an agent has what it needs to call 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% with bounds, defaults and enum glosses, so the baseline is 3. The description adds value beyond the schema by flagging that 'Only used when' inputs are conditional and by restating the key gating combination (monthly salary + third calendar year), helping the agent reason about the conditional parameter set.
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 pair with jurisdiction and year: 'Statutory annual leave days in Greece for 2026 ... and the gross leave allowance for monthly-salaried employees in at least their third calendar year'. The scope qualifiers (5-/6-day week, seniority increments, third calendar year) let an agent distinguish it from the close siblings latvia_vacation_pay and malta_vacation_leave 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?
'Uncovered cases are reported instead of given a number' plus the explicit limitation to monthly-salaried employees in their third calendar year tells the agent when the tool will and won't produce a value. It does not, however, route the agent to alternatives for those uncovered cases or name any sibling tool, 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.
Regular DYPA unemployment benefit for common unemployed people in Greece, amounts from 2026-04-01: daily and monthly amount by earnings category, dependant supplement, duration in daily allowances, start date, application deadline and Easter/Christmas bonuses. Other categories (construction, seasonal, seafarers, continuation) are reported as outside scope. Rules year 2026, last updated 2026-09-25. Page: https://kalkulo.eu/el/ypologistis-anergias/. Returns result rows (page language), raw engine outputs, sources with lastChecked dates and a disclaimer. Inputs marked "Only used when" are needed only in that case.
| Name | Required | Description | Default |
|---|---|---|---|
| tekna | No | Προστατευόμενα μέλη (έμμεσα ασφαλισμένα μέσω εσάς) Σύζυγος, παιδιά ή άλλα μέλη που είναι έμμεσα ασφαλισμένα μέσω σας. Κάθε μέλος προσθέτει 10% στο ημερήσιο ποσό της κατηγορίας σας. Default if omitted: 0. | |
| sizygos | No | Αν επιδοτείται και ο/η σύζυγος, ποιος λαμβάνει την προσαύξηση; Για τα ίδια μέλη και την ίδια περίοδο η προσαύξηση δεν δίνεται δύο φορές. Με υπεύθυνη δήλωση επιλέγετε: όλη σε έναν από τους δύο ή μισή στον καθένα. Αγνοείται όταν δεν δηλώνετε μέλη. Options: agnosto = Δεν γνωρίζω; ochi = Ο/Η σύζυγος δεν επιδοτείται ή δεν υπάρχει; olo_emena = Όλη η προσαύξηση σε εμένα; olo_sizygos = Όλη η προσαύξηση στον/στη σύζυγο; moirasma = Μισή στον καθένα (50%). Default if omitted: agnosto. | |
| ilikia49 | No | Έχετε κλείσει τα 49 κατά την υποβολή της αίτησης; Με συμπληρωμένο το 49ο έτος και τουλάχιστον 210 ημέρες στο 14μηνο (ή 350 στη διετία) η διάρκεια γίνεται 12 μήνες. Options: agnosto = Δεν γνωρίζω; nai = Ναι; ochi = Όχι; metaxy = Τα κλείνω μεταξύ αίτησης και έναρξης της επιδότησης. Default if omitted: agnosto. | |
| katigoria | No | Ποια περίπτωση σας αφορά; Ο υπολογιστής καλύπτει την αρχική τακτική επιδότηση κοινών ανέργων. Οι άλλες κατηγορίες έχουν δικούς τους κανόνες και δεν υπολογίζονται εδώ. Options: koinos = Κοινός άνεργος — νέα (αρχική) επιδότηση; pilotiko = Πιλοτικό πρόγραμμα επιδότησης ανεργίας; oikodomos = Οικοδόμος; epoxikos = Εποχικά εργαζόμενος; naftikos = Ναυτικός; synexisi = Συνέχιση προηγούμενης επιδότησης; allo = Άλλη ειδική κατηγορία; agnosto = Δεν είμαι βέβαιος/η. Default if omitted: koinos. | |
| apasxolisi | No | Είδος απασχόλησης Η πλήρης απασχόληση δίνει πάντα το πλήρες ποσό. Στη μερική απασχόληση το ποσό εξαρτάται από τις μέσες μικτές αποδοχές του τελευταίου εξαμήνου. Options: agnosto = Επιλέξτε; plires = Πλήρης απασχόληση; meriki = Μερική απασχόληση. Default if omitted: agnosto. | |
| protiEtisies | No | Έχετε 80 ημέρες ασφάλισης σε καθένα από τα δύο προηγούμενα έτη; Προϋπόθεση της πρώτης επιδότησης, και στη διαδρομή του 14μήνου και στη διαδρομή της διετίας. Only used when protiForaIperigoumena = proti_fora. Options: agnosto = Δεν γνωρίζω; nai = Ναι, τουλάχιστον 80 ημέρες σε κάθε έτος; ochi = Όχι. Default if omitted: agnosto. | |
| imeresDietias | No | Ημέρες ασφάλισης στη διετία (μόνο αν στο 14μηνο έχετε κάτω από 125) Ημέρες στα δύο έτη πριν από τη λήξη της εργασίας, χωρίς τους δύο τελευταίους μήνες. Χρησιμοποιείται μόνο για την εναλλακτική διαδρομή της πρώτης επιδότησης (από 200 ημέρες). Only used when protiForaIperigoumena = proti_fora. Default if omitted: 0. | |
| synolikes4050 | No | Συνολικές ημέρες εργασίας σε όλο τον εργασιακό βίο Με 4.050 ημέρες ή περισσότερες η διάρκεια γίνεται 12 μήνες. Αν δεν το γνωρίζετε, η διάρκεια μένει ανοιχτή όταν αυτό μπορεί να την αλλάξει. Options: agnosto = Δεν γνωρίζω; nai = 4.050 ημέρες ή περισσότερες; ochi = Λιγότερες από 4.050. Default if omitted: agnosto. | |
| mesesApodoches | No | Μέσες μικτές μηνιαίες αποδοχές τελευταίου εξαμήνου Πάνω από 493,08 € → πλήρες ποσό· 246,55–493,08 € → 75%· έως 246,54 € → 50%. Only used when apasxolisi = meriki. Default if omitted: 0. | |
| imeresAsfalisis | Yes | Ημέρες ασφάλισης (τελευταίο 14μηνο) Ημέρες ασφάλισης (ημερομίσθια) στο κρίσιμο 14μηνο πριν από τη λήξη της εργασίας, χωρίς τους δύο τελευταίους μήνες. Ακέραιος αριθμός. | |
| imerominiaLysis | No | Ημερομηνία λήξης ή λύσης της εργασίας Από αυτήν μετράνε η προθεσμία των 60 ημερών και η έναρξη της επιδότησης. Date as YYYY-MM-DD, or "" if unknown. | |
| tetraetiaMetrisi | No | Γνωρίζετε τα ημερήσια επιδόματα που λάβατε στην τετραετία; Το όριο των 400 μετριέται στην τετραετία πριν από την έναρξη της νέας επιδότησης. Αν δεν γνωρίζετε τον αριθμό ή τον μετρήσατε έως σήμερα, η διάρκεια μένει ανοιχτή και δεν υποθέτουμε μηδέν. Only used when protiForaIperigoumena = epanaliptiki. Options: agnosto = Δεν γνωρίζω τον αριθμό; enarxi = Γνωρίζω τον αριθμό για την τετραετία πριν από την έναρξη της νέας επιδότησης; simera = Τον μέτρησα έως σήμερα. Default if omitted: agnosto. | |
| imerominiaAitisis | No | Ημερομηνία αίτησης στη ΔΥΠΑ Αν η αίτηση γίνει μέσα στις πρώτες 7 ημέρες, η επιδότηση ξεκινά την 7η ημέρα· αλλιώς ξεκινά την ημέρα της αίτησης. Date as YYYY-MM-DD, or "" if unknown. | |
| protiForaIperigoumena | No | Πρώτη φορά ή επαναληπτική επιδότηση; Στην επαναληπτική επιδότηση ισχύει όριο 400 ημερησίων επιδομάτων στην τετραετία πριν από την έναρξη της νέας επιδότησης. Options: proti_fora = Πρώτη φορά (επιδοτούμαι για πρώτη φορά); epanaliptiki = Επαναληπτική (έχω ξαναεπιδοτηθεί). Default if omitted: proti_fora. | |
| imeresEpidotisisTetraetias | No | Ημερήσια επιδόματα που λάβατε στην τετραετία πριν από την έναρξη της νέας επιδότησης Ο αριθμός που καταγράφει η ΔΥΠΑ για τα τέσσερα χρόνια πριν από την έναρξη της νέας επιδότησης (25 ημερήσια επιδόματα = ένας πλήρης μήνας). Ακέραιος αριθμός· αν αφήσετε το πεδίο κενό, η διάρκεια μένει ανοιχτή. Only used when protiForaIperigoumena = epanaliptiki and tetraetiaMetrisi = enarxi. Default if omitted: 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safe-read profile (readOnlyHint, idempotentHint, non-destructive, openWorldHint=false), so the bar is lower. The description still adds real value by disclosing the rules year (2026), the last-updated date (2026-09-25), and the returned artifacts (result rows, raw engine outputs, sources with lastChecked dates, disclaimer), which an agent cannot 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?
Purpose and scope are front-loaded, and the paragraph is dense but free of filler. The trailing sentences on return contents, freshness metadata and the page URL are all load-bearing, though the whole block is a single run-on paragraph that could be broken up.
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 15-parameter, single-required-field calculator with no output schema, the description supplies the missing pieces: it enumerates what is returned, states the rule-set year and freshness, and delimits the supported category. Only a minor gap remains around how partial/unknown inputs affect the returned duration, which the schema partially covers.
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% with 15 richly documented parameters including enums, ranges, defaults and cross-parameter conditions, so the schema carries the burden and the baseline is 3. The description's only added meaning is the meta-note that 'Only used when' inputs are conditionally needed, which summarizes gating already stated in each schema field.
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 names the specific benefit (regular DYPA unemployment benefit), the population (common unemployed people in Greece), and the exact outputs it computes (daily/monthly amounts, dependant supplement, duration, deadlines, bonuses). It clearly scopes out construction, seasonal, seafarers and continuation categories. It does not explicitly name a sibling tool, so sibling differentiation rests on the country/benefit naming rather than prose.
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 states which categories are in scope and that other categories are 'outside scope', which is a form of when-not guidance, and it flags that inputs marked 'Only used when' are conditionally required. However, it never routes the agent to an alternative tool for the excluded categories, so usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latvian vacation pay for 2026, gross and net: average daily earnings times vacation days, less employee social insurance (VSAOI 10.5 %) and personal income tax with the €550 monthly non-taxable minimum. Rules year 2026, last updated 2026-09-29. Page: https://kalkulo.eu/lv/atvalinajuma-nauda/. Returns result rows (page language), raw engine outputs, sources with lastChecked dates and a disclaimer. Inputs marked "Only used when" are needed only in that case.
| Name | Required | Description | Default |
|---|---|---|---|
| menesaAlga | Yes | Mēneša bruto alga Mēneša bruto alga (pirms nodokļiem). No tās atvasina vidējo dienas izpeļņu, dalot ar vidēji 21 darba dienu mēnesī. Izmanto šo VAI sešu mēnešu kopsummu zemāk. | |
| sesuMenesuAlga | No | Pēdējo 6 mēnešu darba samaksas kopsumma (neobligāti) Ja zināma, ievadi pēdējo 6 mēnešu kopējo bruto darba samaksu (alga + piemaksas + prēmijas). To dala ar 126 darba dienām, lai iegūtu precīzāku vidējo dienas izpeļņu. Ja aizpildīts, šis lauks aizstāj mēneša algu. Default if omitted: 0. | |
| nostradatasDienas | No | Faktiski nostrādātās darba dienas pēdējos 6 mēnešos Vidējo dienas izpeļņu rēķina no faktiski nostrādātajām dienām (Darba likuma 75. panta 4. un 8. daļa). 0 = pieņem 126 dienas. Piemēram, 9 000 € par 120 dienām un 10 atvaļinājuma dienas → 750 €. Default if omitted: 0. | |
| atvalinajumaDienas | Yes | Atvaļinājuma darba dienas Darba dienu skaits, par kurām aprēķina atvaļinājuma naudu (parasti tikai darba dienas, ne brīvdienas vai svētku dienas). Minimālais ikgadējais atvaļinājums ir 4 nedēļas = 20 darba dienas. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety and determinism (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real value beyond that: the return payload shape (result rows in page language, raw engine outputs, sources with lastChecked dates, disclaimer), the governing rules year, a last-updated date, and the source page.
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 formula and scope are front-loaded in the opening sentence, and the tax/return details are packed efficiently without filler. The dangling 'Inputs marked "Only used when"' sentence does not earn its place given no such marking exists in the schema.
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 steps up to explain the return payload and disclaimer, and the 100%-covered input schema handles the parameters. The rules year, currency context (implied EUR), and freshness date are covered, leaving little an agent would need that 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 description coverage is 100%, so the schema itself documents each parameter in detail, including the 6-month aggregate alternative and the default handling for nostradatasDienas. The description contributes only the vague 'Only used when' note, which adds little beyond the structured field descriptions – 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 resource (Latvian vacation pay) and year (2026), and spells out the computation: average daily earnings times vacation days less VSAOI 10.5% and PIT with a €550 non-taxable minimum. An agent can immediately distinguish this from the sibling country/benefit calculators such as greece_annual_leave or estonia_redundancy_compensation.
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 country and benefit scope, but there is no explicit when-to-use guidance or named alternative. The trailing note about 'Inputs marked "Only used when"' implies conditional-input guidance, yet no such marking appears in the schema, leaving the instruction dangling and unactionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the Kalkulo.eu calculators available as tools here, with country, rules year, last update, page URL and the tool name to call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds useful return-field context (country, rules year, last update, page URL, tool name) since no output schema exists, but does not describe ordering, pagination, or freshness 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 front-loaded sentence with zero wasted words. It starts with the verb 'Lists' and then enumerates the returned fields efficiently.
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 zero-parameter, read-only listing tool whose annotations already cover safety, the description is complete: it says what the tool does and enumerates the return fields in the absence of an output schema. Nothing needed to call it correctly 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?
The tool takes zero parameters, so the baseline is 4. The description correctly adds no parameter details because none are needed, and the empty schema is self-explanatory.
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 (Lists) and resource (Kalkulo.eu calculators) and clarifies scope by saying 'available as tools here,' which distinguishes it from the sibling calculator tools that each perform a specific calculation.
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 provides clear context for use: it lists calculators along with the 'tool name to call,' which implies this is the discovery entry point for the sibling tools. However, it does not explicitly state when to use this versus calling a known calculator directly, and it names no alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Luxembourg full unemployment benefit (ADEM) with 2026 parameters: 80 % of the average gross salary of the last three months (85 % with a dependent child), capped by multiples of the unskilled social minimum wage that step down over the benefit period. Rules year 2026, last updated 2026-09-05. Page: https://kalkulo.eu/lu/calcul-chomage/. Returns result rows (page language), raw engine outputs, sources with lastChecked dates and a disclaimer. Inputs marked "Only used when" are needed only in that case.
| Name | Required | Description | Default |
|---|---|---|---|
| enfantACharge | No | Enfant à charge Bénéficiez-vous de la modération d'impôt pour un ou plusieurs enfants ? (taux porté à 85 %) Options: non = Non (taux 80 %); oui = Oui (taux 85 %). Default if omitted: non. | |
| salaireBrutMoyen | Yes | Salaire brut moyen (3 derniers mois) Moyenne mensuelle du salaire brut des 3 mois précédant le chômage, hors 13e mois éventuel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: it returns result rows in the page language, raw engine outputs, sources with lastChecked dates, and a disclaimer, plus the rules year (2026) and last-updated date, which signals data staleness risk.
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 core calculation is front-loaded in one dense but readable sentence, followed by compact metadata (rules year, last updated, page URL, return shape). The nested cap clause ('multiples of the unskilled social minimum wage that step down over the benefit period') is slightly run-on, but there is little waste overall.
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 two-parameter calculation tool with no output schema, the description covers the formula, the rules vintage, and the return shape (result rows, raw engine outputs, sources, disclaimer). What is missing is any eligibility/prerequisite context or guidance on interpreting the raw engine outputs, but the essentials for correct invocation are present.
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 two parameters (salaireBrutMoyen and the enfantACharge enum with its default) are already fully documented. The description only reinforces the 85% linkage for a dependent child, which the enum description already states, and its one parameter-related sentence is generic boilerplate. 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?
The description states precisely what is computed (Luxembourg ADEM full unemployment benefit with 2026 rules) and even summarizes the algorithm: 80% of the average gross salary of the last three months, 85% with a dependent child, capped by stepped multiples of the unskilled social minimum wage. The country and ADEM scope effectively separate it from siblings like greece_unemployment_benefit, though no sibling is named 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?
There is no guidance on when to use this tool versus the other country calculators, no stated prerequisites (e.g. eligibility conditions, employment history), and no exclusions. The only usage-adjacent sentence ('Inputs marked "Only used when" are needed only in that case') is generic boilerplate that does not correspond to any 'Only used when' marking in the actual schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Statutory vacation leave in Malta for 2026 in hours: the 192-hour base plus 24 hours for the three 2026 public holidays that fall on a weekend, pro-rated for part-time hours and a partial year of service, less leave already taken. Rules year 2026, last updated 2026-09-29. Page: https://kalkulo.eu/mt/vacation-leave-calculator/. Returns result rows (page language), raw engine outputs, sources with lastChecked dates and a disclaimer. Inputs marked "Only used when" are needed only in that case.
| Name | Required | Description | Default |
|---|---|---|---|
| weeklyHours | Yes | Weekly hours worked Average normal weekly hours. Full-time in Malta is 40 hours/week. Part-time and reduced-hours staff are pro-rated against 40. | |
| monthsWorked | Yes | Months worked in 2026 Number of months employed during the year. Used to pro-rate entitlement for a partial year (e.g. new starters or leavers). | |
| leaveTakenHours | No | Leave already taken Vacation leave hours already used so far this year. Subtracted from the entitlement to show your remaining balance. Default if omitted: 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower; the description still adds real context by disclosing the rules year, last-updated stamp, and that results include engine outputs, sources with lastChecked dates and a disclaimer. It stops short of describing pagination or row limits, but for a pure calculator this is solid.
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 calculation formula and unit, followed by versioning and return-shape notes; no sentence is pure filler. The trailing 'Inputs marked "Only used when"...' line is meta-commentary that doesn't map to anything in the schema and could be dropped.
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 three-parameter calculator with no output schema, the description does necessary work: it explains the return payload composition and the rules vintage the agent is relying on. Combined with 100% schema coverage, an agent has enough to invoke it correctly; only cross-tool routing guidance 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 description coverage is 100%, so the schema already explains weeklyHours, monthsWorked and leaveTakenHours thoroughly; the description adds only the pro-rating intent, which the schema also states. The sentence about inputs 'marked "Only used when"' refers to markers that do not appear in the provided schema, which is mildly confusing rather than additive.
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 resource ('Statutory vacation leave in Malta for 2026'), a concrete unit (hours), and even the composition of the figure (192-hour base plus 24 weekend-holiday hours, pro-rated). This clearly separates it from sibling country/benefit calculators without needing the 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?
Usage is implied by the country-and-benefit scoping of the name, but the description never states when to reach for this versus another calculator (e.g. greece_annual_leave, latvia_vacation_pay) or any precondition such as 'for 2026 employment only'. Nothing misleads, but the agent must infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Serbian VAT in both directions: add VAT to a net amount or extract VAT from a gross amount, at the 20 % general or 10 % special rate (Article 23 of the VAT Law). Rules year 2026, last updated 2026-09-29. Page: https://kalkulo.eu/sr/kalkulator-pdv/. Returns result rows (page language), raw engine outputs, sources with lastChecked dates and a disclaimer. Inputs marked "Only used when" are needed only in that case.
| Name | Required | Description | Default |
|---|---|---|---|
| smer | No | Smer obračuna „Dodaj PDV na osnovicu" računa od neto osnovice (bez PDV-a → sa PDV-om). „Izdvoji PDV iz bruto iznosa" izdvaja osnovicu i PDV iz iznosa sa PDV-om. Options: na_osnovicu = Dodaj PDV na osnovicu; iz_bruto = Izdvoji PDV iz bruto iznosa. Default if omitted: na_osnovicu. | |
| iznos | Yes | Iznos (RSD) Kod opcije „Dodaj PDV na osnovicu" iznos je osnovica (bez PDV-a). Kod opcije „Izdvoji PDV iz bruto iznosa" iznos je ukupno (sa PDV-om). | |
| stopa | No | Stopa PDV-a Opšta (standardna) stopa 20% primenjuje se na većinu dobara i usluga. Posebna (snižena) stopa 10% važi za listu iz člana 23. Zakona o PDV (osnovne životne namirnice, lekovi, knjige, komunalne usluge, smeštaj i dr.). Options: 20 = Opšta stopa (20%); 10 = Posebna stopa (10%). Default if omitted: 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds valuable non-structured context: the return payload (result rows in page language, raw engine outputs, sources with lastChecked dates, a disclaimer) and the rules vintage (2026, last updated 2026-09-29).
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?
Compact and front-loaded: purpose first, then rate/legal frame, then returns, then freshness. The trailing sentence about inputs marked 'Only used when' dangles — no such marker appears in this schema — so it costs a little clarity for no benefit.
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 usefully discloses what comes back and that results are page-language, source-attributed, and dated, which is enough for an agent to call a stateless calculator correctly. Missing only error/edge behavior (e.g., what happens at the 1e9 maximum or a zero net amount).
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 both enums (smer, stopa) are fully documented with defaults in the schema, so the baseline is 3. The description's VAT-direction and rate language merely mirrors what the schema already says, adding no new syntax, bounds, or edge-case meaning.
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 and resource ('Serbian VAT in both directions: add VAT to a net amount or extract VAT from a gross amount') plus the applicable rates and legal basis (Article 23). An agent can distinguish it immediately from the company-car, leave, and benefit calculators in the sibling set.
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 gives clear context for both operating modes and the schema elaborates on which direction applies to which input meaning. However, it names no alternatives or exclusions, and no sibling is a genuine substitute, so the routing guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Slovak personal income tax on property rental income for 2026 under § 6(3) of the Income Tax Act: the €500 exemption, proportional expenses, tax base, tax across the 19/25/30/35 % bands, and whether a tax return is required. No tax amount is given while other income or expense verification is unknown. Rules year 2026, last updated 2026-09-25. Page: https://kalkulo.eu/sk/kalkulacka-prijem-z-prenajmu/. Returns result rows (page language), raw engine outputs, sources with lastChecked dates and a disclaimer. Inputs marked "Only used when" are needed only in that case.
| Name | Required | Description | Default |
|---|---|---|---|
| odpisy | No | Z toho odpisy a iné nepeňažné výdavky (€) Časť výdavkov, ktorú ste v hotovosti nezaplatili (napr. odpisy). Znižuje základ dane, ale nie vašu hotovosť. Only used when vydavkyRezim = suhrn. Default if omitted: 0. | |
| podiel | No | Váš podiel na príjmoch (%) Pri BSM dohodnutý pomer, bez dohody 50 %. Pri spoluvlastníctve váš spoluvlastnícky podiel, ak zákon alebo dohoda neurčuje iný. Kalkulačka pomer nevyberá za vás. Only used when vlastnictvo = bsm or spoluvlastnictvo. | |
| prijem | Yes | Nájomné za rok 2026 (€) Nájomné zo všetkých vašich prenajímaných nehnuteľností za rok 2026 podľa § 6 ods. 3 ZDP (prenájom bez doplnkových služieb). Pri BSM alebo spoluvlastníctve zadajte sumu za celú nehnuteľnosť; váš podiel sa vypočíta. Pri rozpise nižšie sem nezahŕňajte energie, zábezpeku ani nepeňažné príjmy, tie zadáte zvlášť. | |
| vydavky | No | Daňové výdavky k prenájmu (€) Súčet daňových výdavkov pred pomerným krátením, vrátane energií a služieb, ktoré ste zahrnuli do príjmov. Čo sa dá uplatniť, závisí od toho, či je nehnuteľnosť v obchodnom majetku; ak si nie ste istí, použite rozpis. Only used when vydavkyRezim = suhrn. | |
| fondOprav | No | Preddavky do fondu prevádzky, údržby a opráv (€) Zaplatené preddavky správcovi alebo spoločenstvu vlastníkov. Daňovým výdavkom sú aj pri nehnuteľnosti mimo obchodného majetku. Príklad: 1 200 €. Only used when vydavkyRezim = polozky. | |
| energopomoc | No | Energopomoc (energopoukážky) k prenajímanej nehnuteľnosti (€) Ak ste energie tejto nehnuteľnosti uplatnili ako výdavok, je energopomoc príjmom z prenájmu; inak je oslobodená. Only used when vydavkyRezim = polozky. Default if omitted: 0. | |
| vlastnictvo | No | Komu nehnuteľnosť patrí? Pri BSM si manželia príjem rozdelia rovnakým dielom alebo v dohodnutom pomere (§ 4 ods. 8), pri podielovom spoluvlastníctve podľa spoluvlastníckeho podielu (§ 10 ods. 1). Výdavky sa delia v tom istom pomere a každý má vlastné oslobodenie 500 €. Options: sam = Len mne; bsm = Manželom v bezpodielovom spoluvlastníctve (BSM); spoluvlastnictvo = Viacerým spoluvlastníkom (podielové spoluvlastníctvo). Default if omitted: sam. | |
| energieRezim | No | Kto má zmluvu s dodávateľmi energií a služieb? Podľa metodiky Finančnej správy rozhoduje, kto má zmluvu s dodávateľom a kto platí. Ak je zmluva vaša, platby nájomcu za energie sú váš príjem a platby dodávateľom váš výdavok, aj keď nájomca platí dodávateľovi priamo. Ak má zmluvu nájomca, nie sú ani príjmom, ani výdavkom. Only used when vydavkyRezim = polozky. Options: prenajimatel = Ja, a dodávateľom platím ja; najomcaPriamo = Ja, ale nájomca platí dodávateľom priamo; zmluvaNajomcu = Nájomca má vlastnú zmluvu; neviem = Neviem. Default if omitted: prenajimatel. | |
| vydavkyRezim | No | Ako zadáte výdavky? Rozpis podľa druhu posúdi, čo je daňový výdavok a čo príjem. Súhrn použite, ak už máte overený súčet daňových výdavkov, napríklad z daňovej evidencie. Options: polozky = Rozpíšem príjmy a výdavky podľa druhu; suhrn = Zadám overený súčet daňových výdavkov. Default if omitted: polozky. | |
| odpisyMajetok | No | Odpisy nehnuteľnosti (€) Daňové odpisy za rok 2026. Znižujú základ dane, nie hotovosť. Only used when vydavkyRezim = polozky and obchodnyMajetok = ano. Default if omitted: 0. | |
| ostatnyZaklad | No | Ostatný základ dane podľa § 4 ods. 1 písm. a) (€) Základ dane zo zamestnania po nezdaniteľných častiach plus čiastkové základy podľa § 6 ods. 4 a § 8. Nie hrubá mzda. Živnosť (§ 6 ods. 1 a 2) a kapitálové príjmy (§ 7) sem nepatria. Only used when ineZdanitelnePrijmy = ano. Default if omitted: 0. | |
| zabezpekaStav | No | Ponechali ste si v roku 2026 časť zábezpeky (kaucie)? Vratná zábezpeka nie je príjmom, kým vám nevznikne právo si ju ponechať. Ponechaná na nezaplatené nájomné je príjmom; na náhradu škody len pri nehnuteľnosti v obchodnom majetku. Only used when vydavkyRezim = polozky. Options: ziadna = Nie, nič som si neponechal(a); najomne = Áno, na nezaplatené nájomné alebo poplatky; skoda = Áno, na náhradu škody. Default if omitted: ziadna. | |
| zabezpekaSuma | No | Ponechaná suma zábezpeky (€) Suma, na ktorú ste v roku 2026 získali právo. Only used when vydavkyRezim = polozky and zabezpekaStav = najomne or skoda. Default if omitted: 0. | |
| energiePrijate | No | Platby nájomcu za energie a služby, ktoré ste dostali navyše k nájomnému (€) Ak sú energie zahrnuté v nájomnom, zadajte 0. Only used when vydavkyRezim = polozky and energieRezim = prenajimatel. Default if omitted: 0. | |
| majetokVydavky | No | Opravy, poistenie, daň z nehnuteľností a úroky z úveru (€) Zaplatené v hotovosti. Daňovým výdavkom sú len pri nehnuteľnosti v obchodnom majetku; inak ich kalkulačka odpočíta len z hotovosti. Only used when vydavkyRezim = polozky. Default if omitted: 0. | |
| vydavkyOverene | No | Spĺňajú zadané výdavky podmienky ZDP? Ak si nie ste istí, základ dane ani daň neurčíme. Neuvádzame nulu ani odhad. Only used when vydavkyRezim = suhrn. Options: ano = Áno, sú to daňovo uznané výdavky s dokladmi; neviem = Neviem. Default if omitted: ano. | |
| obchodnyMajetok | No | Je nehnuteľnosť zaradená do obchodného majetku? Zaradená znamená, že ju vediete v účtovníctve alebo v evidencii podľa § 6 ods. 11 ZDP. Len vtedy sa uplatňujú odpisy, opravy, poistenie, daň z nehnuteľností a úroky z úveru na kúpu. Energie, služby a preddavky do fondu opráv sa uplatňujú v oboch prípadoch. Only used when vydavkyRezim = polozky. Options: nie = Nie; ano = Áno, vediem ju v obchodnom majetku; neviem = Neviem. Default if omitted: nie. | |
| oslobodenieStav | No | Koľko z oslobodenia 500 € vám zostáva? Oslobodenie 500 € ročne je jedno na daňovníka a delí sa s príležitostnými príjmami (§ 8 ods. 1 písm. a) a s oslobodenými prevodmi podľa § 8 ods. 1 písm. d) až f). Options: cele = Celých 500 € (iné takéto príjmy nemám); ciastocne = Časť som už použil(a) na iné príjmy; neviem = Neviem. Default if omitted: cele. | |
| energieZaplatene | No | Vaše platby dodávateľom energií a služieb (€) Elektrina, teplo, voda, plyn a služby spojené s užívaním (odpad, upratovanie, výťah, internet, správa domu). Plné sumy faktúr, aj časť uhradenú energopoukážkou. Príklad: 2 400 €. Only used when vydavkyRezim = polozky and energieRezim = prenajimatel. | |
| najomcaZhodnotenie | No | Nepeňažný príjem zo zhodnotenia alebo opráv, ktoré urobil nájomca (€) Technické zhodnotenie alebo opravy nad rámec zmluvy, ktoré ste nájomcovi neuhradili (§ 17 ods. 20 a 21 ZDP), v sume a roku určenom podľa týchto ustanovení. Inak 0. Only used when vydavkyRezim = polozky. Default if omitted: 0. | |
| pouziteOslobodenie | No | Už použitá časť oslobodenia (€) Suma oslobodenia, ktorú ste v roku 2026 uplatnili na iné príjmy (0 až 500 €). Only used when oslobodenieStav = ciastocne. Default if omitted: 0. | |
| ineZdanitelnePrijmy | No | Máte v roku 2026 aj iné zdaniteľné príjmy? Daň z prenájmu sa počíta zo spoločného základu so mzdou a niektorými ďalšími príjmami, preto bez tejto odpovede sumu dane neuvádzame. Options: neviem = Neviem / nechcem uvádzať; nie = Nie, prenájom je môj jediný zdaniteľný príjem (bez daňového bonusu a preddavkov); ano = Áno, poznám svoj ostatný základ dane. Default if omitted: neviem. | |
| energieNajomcaPriamo | No | Platby nájomcu priamo dodávateľom na vašu zmluvu (€) Tieto platby sú váš nepeňažný príjem a zároveň daňový výdavok v rovnakej sume; vašu hotovosť nemenia. Only used when vydavkyRezim = polozky and energieRezim = najomcaPriamo. Default if omitted: 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint false, openWorldHint false), so the description's added value is the disclosure that results are deliberately withheld in ambiguous cases and that the tool returns result rows, raw engine outputs, sources with lastChecked dates, and a disclaimer. It also explains the "Only used when" gating convention for conditional inputs, which is genuine behavioral context not present in annotations. It stops short of describing pagination/limits, but little is at stake for a deterministic read-only calculator.
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 purpose and statutory scope, then progressively narrower detail (withheld results, year/version stamp, page URL, return shape, conditional-input convention). Dense but each clause carries operational information; the versioning sentence is arguably the weakest, yet it is useful for a jurisdiction- and year-specific calculator.
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 23-parameter, 8-enum, interlocking calculator with no output schema, the description covers what the tool computes, when it declines to produce a number, and what the response contains. The conditional dependency structure is acknowledged rather than fully mapped, but the schema descriptions (at 100% coverage) carry that load, leaving the definition adequately complete.
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 23 parameters including 8 enums are already fully documented, giving a baseline of 3. The description earns one extra point by explaining the cross-field conditional contract — inputs labelled "Only used when" apply only in that branch — which is the one piece of semantics an agent cannot infer from the flat schema alone. It does not restate individual field meanings, which 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 and resource (Slovak personal income tax on property rental income for 2026) and pins the statutory basis (§ 6(3) of the Income Tax Act). It enumerates the exact computations covered — €500 exemption, proportional expenses, tax base, 19/25/30/35 % bands, filing obligation — which clearly separates it from the other country/benefit calculators in the sibling list.
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?
Sets clear context: rules year 2026, last updated date, and the boundary condition that no tax amount is returned while other income or expense verification is unknown. It does not explicitly route the agent between this and siblings such as list_calculators, but the domain is narrow enough that the applicable scenario is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Slovak statutory minimum severance pay (odstupné, Labour Code § 76), wage compensation on immediate termination by the employee (§ 69), the retirement allowance (odchodné, § 76a) and the minimum notice period with dates. All amounts are gross statutory minimums. Rules year 2026, last updated 2026-09-26. Page: https://kalkulo.eu/sk/kalkulacka-odstupne/. Returns result rows (page language), raw engine outputs, sources with lastChecked dates and a disclaimer. Inputs marked "Only used when" are needed only in that case.
| Name | Required | Description | Default |
|---|---|---|---|
| dovod | No | Dôvod skončenia uvedený vo výpovedi alebo v dohode Zákonné odstupné zakladajú len dôvody podľa §76 ods. 1 až 3. Pri inom dôvode ho zákon neprikazuje, zamestnávateľ ho však môže poskytnúť (§76 ods. 7). Ak dôvod nepoznáte, kalkulačka ukáže rozpätie. Only used when sposob = vypoved or dohoda. Options: organizacne = Organizačný dôvod: zrušenie alebo premiestnenie zamestnávateľa, nadbytočnosť (§63 ods. 1 písm. a), b)); zdravie = Podľa lekárskeho posudku ste dlhodobo stratili spôsobilosť vykonávať doterajšiu prácu; uraz = Pracovný úraz, choroba z povolania, ohrozenie ňou alebo najvyššia prípustná expozícia (§76 ods. 3); ine = Iný dôvod (napr. osobné dôvody zamestnanca, porušenie pracovnej disciplíny); neviem = Neviem. Default if omitted: neviem. | |
| sposob | No | Spôsob skončenia pracovného pomeru Odstupné podľa §76 patrí len pri výpovedi zo strany zamestnávateľa alebo pri dohode, a to z dôvodov uvedených nižšie. Pri okamžitom skončení zamestnancom podľa §69 nejde o odstupné, ale o náhradu mzdy. Options: vypoved = Výpoveď zo strany zamestnávateľa; dohoda = Dohoda o skončení pracovného pomeru; okamzite = Okamžité skončenie zo strany zamestnanca (§69); okamziteZamestnavatel = Okamžité skončenie zo strany zamestnávateľa (§68); ine = Iný spôsob (výpoveď zamestnanca, skúšobná doba, uplynutie doby určitej). Default if omitted: dohoda. | |
| odchodne | No | Máte nárok na odchodné (§76a)? Odchodné patrí pri prvom skončení pomeru po vzniku nároku na starobný dôchodok alebo invalidný dôchodok s poklesom schopnosti nad 70 %, ak ste oň požiadali pred skončením alebo do 10 pracovných dní po ňom, a pri priznaní predčasného starobného dôchodku na žiadosť podanú pred skončením alebo do 10 dní po ňom. Patrí len od jedného zamestnávateľa a pri okamžitom skončení zamestnávateľom podľa §68 ods… Options: ano = Áno, podmienky spĺňam a odchodné som ešte nedostal/a; nie = Nie; neviem = Neviem. Default if omitted: neviem. | |
| zaciatok | Yes | Začiatok pracovného pomeru Deň nástupu do tohto pracovného pomeru. Pri reťazení pomerov na určitú dobu alebo pri prechode k inému zamestnávateľovi si započítanie overte u zamestnávateľa. Predvolený dátum je príklad. Date as YYYY-MM-DD, or "" if unknown. | |
| dorucenie | No | Deň doručenia výpovede Výpovedná doba sa určuje podľa trvania pomeru ku dňu doručenia a začína plynúť prvým dňom nasledujúceho mesiaca (§62 ods. 3, 4 a 7). Only used when sposob = vypoved. Date as YYYY-MM-DD, or "" if unknown. | |
| skoncenie | Yes | Deň skončenia pracovného pomeru Pri dohode dohodnutý deň skončenia (nemusí to byť deň podpisu), pri výpovedi posledný deň výpovednej doby. Násobok odstupného sa určuje podľa trvania pomeru k tomuto dňu. Date as YYYY-MM-DD, or "" if unknown. | |
| vynimkaUraz | No | Uplatní sa výnimka z §76 ods. 3? Desaťnásobok nepatrí, ak ste pracovný úraz spôsobili zavineným porušením predpisov alebo pokynov o bezpečnosti a ochrane zdravia pri práci, s ktorými ste boli preukázateľne oboznámení, alebo pod vplyvom alkoholu, omamných či psychotropných látok. Pri chorobe z povolania a expozícii zvoľte Nie. Only used when dovod = uraz. Options: ano = Áno, výnimka sa uplatní; nie = Nie, výnimka sa neuplatní; neviem = Neviem. Default if omitted: neviem. | |
| okamziteSplnene | No | Je okamžité skončenie platné podľa §69 a §70? Platné je, ak nastal dôvod podľa §69 ods. 1 (napr. mzda alebo jej časť nebola vyplatená do 15 dní po splatnosti; lekársky posudok a nepreradenie do 15 dní; bezprostredné ohrozenie života alebo zdravia), skončili ste do jedného mesiaca odo dňa, keď ste sa o dôvode dozvedeli, a písomné skončenie s konkrétne vymedzeným dôvodom bolo doručené zamestnávateľovi. Only used when sposob = okamzite. Options: ano = Áno, podmienky sú splnené; nie = Nie; neviem = Neviem. Default if omitted: neviem. | |
| priemernyMesacnyZarobok | Yes | Priemerný mesačný zárobok (PMZ) Priemerný mesačný zárobok podľa §134 Zákonníka práce, ktorý zamestnávateľ zisťuje spravidla z predchádzajúceho kalendárneho štvrťroka. Môže byť vyšší aj nižší ako vaša aktuálna hrubá mzda. Zadajte sumu od mzdovej účtárne; 1 500 € je len príklad. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description goes beyond that by disclosing the legal basis and its currency (rules year 2026, last updated 2026-09-26), that amounts are gross statutory minimums, the source page, and the return payload (result rows, raw engine outputs, sources with lastChecked, disclaimer).
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?
Four sentences, front-loaded with what is computed before moving to legal currency, source page and return shape. Dense with § references but every sentence carries information; the only slight drag is the pipe-separated enumeration of covered allowances, which reads as a list crammed into a paragraph.
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 9-parameter, 5-enum calculator with no output schema, the description supplies the needed framing: jurisdiction, statutory basis, year/update stamp, gross-minimum caveat, source URL, return contents and disclaimer. It stops short of explaining how the conditional inputs interact with the result semantics or any rounding/validation behavior.
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 each parameter carries detailed Slovak-language documentation, so the schema does the heavy lifting and baseline 3 applies. The description's only added parameter meaning is the meta-note that 'Only used when' inputs are conditional, which is marginal but not zero value.
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 resource and scope: Slovak statutory minimum severance pay (odstupné, §76), plus the exact additional computations covered (wage compensation on immediate termination §69, odchodné §76a, minimum notice period dates). The legal citations and 'gross statutory minimums' qualifier make the tool's remit unambiguous and clearly distinct from sibling calculators such as slovakia_rental_income_tax.
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 is implied rather than stated: nothing tells the agent when to pick this over a sibling calculator or what preconditions the user must meet. It does give conditional parameter guidance ('Inputs marked "Only used when" are needed only in that case'), which is useful but is about filling inputs, not about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
czechia_company_car_benefitestonia_redundancy_compensationgreece_annual_leavegreece_unemployment_benefitlatvia_vacation_paylist_calculatorsluxembourg_unemployment_benefitmalta_vacation_leaveserbia_vatslovakia_rental_income_taxslovakia_severance_payRead-only payroll calculations and multi-country tax comparisons for eight countries.
Net pay to the cent, every deduction and the employer's cost for Germany and the UK, computed with…
Fiscalidad, derecho laboral y finanzas de España: IRPF, autónomos (cuota RETA, modelos 130 y 303, gastos deducibles), nóminas de bruto a neto, despidos (indemnización, finiquito, paro), herencias y donaciones por comunidad autónoma, jubilación y pensiones, hipotecas y compraventa de vivienda. Incluye consultas de escenario que combinan varios cálculos a la vez, como haría una gestoría. Gratuito, sin registro ni API key.
European govt data, cited: rates, VAT, tax, wages, holidays, FX. 35 countries; Germany free.
Add one secure layer between your agents and this server.
