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

With no annotations, the description carries the full burden and does substantial work: it explains that shares are B-income with nothing withheld, the resulting restskat and the 31 December voluntary-payment interest consequence, the three withholding models, that assumptions live in dk_tax.calc.payslip, and that it is not tax advice. It does not explicitly state that the call is side-effect-free (an estimate), though the verb and output framing imply 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?

Purpose and usage lead, then a compact semi-colon separated parameter glossary; dense but nearly every clause carries tax-domain information an agent could not infer. Minor waste: the pointer 'see share_vest' references a tool that is not among the listed siblings, which adds ambiguity rather than clarity.

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?

Output schema exists, so return values need not be described, and the assumptions pointer plus the 'cite sources with income year / flag unverified' instruction are valuable. Against 19 parameters and 0% schema coverage, however, roughly half the inputs remain opaque, and the relationship to estimate_salary_tax is never resolved.

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 0% across 19 parameters, so the description must compensate. It does explain the highest-risk ones well (monthly_salary includes the employee's own pension share; pension_*_pct is a percentage of monthly_salary; bonus spread over bonus_payments; the share_withholding enum values), but leaves kommune, folkekirke_member, atp_full_time, other_deductions, bonus_has_pension, net_capital_income, vests_per_year, share_withholding_rate and within_15_years_of_pension entirely unexplained in both schema and prose.

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 a well-defined output set: predicts skattekort (trækprocent, månedsfradrag), normal-month and bonus-month payout, and year-end restskat from 2026 onwards. That is far more specific than the name alone. It does not, however, distinguish itself from the sibling estimate_salary_tax, which an agent could plausibly confuse with this 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?

Gives a clear use context ('questions about monthly take-home pay or what to enter in the forskudsopgørelse') and an operational rule: one scenario per call, call twice to compare when the include_*_in_forskud flags differ. Missing an explicit when-not / use-estimate_salary_tax-instead statement against the sibling 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?

With no annotations supplied, the description carries the full burden and does substantial work: it discloses the key output fields (til_udbetaling, effektiv_skatteprocent, marginalskat), the provenance behavior (source, verified date, status per figure, all_verified), and a 'Not tax advice' caveat. It does not state whether the tool is a pure computation with no side effects, nor any rate-limit or auth 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?

Purpose is front-loaded in a single opening sentence, and the per-parameter bullets are terse and scannable rather than prose-heavy. The length is justified by 14 parameters, though the final sentence partially restates output fields that an output schema already covers.

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 14-parameter, annotation-free estimation tool this is close to complete: input conventions, unit conventions, output highlights, provenance semantics and known limitations are all present. The remaining gap is that required kommune and several optional income/adjustment parameters are undefined, which for a domain-specific tax tool could lead to malformed calls.

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 0%, so the description must compensate and it largely does: gross_salary gets a precise inclusion/exclusion rule (own pension share included, employer share excluded, bonus and RSU vests count), and pension_own, pension_employer, private_ratepension, atp_full_time, atp_own, atp_employer and other_deductions are all given meaning the bare titles lack. Three non-obvious parameters — net_capital_income, other_personal_income and within_15_years_of_pension — receive no explanation at all, and kommune is left undefined despite a get_kommune sibling.

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: 'Estimate a single (unmarried) employee's Danish income tax for one year, with the full breakdown.' Scope and the single/unmarried restriction are explicit, and the closing 'Not covered' line further bounds it. It does not name the obvious sibling (estimate_payslip) or explain how the two differ, so it stops short of full sibling differentiation.

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?

'Use this instead of doing tax arithmetic yourself' plus 'All amounts are yearly DKK, not percent' and the percentage-to-kroner conversion instruction give clear operational context and prevent predictable input errors. Exclusions (married couples, aktieindkomst, ejendomsværdiskat) act as when-not guidance. What is missing is routing guidance toward get_kommune for the required kommune value or toward estimate_payslip.

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 no annotations at all, the description carries the full disclosure burden, and it handles the highest-risk trait well: values are raw as printed (percent as 12.01, not 0.1201; amounts in whole DKK), which prevents unit-scaling errors that annotations would never have covered. It also discloses that each figure carries provenance and a verification status. It does not say what happens when a key is unknown or unavailable for the requested year, which is the main remaining behavioral gap.

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?

Three short blocks, front-loaded with what the tool returns, then the value-format warning, then the discovery pointer. Every sentence earns its place: the scaling warning prevents a concrete error class, and the list_figures line prevents an invalid call. No restatement of the tool name 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?

An output schema exists, so the description is not obligated to document return values, yet it adds the one thing the schema cannot convey: the raw scaling convention and the presence of source/verified/status metadata. For a two-parameter lookup tool this is close to sufficient. Missing only failure behavior for unknown keys or years.

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 0%, so the description must supply meaning for both parameters. It does partially: "income year" clarifies the intent of year, and the list_figures pointer tells the agent where the keys vocabulary comes from. It never states the year format (four-digit calendar year vs. income/tax year bounds) or what a key string looks like, so half the semantic burden still falls on the caller.

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 verb and resource ("Get Danish tax figures for an income year") and immediately enumerates what comes back with each figure: source, verified date and status. That scope, plus the explicit pointer to list_figures for key discovery, lets an agent separate this retrieval tool from the sibling estimators without opening a 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?

It gives a concrete prerequisite and alternative: "Use list_figures to discover keys," which tells the agent it cannot call this blind with arbitrary key strings. It also prescribes post-retrieval behavior (cite source and income year, flag non-'verified' status). It stops short of saying when to prefer get_figures over estimate_salary_tax or estimate_payslip, so the boundary with the estimation siblings is left implicit.

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?

No annotations are supplied, so the description carries the full burden. It usefully discloses that percentages are printed in Danish decimal convention (24.52 = 24,52 %) and that kirkeskat only applies to Folkekirken members, which is genuine domain behavior. It does not state that this is a read-only lookup, where the data comes from, or whether all years/municipalities are 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?

Two short paragraphs, front-loaded with the core purpose and followed by the two clarifications that matter most (percentage format, kirkeskat membership caveat). No filler, though the four untranslated Danish tax terms are listed without any gloss for an agent unfamiliar with them.

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?

An output schema exists, so return values need not be described, and the domain caveats cover the trickiest interpretation issue. The notable gap is `year`: with two required parameters and no schema documentation, the description should say what years are valid and what happens for an unsupported year.

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 0%, so the description must explain both parameters. It does well for `kommune` by giving concrete examples ('Aarhus', 'Lyngby-Taarbæk'), including a hyphenated name. However, `year` is never mentioned at all — no format, no valid range, no indication of which years have data — leaving half the parameters undocumented.

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 verb and a precise set of resources (kommuneskat, kirkeskat, skatteloftsnedslag, grundskyldspromille), so an agent knows exactly what data is returned. It does not explicitly distinguish itself from siblings like estimate_salary_tax or get_figures, but the municipal-tax-rate scope is narrow enough to be 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 only implied: an agent can infer this is a per-municipality, per-year rate lookup. There is no statement of when to prefer it over estimate_salary_tax or estimate_payslip (e.g. 'use this to obtain rates that feed the estimators'), and no prerequisites or exclusions are given.

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 no annotations, the description carries the full burden, and it does disclose that this is a discovery/listing step returning keys with name and unit rather than values, plus the year-dependent variance in key sets. It omits safety/permission context and pagination or size behavior, which are minor for a small reference listing.

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?

Three short sentences, front-loaded with the core action and return content, then routing guidance, then the year-variance caveat. Nothing is redundant and no sentence could be dropped without losing 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?

An output schema exists, so return-value documentation is not required, and the description covers purpose, alternative routing, and year sensitivity. The remaining gap is the semantics of the year argument (calendar vs. income year definition, valid bounds), which the empty schema leaves entirely to the description.

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 0% for the single required integer `year`, so the description must supply meaning. It clarifies that the parameter is an income year and that different years yield different keys, but gives no valid range, format, or out-of-range behavior.

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 ("List the tax figure keys available for an income year") plus what each entry contains (name and unit). The second sentence explicitly distinguishes it from the sibling get_figures, so an agent can separate the two without opening either 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?

Gives an explicit workflow: use this to find keys, then call get_figures to fetch values. It also warns that the valid key set varies by year with concrete examples (2025 topskat vs. 2026 mellemskat/toptopskat), which tells the agent when a cached key list is unsafe to reuse.

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