tax-engine

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

The readOnlyHint annotation already covers safety, and the description adds useful behavioral context: the 2,000,000 CZK exit threshold and the three possible outcomes. It does not contradict the annotation and provides additional edge-case information.

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 description is a single, well-structured sentence that front-loads the core purpose and includes a key threshold. No unnecessary words or repetition.

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?

Without an output schema, the description should clarify the return structure; it only states the tool 'computes whether' without detailing how results are formatted. The optional parameters and projection mode are not mentioned, which is a notable gap for a tool with this complexity.

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 description clarifies currentBand and actualAnnualIncome, which are the two required parameters, but it does not explain isProjection, monthsInRegime, or flatRatePercent. With 60% schema coverage, it partially compensates but leaves a gap.

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 uses a specific verb ('computes') and resource ('paušální daň settlement') and clarifies the outcome types (doplatek, vratka, exit). It distinguishes itself from sibling tools by focusing on the settlement decision rather than eligibility or thresholds.

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 context of a year-end settlement is implied, but there is no explicit guidance on when to use this tool over siblings like check_flat_tax_eligibility or compare_regimes. No alternatives or exclusions are mentioned.

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 as read-only, and the description doesn't contradict that. The description adds the scope of what the calculator accounts for (income tax, social/health insurance, spendable amount) and supported income types, but doesn't disclose details like rounding, assumptions, or output format. This is acceptable given the read-only annotation, but it adds minimal behavioral insight beyond the annotation.

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 description is two sentences, immediately states the core question, and includes supporting context without redundancy. Every phrase earns its place, and the structure is front-loaded with the main purpose.

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 9 parameters and no output schema, the description is too brief to fully guide invocation. It doesn't explain return values, key parameter interactions (e.g., how pausal bands affect the calculation), or conditions like advanceExempt. The read-only annotation reduces safety concerns, but the tool still needs more contextual detail for reliable use.

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 only 44%, leaving several parameters (taxRegime, activityType, advanceExempt, employerCoversHealth, secondaryThresholdExceeded) without inline descriptions. The description hints at some parameters (mixed income, flat tax) but doesn't explain their semantics or how they affect the calculation. Thus it doesn't adequately compensate for the low schema coverage.

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 clearly states the tool's purpose: calculating how much of monthly OSVČ income to set aside for Czech income tax, social and health insurance, and what remains safe to spend. It also specifies support for mixed §7/§9 income and flat-tax regimes, which helps distinguish it from sibling calculators like calc_flat_tax_settlement. However, it doesn't explicitly name alternatives or exclusions, so it stops short of a perfect score.

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 on when to use the tool: for monthly set-aside calculations, including mixed §7/§9 income and flat-tax regimes. This helps an agent understand applicability but doesn't explicitly state when not to use it or point to alternative tools such as calc_flat_tax_settlement. That is a mild gap.

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?

The readOnlyHint annotation already covers safety. The description adds behavioral context by stating it returns 'reasons with severity' and specifies the screening dimensions (health insurance, VAT, income ceiling, side income). This goes beyond the annotation and provides useful expectations.

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 front-loaded sentences: the first states the purpose and key criteria, the second states the return format. Every word contributes value; no filler or repetition.

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 6-parameter tool with no output schema, the description gives a strong overview of the logic and return structure. It could be more explicit about how parameters interact (e.g., rental income vs. main income) and the severity levels, but overall it satisfies the core need.

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 50%, so the description compensates by naming the income ceiling (2,000,000 CZK), VAT-payer status, public health insurance participation, and side/secondary activity. This clarifies the meaning of annualIncome, isVATRegistered, citizenshipType, and activityType. However, rentalAnnualIncome is not explicitly mapped.

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 uses a specific verb ('Screens whether') with a named resource ('OSVČ may enter or stay in the paušální daň regime') and lists the key criteria. This clearly distinguishes it from sibling tools like calc_flat_tax_settlement or check_thresholds.

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 clearly implies when to use this tool (when checking flat tax eligibility) but does not explicitly mention alternatives or exclusions. It lacks guidance such as 'use check_thresholds for general thresholds' or 'use calc_flat_tax_settlement for calculations'.

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?

Beyond the readOnlyHint annotation, the description discloses fact-freshness handling and the 15-day registration deadline, and reveals the verdict outputs ('ok / check / act_now'). This adds meaningful behavioral context without contradicting the annotation.

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 description is a single, information-dense sentence that front-loads the action ('Checks whether') and includes legal references, examples, and output verdicts. Every phrase adds value, though the density could be slightly off-putting.

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 supplies the verdict values and mentions deadline/freshness handling, giving a solid picture of the tool's behavior. It does not detail all possible return fields, but for a check tool the verdict is the primary output and the schema covers inputs well.

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 high (86%), so the baseline is 3. The description adds contextual examples (Google Ads, Meta, ChatGPT, hosting) that map to foreignServicePurchase and foreignSales, but it does not explain individual parameters beyond what the schema already provides.

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 clearly states the tool's function: checking whether foreign service purchases or sales to EU businesses trigger identifikovaná osoba status under specific legal sections (§ 6h/§ 6i ZDPH), with a definitive verdict output. It distinguishes from sibling tools like check_thresholds by focusing on the IO trigger rather than general VAT thresholds.

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 when the tool is relevant (buying foreign services, selling to EU businesses) with concrete examples, and mentions the 15-day deadline. However, it does not explicitly name alternative tools or state when not to use this tool, leaving some room for the agent to infer applicability.

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?

The readOnlyHint annotation already marks the tool as safe, and the description adds meaningful behavioral detail by specifying the output conditions: approaching (90%), exceeded, and remaining amounts. This enriches the agent's understanding without contradicting the annotation.

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 concise sentences front-load the core action and then list the four thresholds and output behavior. There is no redundant or irrelevant text; every piece of information earns its place.

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 tool with a single numeric input and no output schema, the description fully covers both input meaning and result categories (approaching, exceeded, remaining). An agent has enough information to invoke the tool and interpret its returned values.

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 sole parameter annualIncome has no schema description, but the description clarifies it as an annual income amount and gives all thresholds in CZK, strongly implying the currency unit. This compensates for the 0% schema coverage, though it could be even more explicit.

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 uses a specific verb ('Checks') and names the exact resource: an annual income against four enumerated statutory thresholds (VAT, higher tax bracket, flat tax ceiling). This clearly distinguishes it from sibling tools like check_flat_tax_eligibility and compare_regimes.

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 intended use is clear: feed an annual income to detect threshold proximity and exceedance. It does not explicitly mention exclusions or alternative tools, but the tight scope and threshold details imply the correct usage context.

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. The description adds that the tool accounts for tax credits lost with the flat tax (children, spouse) and that it recommends the cheaper regime, providing useful behavioral context beyond the read-only flag. It does not disclose all assumptions, but it gives meaningful insight into the calculation logic.

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 description is a single informative sentence, front-loaded with the action verb, and includes relevant details without redundancy. It is concise but not overly terse, making it effective and easy to parse.

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 8 parameters, a nested object, and no output schema, the description does not fully specify the return structure or explain all inputs. It does mention the recommendation output, but it leaves out how deductions and the flat-rate percentage factor into the comparison, so an agent may not know what to expect or how to populate all parameters.

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 only 38%, and the description only partially compensates by mentioning 'yearly income' and 'children, spouse' as factors. It provides no meaning for deduction fields, flatRatePercent, rentalAnnualIncome, or the nested deductions object, leaving the agent to rely on parameter names alone. This is insufficient for a tool with 8 parameters.

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 uses a specific verb 'Compares' and clearly identifies the two regimes (standard OSVČ vs paušální daň), along with the key factor of lost tax credits and the recommendation output. This distinguishes it from siblings like calc_flat_tax_settlement and check_flat_tax_eligibility, which handle singular calculations or eligibility checks.

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 the primary use case: comparing regimes for a yearly income, and notes the inclusion of tax credits. However, it does not explicitly state when not to use this tool or name alternatives, though the context is clear enough for an agent to select it over more specific calculation or eligibility tools.

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?

With readOnlyHint already present, the description adds valuable context: 'All figures come from the deterministic Freelax engine, never from the model.' This tells the agent the output is reliable and not AI-generated, which is important for a computation tool. It also specifies the scope of computation, going beyond the annotation without contradicting it.

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 description is two sentences, front-loaded with the primary action, and every phrase carries meaning. It efficiently lists the computed outputs and the deterministic-engine guarantee without unnecessary detail.

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 tool with 23 parameters, nested objects, no required fields, and no output schema, this description is incomplete. It explains what is computed but not the response structure, default behaviors, validation rules, or how results are presented. Since output schema is absent, more detail is needed for an agent to use it effectively.

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 only 26%, and the description does not compensate. While it mentions parameter groups (children, spouse, deductions), it fails to explain individual parameters like hasZTP, isStudying, citizenshipType, or the precedence of annualBusinessIncome over monthlyBusinessIncome. The description adds little beyond what the sparse schema already states.

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 clearly states the tool's function: 'Computes a full Czech OSVČ tax year from personal facts' and lists specific components (income tax, insurance, set-aside, safe-to-spend, flat-tax band, regime eligibility). This distinguishes it from sibling tools that handle more specific calculations (e.g., calc_flat_tax_settlement, compare_regimes) by emphasizing the full-year scope.

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: 'full Czech OSVČ tax year' and enumerates what the computation covers, implying use when a comprehensive annual calculation is needed. However, it does not explicitly mention when not to use this tool or name alternative tools, so it falls 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.

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

The readOnlyHint annotation already indicates no side effects. The description goes beyond that by disclosing that the tool reports the rate's publication date, may use a stale cached ČNB publication, and fails closed if no verified rate is available. This is valuable operational context.

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 description is two sentences long, front-loaded with the purpose, and every sentence adds either operational detail or failure behavior. No redundancy or filler.

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?

The description covers the core conversion, the rate source, output specifics (rate, publication date, stale flag), and failure mode. It does not explicitly say the converted CZK amount is part of the output, but that is strongly implied by the verb 'converts.' Given the simplicity and full parameter schema, this is near-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?

The schema fully describes the only parameter, amountEur, with name, description, and numeric constraints. Schema coverage is 100%, so the description does not need to add parameter meaning, and it does not. 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 clearly states the tool converts EUR to CZK using the Czech National Bank daily rate, and explicitly notes its use for Czech tax purposes. This specific verb+resource pair distinguishes it from the sibling tax-related tools, none of which perform currency conversion.

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: use this tool when you need EUR→CZK conversion at the CNB rate for Czech tax purposes. It does not explicitly mention alternatives or when not to use, but no sibling tool covers the same function, so the context is sufficient.

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?

The readOnlyHint annotation is present, and the description goes beyond it by explaining the output semantics: it returns holidays and, for a date, working-day status and the next working day a deadline would shift to. This adds valuable behavioral context without contradicting the annotation.

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 description is a single, well-structured sentence that front-loads the main purpose and packs the key behaviors without wordiness. Every clause adds value, and there is no redundant or extraneous 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 adequately conveys what the tool returns (holidays, working-day status, next working day). It covers both parameter use cases and the tool's scope (Czech calendar), making it sufficiently complete for an agent 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 coverage is 50% (only 'date' has a description). The tool description compensates by clarifying that 'year' is the calendar year for holiday lookup and 'date' is the specific date to test. It adds meaning to the otherwise undescribed 'year' parameter and reinforces the semantics of 'date'.

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 clearly states the tool provides Czech public holidays for a year and, for a given date, returns its working-day status and the next working day for statutory deadlines. It uses specific verbs like 'provides' and 'whether it is' and distinguishes itself from sibling tax-specific tools by focusing on working-day calculations.

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 clear usage contexts: 'for a year' for annual holiday lists and 'for a specific date' for working-day checks. It does not explicitly mention alternatives or exclusions, but the context is sufficiently clear for an agent to know when to use this tool.

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?

Beyond the readOnlyHint annotation, the description discloses specific behavioral details: repo rate plus 8 percentage points, specific rates for 2026 half-years, 3 grace days, floors, and the rejection condition for dated estimates outside implemented history. This is rich, non-obvious behavioral information that aids the agent in understanding how the tool behaves.

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 description is two sentences, compact, and front-loaded with the primary purpose. Every sentence carries substantive information (rates, thresholds, rejection behavior) without unnecessary verbiage.

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?

Given the tool's complexity (5 parameters, no output schema), the description covers key aspects: calculation inputs, rate types, and a critical limitation. It does not describe return format, but that may be less critical for a calculation tool. The behavioral notes provide sufficient context for most usage scenarios.

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 description provides some context for parameters (e.g., repo rate, grace days, thresholds) but does not directly explain each parameter's role. Schema coverage is 60%, meaning some parameters are not described in the schema or the description. The description adds value but not enough to fully compensate for the coverage gap.

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 clearly states the tool's purpose: estimating the Czech penalty/interest for a late payment or filing. It names the specific resource (penalty/interest) and verb (estimates), and includes rate details that immediately distinguish it from sibling tools.

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 when to use the tool (for late payment or filing penalty estimates) but does not explicitly mention alternatives or when not to use it. It does note a key constraint about dated estimates being rejected outside implemented history, which helps guide usage.

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?

The annotation only indicates readOnlyHint: true, and the description adds a meaningful behavioral detail: 'Weekend and holiday shifts are applied.' This goes beyond the annotation by disclosing that the deadline is adjusted for non-working days, which is useful context for the agent. No contradictions are present.

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 description is two concise sentences with no waste. The first sentence front-loads the core purpose (deadline + entity + routes), and the second adds a key behavioral rule. Every word contributes to understanding the tool's function.

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?

Given the simplicity of the tool (2 params, 1 required, no output schema), the description covers the essentials: what it returns (a deadline), for what (DPFO), and the key behavior (weekend/holiday shifts). It could be more explicit about the return format (e.g., a date), but the description is adequate for the tool's complexity and annotation support.

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. The description paraphrases the route enum names ('paper, self-filed electronic, or via tax advisor') but does not introduce new semantics beyond what the parameter descriptions already state. It adds marginal value by confirming the relationship between routes and deadlines.

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 clearly states the tool returns a deadline for the Czech personal income tax return (DPFO), specifying the resource (tax year) and scope (per filing route). It explicitly lists the three filing routes (paper, self-filed electronic, tax advisor), which distinguishes it from sibling tools like get_prehled_deadlines or czech_working_days.

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 to use the tool—when you need a specific filing deadline for a given tax year and route—but it does not explicitly name alternatives or provide exclusions. There is no direct comparison to sibling tools, so usage context 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.

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

The annotations already declare readOnlyHint=true, so the safety profile is known. However, the description adds confusion by mentioning 'current monthly payment' and 'next income threshold' without clarifying whether these are inputs, outputs, or internal calculations. This creates ambiguity about the tool's behavior beyond what annotations cover.

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 description is a single long, run-on sentence with extraneous details. It is not front-loaded and contains unnecessary clauses that could be omitted. A clearer, shorter sentence such as 'Returns the flat tax band (1/2/3) for a given annual income and expense flat rate' would be more effective.

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?

There is no output schema, so the description must clarify the return value. It states the tool determines the band, but also mentions 'current monthly payment' and 'next income threshold', leaving uncertainty about whether these are returned. Given the domain's complexity, the description is incomplete and does not fully explain the tool's role relative to sibling tools.

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 50%: flatRatePercent has a description, annualIncome does not. The description refers to 'annual income' and 'expense flat-rate', providing some meaning for both parameters. But it also introduces non-schema concepts, which detracts from clarity. It partially compensates for the missing parameter description.

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 clearly states it determines the paušální daň band for an annual income, using a specific verb and resource. However, it includes extra clauses about 'current monthly payment' and 'next income threshold' that are not in the schema, slightly muddying the purpose but still understandable.

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 the tool is for mapping income to a band, which is a common use case, but it does not explicitly state when to use it versus alternatives like check_flat_tax_eligibility or compare_regimes. No exclusions or alternative guidance are provided.

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?

The description adds useful context beyond the readOnlyHint annotation by noting that results vary by filing route and that the payment due date is 8 calendar days after the filing deadline. It does not contradict the annotation and provides helpful behavioral details. Given the annotation already covers safety, this is adequate.

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 description is a single, information-dense sentence that packages all key behaviors without unnecessary words. It is front-loaded with the core subject and then enumerates specifics. The structure is acceptable, though a slight split would improve readability.

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?

The description covers the what (deadlines for both insurers, payment due date), the variable (route), and the time context (annual report). Without an output schema, it does not describe return formatting, but that is not essential for a simple reference lookup. It is complete enough for the tool's simplicity.

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 schema provides detailed descriptions for the route parameter's enum values, covering semantics well. The description mentions 'per tax-return filing route' but does not add new information about parameters. With 50% schema coverage, the schema carries the load and the description adds minimal 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?

The description clearly identifies the tool as providing filing deadlines for the annual OSVČ Přehled for both ČSSZ and the health insurer, distinguishing it from sibling get_filing_deadlines by specifying the exact resource and scope. Though it uses a noun phrase rather than an explicit verb, the tool name 'get_' makes the operation clear. This is a strong purpose statement.

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 to use this tool—when you need OSVČ Přehled deadlines for a given tax year and route—but it does not explicitly mention alternatives or exclusion criteria. With sibling tools like get_filing_deadlines present, there is no direct guidance on when to choose this tool over others. Thus guidance is implied, not explicit.

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, so the read-only nature is covered. The description adds contextual detail about return content (current values, verification dates, source institutions) but does not disclose deeper behaviors like data freshness, error handling, or rate limits.

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 description is two sentences, front-loaded with the main purpose, and the topic list is compact. Every sentence is useful.

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?

The description covers purpose, supported topics, and return components (rule, citations, verification dates, articles), which is adequate for a simple lookup without an output schema. However, it lacks details on locale handling and the exact structure or format of the returned citations.

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 schema has zero description coverage, and the description only restates the topic enum values without explaining their meaning. The locale parameter is not mentioned in the description, so the agent gets no extra semantics 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?

The description states a specific action ('returns') and resource ('governing rule with primary-source citations, verification dates, and related Freelax articles'), and the topic scope is clear. It distinguishes from sibling calculation tools by emphasizing citations and verification rather than numeric computation.

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 context ('For a Czech OSVČ tax topic') and lists supported topics, implying when the tool is appropriate. However, it does not explicitly state when to prefer this over sibling tools like get_flat_tax_band or check_thresholds, nor any exclusions.

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