PromNET — Hungarian business calculators & legal checker

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered structurally. The description adds useful domain context – the available VAT rates and that 0% corresponds to alanyi adómentes – but nothing about rounding, currency handling, or output format. With annotations carrying the behavioral load, 3 is appropriate.

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?

Two short sentences, front-loaded with the core operation before the rate details. Nothing is redundant, though it is minimal to the point that a little more operational detail could have been afforded.

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?

A pure calculation tool with three well-documented parameters, no output schema required, and a description that covers the operation, inputs, and the meaning of the result (includes the VAT amount). Rounding/currency precision is the only real omission for a money-calculation tool.

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 are documented in the schema, so the baseline is 3. The description reinforces the rate set and explains the 0% case (alanyi adómentes), which adds mild semantic value over the enum values, but it says nothing extra about osszeg or osszeg_tipusa beyond the schema.

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: converts net to gross or gross to net (nettóból bruttót vagy bruttóból nettót számol) and returns the VAT amount. This clearly distinguishes it from siblings like ber_szamitas or kesedelmi_kamat, which compute different quantities. It does not explicitly name any sibling, but the arithmetic function 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?

The description implies when the tool applies (whenever a Hungarian VAT conversion is needed) via the 'nettó ↔ bruttó' framing, and the rate list signals the supported cases. However, it gives no explicit when-to-use/when-not guidance and does not reference any alternative tool for related tasks (e.g. corporate tax or late-interest siblings).

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

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

Annotations already declare this a pure read-only, idempotent, non-destructive, closed-world calculation. The description adds useful domain context (which allowances and thresholds apply), but no behavioral traits beyond that — no statement of what the response contains or any edge-case handling, which is acceptable given the safety profile is fully covered.

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 core action and packed with the applicable 2026 rules in a tight single dense sentence with no filler. The heavy parenthetical detail is justified but makes the sentence somewhat run-on.

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 compensates by listing the computed outputs (nettó, SZJA, TB, szocho, employer cost). Combined with annotations that fully cover the safety profile, an agent has enough to invoke it correctly, though it could be explicit that these are the returned fields.

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 coverage is 100%, so the baseline is 3, but the description genuinely enriches the terse schema fields: it maps gyerekek to concrete allowance amounts (20 000 / 40 000 / 66 000 Ft), explains the 715 765 Ft threshold for the under-30-mother allowance, and clarifies the two conditions behind anya_szja_mentes.

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 (kiszámolja) and resource (nettó from bruttó havi bér) and enumerates the exact components computed (SZJA 15%, TB 18,5%, szocho 13%, total employer cost). The purpose is unambiguous, though it never names or contrasts with siblings like afa_szamitas, so differentiation is left to the name alone.

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 — an agent can infer this is the tool for turning a gross monthly salary into net and employer cost. However, there is no explicit when-to-use, when-not, or reference to alternative tools such as egyeni_vallalkozo_adozas for different tax regimes.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered without the description. The description contributes real behavioral context by enumerating exactly which legal elements are inspected, including the forward-looking 2026-06-19 online withdrawal requirement, but says nothing about how the page is fetched or whether dynamic/JS-rendered sites are handled.

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 dense sentence that front-loads the scope ('Egy magyar weboldal kívülről látható jogi hiányosságai') before the enumeration. The long list of legal elements earns its place as a scope specification, though it reads as a run-on rather than structured points.

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 one-parameter, read-only inspection tool with no output schema, the description adequately covers what is checked, and annotations carry the safety profile. However, without an output schema it should indicate what the agent receives back (a findings report? a pass/fail list?) and any coverage limits such as login-protected or script-rendered pages.

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?

There is one parameter (url) with 100% schema description coverage ('A weboldal címe, pl. cegem.hu'), so the schema already documents it fully. The description adds no additional syntax or format meaning beyond what the schema provides, so the baseline 3 for high-coverage schemas applies.

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 and scope — the externally visible legal gaps of a Hungarian website — and enumerates the exact compliance areas inspected (impresszum, ÁSZF, adatkezelési tájékoztató, cookie consent, ODR, elállási jog). The verb is implicit ('hiányosságai' implies it surfaces deficiencies rather than merely listing elements), and it is trivially distinguishable from the numeric sibling tools, but a fully explicit 'checks/reports' verb is missing.

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 or when-not-to-use guidance is given, and no alternatives are named (the siblings — afa_szamitas, ber_szamitas, etc. — are unrelated calculators, so routing is not a real risk). The phrase 'kívülről látható' implies a useful boundary (only externally observable, non-authenticated content), which is implied usage rather than stated guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true. The description adds useful context that the rate tracks the live MNB base rate and is applied semi-annually, which explains the open-world behavior, but it says nothing about the 40 EUR cost item's currency handling or how the live rate is obtained.

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 dense sentence that front-loads the governing rule and compresses the rate structure without filler. It is long for one sentence but every clause carries substantive rule information.

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 should clarify what is returned (e.g. the interest amount in HUF and whether the fixed cost lump sum is included). The legal rule set is described well, but the return contract and date-handling behavior are left unstated for a four-parameter calculation tool.

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 all four parameters are already documented, and the baseline is 3. The description does enrich one parameter by mapping 'vállalkozások között' to the +8 percentage-point rule, but it adds no interpretation guidance for osszeg, esedekesseg or fizetes_napja.

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 computation (late-payment interest under the Ptk.) and the exact rate rules it applies, which is far more informative than the bare name 'kesedelmi_kamat'. It does not explicitly distinguish itself from siblings like afa_szamitas or ber_szamitas, though those are plainly different domains.

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 statement of when to use this tool versus alternatives, no prerequisites (e.g. that a late payment actually occurred), and no exclusions. The intended scenario is only implied by the domain vocabulary.

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

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, so the safety profile is covered. The description adds real domain behavior — Hungarian public holidays and shifted workdays are included, and it can also return a year's holidays — which is useful context. It does not explain output format or how the two modes are selected, so a 3 is apt.

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 dense sentence that front-loads the resource and both operations, with no filler or restatement of the title. It is information-dense rather than wasteful, though the packed Hungarian clause structure makes it slightly harder to scan quickly.

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 3-parameter, single-output-less read-only calculator with full schema coverage and complete annotations, the description covers both operating modes and the holiday/shifted-workday semantics that an agent could not infer elsewhere. Only the return shape and mode-selection rules are unstated, which is minor given no output schema exists.

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 all three parameters (mettol, meddig, munkanap_szam) are already documented in the schema. The description mirrors the same two-mode framing (interval vs. N-workday offset) without adding format, default, or mutual-exclusivity detail beyond what the schema states. Baseline 3 applies when the schema carries the load.

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 (Munkanapok) and two concrete operations: counting workdays between two dates and finding the N-th workday (deadline) from a date, including holidays and shifted workdays. An agent immediately knows the domain and both modes, though it never explicitly contrasts itself with the sibling szabadsag (vacation) tool.

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 two described modes — 'határidő' signals deadline computation, date-interval counting signals duration queries — but there is no explicit when-to-use/when-not statement and no routing to or away from siblings. Adequate but leaves the agent to infer which mode the caller wants.

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

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

Annotations already declare the operation as read-only, idempotent, non-destructive and closed-world, so the safety profile is fully covered by structured data. The description adds domain scope (which content areas are offered) but says nothing about the return shape or what invoking it produces — a real gap for a zero-parameter tool with 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.

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

Two sentences, front-loaded with the service enumeration that matters most, and the trigger condition placed last. The first sentence is a long run-on list of seven items, but each item conveys scope rather than filler, so it stays within acceptable bounds.

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 parameterless, read-only informational tool with no output schema, the description supplies the offering list and the invocation trigger, which is close to sufficient. The missing piece is any hint of what the tool returns (link, catalog, generated text), which is the main remaining uncertainty for the agent.

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 there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. The schema description coverage is 100% regardless, and no parameter-level detail is needed.

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 identifies the resource (PromNET's free tools and services) by enumerating its contents, but supplies no action verb — it reads as marketing copy ('Mit kínál a PromNET...') rather than stating what invoking the tool does. An agent can infer it is an informational/overview resource, and the enumeration partly separates it from calculation siblings, but the operation itself remains vague.

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 second sentence gives an explicit trigger: call it when the user needs ÁSZF, privacy notice, imprint, cookie banner, cancellation button, or a simple company website. That is concrete when-to-use guidance. It stops short of naming alternatives or exclusions — notably it never points to the jogi_ellenorzes sibling, which overlaps with the legal-document use case.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety behavior is covered. The description adds useful domain scope (what inputs drive the result), but says nothing about the return form or how proration is resolved; with annotations doing the safety work, this is adequate but not rich.

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 that leads with the core question and then lists the determining factors. No filler or repetition of the name/title.

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 5-parameter calculator with no output schema, the description conveys the domain and the factors affecting the result, and annotations cover safety. It could say more about what the output actually contains (a day count, breakdown), but it is broadly sufficient to invoke 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%, so all five parameters are already documented (year, start date, children, birth year, disabled children). The description mirrors those concepts at a high level without adding format or edge-case meaning, so the baseline 3 applies.

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 computation (how many vacation days are due under the Labor Code) and enumerates the sub-cases it covers: base leave, age- and child-based supplements, young employee, mid-year proration. It is clearly distinguishable from numeric siblings like afa_szamitas and ber_szamitas, though it does not name any sibling 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?

The description implies usage by listing the covered scenarios (age, children, proration), which helps an agent recognize the right case, but there is no explicit when-to-use, when-not-to-use, or reference to alternative tools. Usage is implied rather than directed.

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