Skip to main content
Glama

PromNET — Hungarian business calculators & legal checker

KATA vagy átalányadó? (egyéni vállalkozó, 2026)

egyeni_vallalkozo_adozas
Read-onlyIdempotent

Egyéni vállalkozó éves adóterhe 2026-ban az éves bevétel alapján: új KATA (50 000 Ft/hó, csak magánszemély ügyfeleknek, 18 M Ft-ig), átalányadós alanyi adómentes EV (20 M Ft-ig, ÁFA nélkül) és átalányadós áfás EV. Átalányadó: költséghányad (45% általános, 80% egyes tevékenységek, 90% kiskereskedelem), évi 1936800 Ft SZJA-mentes jövedelem, 15% SZJA, 18,5% TB, 13% szocho, főfoglalkozásban minimum-járulékalapokkal.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "eves_bevetel": "<eves_bevetel>"
    },
    "name": "egyeni_vallalkozo_adozas"
  }
}

Input Schema

NameRequiredDescriptionDefault
eves_bevetelYesVárható éves bevétel forintban (ÁFA nélkül).
koltseghanyadNoÁtalányadó költséghányada (alapértelmezés: 45).
csak_maganszemely_ugyfelekNoCsak magánszemélyeknek számláz (a KATA csak ekkor választható).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorldHint=false, so the safety profile is fully covered. The description adds domain constants (rates, thresholds) but says nothing about determinism of the result or the shape of the response beyond the annotations' baseline.

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?

It is front-loaded with the core subject, and every clause carries tax-domain information rather than filler. But it is a single run-on sentence cramming three regimes and a dozen figures together with no visual structure, making it hard to scan quickly.

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

Completeness3/5

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

Inputs and domain rules are covered thoroughly, but there is no output schema and the description never indicates what the tool returns (a comparison of burdens per regime, a recommended regime, amounts in Ft). For a multi-regime calculator, that leaves the agent guessing about result interpretation.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline would be 3, but the description adds genuine meaning: it explains that 45/80/90 are cost-ratio categories (general / certain activities / retail) and that the private-clients flag gates KATA eligibility, which the terse schema descriptions only hint at.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

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

The description names a specific subject: the 2026 annual tax burden of an individual entrepreneur (KATA vs. átalányadó), based on annual revenue. That clearly separates it from siblings like afa_szamitas or ber_szamitas. However, it never states the operative verb (compare/calculate), so the agent must infer that this is a calculator rather than an informational text.

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?

Usage is implied through the eligibility rules (KATA only for private-person clients, up to 18M Ft; átalányadó up to 20M Ft), which implicitly tells the agent what inputs select which regime. There is no explicit 'use this when / not when' statement and no reference to the sibling tools it might be confused with.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources