Quellenkontor HR-Daten

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral detail beyond that: weekday vs. Saturday counting, subtraction of public holidays, and optional regional holidays.

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 short and front-loaded with the key constraint ('Nur Deutschland'). The English translation is somewhat redundant with the German sentence but is compact and harmless.

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 read-only calculation tool with a fully documented schema, the description is sufficient to select and invoke the tool. The verb 'Zählt' implies a numeric result, which compensates for the absence of an output schema.

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 does not add much parameter-level meaning beyond what the schema already documents for 'samstag' and 'regionale'; it mostly restates the same ideas.

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 operation: counting working days between two dates in a German Bundesland, excluding weekends and public holidays. It is specific and distinguishes itself from a pure holiday-list tool like hr_feiertage, though it does not name sibling tools 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 gives clear usage context: Germany only, by federal state, with optional Saturday and regional holiday handling. It does not explicitly state when not to use it or point to an alternative tool, but the scope is defined well enough for an agent to route appropriately.

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, and destructiveHint, so the safety profile is known. The description adds behavioral context: it specifies that periods apply from 2015 onward, notes the 2025 change (eight instead of ten years for vouchers), and cites legal bases (ArbZG, MiLoG). This goes beyond annotations by clarifying the data's scope and temporal limitations.

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 reasonably concise, front-loaded with 'Nur Deutschland', and lists the relevant categories. It includes a bilingual English translation which is slightly redundant but helpful for non-German speakers. It is structured and not overly long, with each sentence contributing content.

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 should ideally explain what the tool returns. It describes the data (retention periods) but does not explicitly state the format (e.g., text, table) or whether it returns results for a specific date or all categories. It also doesn't mention edge cases or error conditions. Given the tool's simplicity, this is a minor gap, but it is still incomplete.

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% with descriptions for both datum and bestandteil. The tool description adds value by listing the document categories in German (Lohnkonto, Buchungsbelege, Bücher und Abschlüsse, Geschäftsbriefe, Arbeitszeitnachweise) which map directly to the enum options, and by stating 'ab 2015' which constrains the datum parameter. This enriches understanding 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 clearly states the tool's function: it provides retention periods for personnel and payroll documents in Germany, listing specific document types (Lohnkonto, Buchungsbelege, etc.) and the time frame (since 2015). It also includes an English summary. This is specific and distinct from sibling HR tools which cover other topics like taxes, leave, 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 description gives clear context: it is for Germany and covers retention periods. It does not explicitly name alternatives or say when not to use it, but the scope is so specific that an agent can infer when to choose it. The constraint 'Nur Deutschland' and the listing of covered categories provide sufficient guidance without explicit exclusions.

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 indicate the operation is read-only, idempotent, and non-destructive. The description adds useful context beyond these flags: Germany-only applicability, the specific legal basis, and the optional yearly-levy approximation behavior. No behavioral claim contradicts the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is relatively short and front-loaded with 'Nur Deutschland.' However, the German sentence trails off with 'aus …' before switching to an English restatement, and the bilingual duplication is not fully streamlined. The truncated phrase and slight redundancy keep it from scoring higher.

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 absence of an output schema and the optional parameters, the description gives enough orientation: legal basis, Germany-only scope, quota/small-employer outputs, and the optional yearly-levy approximation. The schema covers parameter semantics, so the intended computation is adequately clear for an agent to invoke the 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 each parameter (jahr, datum, besetzt, bestandteil, arbeitsplaetze) has its own meaningful description. The tool description adds only high-level context about quota rates and the yearly-levy approximation, so it does not need to repeat parameter-level detail; 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 explicitly names the legal concept (Ausgleichsabgabe under § 160 SGB IX), the jurisdiction (Germany), and the expected outputs (amounts per employment-rate bracket, small-employer amounts, optional yearly-levy approximation). This is specific enough to distinguish it clearly from all siblings in the HR legal-reference tool set.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides a clear geographic restriction ('Nur Deutschland') and a temporal scope ('für ein Kalenderjahr ab 2015'), which helps an agent decide when this tool applies. It does not explicitly name alternative sibling tools, but the subject matter is unique enough among the siblings that this 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds context such as Germany-only scope and that amounts are calculated from the contribution assessment ceiling. It does not contradict annotations, and the extra context is useful but not extensive.

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 moderately long, includes both German and English text, and is truncated with an ellipsis, which reduces clarity. It starts with the key constraint (Germany-only) but then lists many details without clear structure. It is not overly verbose, but the duplication in two languages and truncation make it less concise than ideal.

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, and the description does not explain what the tool returns when no bestandteil is specified, the return format, or whether it returns all components by default. This is a significant gap for an agent that needs to interpret the tool's response 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 each parameter is already documented. The tool description adds legal references (e.g., § 3 Nr. 63 EStG, § 1 SvEV) that provide background on the values, but it does not add per-parameter semantics beyond what the schema provides. 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 identifies the tool as providing maximum amounts for company pension provision in Germany, naming specific components like tax-free and social security-free amounts under § 3 Nr. 63 EStG and § 1 SvEV. It distinguishes itself from general tax or social security tools by focusing on bAV, so an agent can tell it apart from siblings like hr_beitragssaetze.

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 guidance is given on when to use this tool versus alternatives. It does not mention any conditions, exclusions, or compare with sibling tools. The description only states what it returns, leaving the agent to infer usage context without clear selection criteria.

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 establish read-only, idempotent, non-destructive behavior, so the description only needs to add context. It adds meaningful scope: data is valid only for Germany, federal/uniform, at one Stichtag, and includes specific contribution components. It does not describe edge cases like dates before 2015, but that is beyond the safety profile.

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 compact and front-loaded with key constraints: Germany, federal uniform rates, single date, since 2015. The bilingual repetition of the insurance list is mildly redundant but not bloated. Every sentence carries meaningful scope 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?

For a simple one-parameter read-only tool with no output schema, the description conveys the data content (which insurances, employer/employee shares) and the temporal/geographic boundaries. It does not need to explain return values because the description already enumerates the returned items. Missing details like pre-2015 behavior are minor for a Stichtag-based lookup.

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 documents the optional 'datum' parameter with format and default behavior, so the baseline is 3. The description reinforces the semantic that rates apply at one Stichtag and only from 2015, slightly contextualizing the parameter. No additional format or value details are 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 names the exact resource: uniform German social insurance contribution rates (health, pension, unemployment, long-term care) at a single cutoff date from 2015. The 'Nur Deutschland' constraint and the insurance list clearly scope it away from sibling HR tools. It lacks an explicit verb like 'returns/retrieves', but the resource and content are 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 usage for querying German statutory contribution rates at a single date, with explicit constraints 'Nur Deutschland' and 'ab 2015'. It provides no exclusions or comparisons to sibling tools such as hr_rechengroessen or hr_mindestlohn that might be confused. The guidance is present but mostly left to inference.

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, and destructiveHint=false, so the safety profile is covered. The description adds useful context about the calculation basis (Beitragsbemessungsgrenze) and the regional distinction for long-term care insurance (bundesweit vs Sachsen). However, it does not disclose the default date behavior (schema does), the 'at most half' cap when actual contributions are provided, or potential error conditions like dates before 2015, so it only partially enriches the behavioral picture.

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 sentence that mixes German and English, and it trails off with 'und …' and 'contribution …', indicating truncation. It front-loads the 'Nur Deutschland' constraint but then packs the calculation logic into a run-on structure. It is not an egregiously long description, but the bilingual duplication and incompleteness hurt readability and structure.

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 carries the full burden of explaining what the tool returns. It mentions the maximum subsidy amount but does not mention the output field names (zuschuss_kv_monat, zuschuss_pv_monat) or how the response changes when optional contributions are provided. It also omits important operational details such as the date range validity (ab 2015) and what happens for earlier dates. These are significant gaps for a calculation tool with no structured output definition.

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 each parameter is already documented with meaning and effect. The description adds only marginal context by framing the parameters as 'Monatsbeitrag' and 'Stichtag', but it mostly repeats or implies what the schema states. It does not explain how the optional contributions interact with the maximum, such as the half-contribution cap, which is already in the schema descriptions. Therefore, a baseline 3 is appropriate.

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

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

The description states a specific verb ('berechnet' / 'calculated') and a clear resource: the maximum monthly employer subsidy for private health and long-term care insurance since 2015. It names the calculation basis (contribution assessment ceiling) and the two insurance types, which distinguishes it from sibling tools like hr_beitragssaetze or hr_bav_hoechstbetraege. However, the description is truncated ('und …') and mixes German and English, which slightly reduces clarity about the exact 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 only usage guidance is the constraint 'Nur Deutschland' and 'ab 2015'. It does not explain when to use this tool versus alternatives, when to provide the optional contribution parameters, or what the returned values mean in different scenarios. There is no mention of exclusions or prerequisites beyond the date and location, leaving the agent without clear decision criteria.

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 establish readOnly, idempotent, and non-destructive behavior; the description adds domain context beyond that, such as the specific tax rules (1%, 0.03%) and the relevance of acquisition date for electric/hybrid reductions. This helps the agent understand what kind of calculation is being performed and what inputs influence 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 redundant and structurally broken: it repeats content in German and English, ends with an incomplete parenthetical ('Viertel, Hälfte, …'), and mixes languages mid-sentence. It is front-loaded with the key action, but the duplicated and truncated text adds noise and reduces 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?

For a tool with 11 parameters and no output schema, the description gives a useful high-level overview but leaves gaps: it does not clarify the return format, fully explain how the 1% and 0.03% rules interact, or complete the reduction description. The rich input schema compensates for many parameter details, but the truncated and bilingual description prevents full completeness.

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. The description adds meaningful context beyond the schema by explaining the tax-rule framework and why parameters like acquisition date or drive type matter for the reduction. It does not enumerate every parameter, but it gives interpretive meaning that the schema alone lacks.

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 verb and resource: it calculates the monthly taxable benefit of a company car under the 1% rule and the 0.03% commuting rule, including electric/hybrid reductions. This clearly distinguishes it from the sibling HR calculators, none of which handle company-car taxation.

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 stating its calculation scope and the 'Nur Deutschland' constraint, but it gives no explicit when-to-use guidance or exclusions, and it does not name alternatives. An agent can infer the use case from the purpose, but the description does not actively route the agent.

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 establish that the tool is read-only, idempotent, and non-destructive. The description adds meaningful context about Germany-only scope, the time range, and the tax components included, but it does not describe output shape, default behavior when jahr is omitted, or how a single component can be selected.

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 compact and front-loaded with the key scope limitation, 'Nur Deutschland.' However, the German text trails off at 'Freigrenze und Satz des …', leaving a dangling fragment, and the English translation partially repeats the same content without adding structural 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?

For a read-only reference tool with no required parameters reasonably safe annotations, this description is nearly complete: it states the country, the time window, and the exact set of returned values. The remaining gaps, such as explicitly mentioning the optional bestandteil filter or clarifying response format, are minor because the schema already documents parameter behavior.

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

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

The input schema has 100% parameter description coverage, including the jahr default, the datum alternative, and the full bestandteil enum. The description lists several of the returned tax values but adds no new parameter-level meaning 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 identifies the resource: Eckwerte der Einkommensteuer for Germany since 2015, and enumerates specific figures such as Grundfreibetrag, Spitzensteuersatz, and child allowance. It does not use an explicit verb like 'returns' or 'lists', and it does not explicitly differentiate the tool from siblings such as hr_steuerfreie_betraege or hr_beitragssaetze, so it stops short of a 5.

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 use case: retrieving German income tax key values for a year. It does not state exclusions, preferred conditions, or mention alternative sibling tools, leaving an agent to infer when this tool should be chosen over similar HR/finance reference 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond that: the results depend on the child's birth date and which BEEG version applies, and the tool is Germany-only. It does not describe output language or what happens when no parameters are passed, but for a read-only lookup with this annotation coverage, the added context 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 German portion is dense and front-loaded (scope, law, key numbers), which is efficient. But the English translation largely duplicates the German content and is truncated mid-sentence ('by the …'), which is a structural flaw, and the bilingual repetition adds length without new 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?

For a read-only legal reference with two fully documented optional parameters and strong annotations, the description is close to adequate. It covers the main content areas but is visibly truncated, and it does not state the default behavior when no enumerator component is given (e.g., whether all components are returned) or how results are delivered.

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% (both parameters have descriptions), so the baseline is 3. The description adds genuine meaning on top by mapping concrete legal values to the enum components (Anmeldefristen 7/13 Wochen, Kündigungsschutz 8/14 Wochen) and by tying the geburtsdatum parameter to which BEEG version applies — interpretation the schema alone does not provide.

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 resource ('Elternzeit nach dem BEEG') and enumerates concrete contents (maximum duration 3 years, transferable portion 12/24 months, notice periods 7/13 weeks, dismissal protection lead times), which clearly distinguishes it from sibling tools like hr_mutterschutz or hr_kuendigungsfrist. It lacks an explicit verb (calculate/look up), but the reference-tool purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the subject matter: the tool answers parental-leave questions under the BEEG for Germany, and the 'Nur Deutschland' note imposes a geographic scope. However, there is no explicit when-to-use vs. alternative routing (e.g., pointing to hr_mutterschutz for maternity-protection questions) and no mention of prerequisites or edge cases like children born before 2007.

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 establish read-only, idempotent, non-destructive behavior. The description adds substantial context beyond that: the legal basis (EFZG), temporal scope (ab 2015), geographic restriction, and the specific rule content (six weeks, four-week waiting period, six/twelve-month deadlines, 100% pay, medical certificate). This gives the agent a clear picture of what information the tool will expose.

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 compact and front-loads the jurisdiction, but it is somewhat messy: the German sentence trails off with 'ärztliche Feststellung bei …' and the English sentence largely restates the German list. It is not poorly sized, but the truncation and redundancy make it less polished than it could be.

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 only two optional parameters, no required inputs, and no output schema, the tool is simple. The description adequately conveys the subject matter, but it does not explain the behavior when 'bestandteil' is omitted (returning all components) or clarify that the 'datum' parameter may affect which legal status applies. These are not fatal gaps but are left to inference.

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 adds value by mapping the enum ids in 'bestandteil' to human-readable, bilingual topic summaries (Duration, waiting period, deadlines and proof), which helps an agent interpret concepts like 'fortsetzung_pause' or 'bescheinigung_ab_dauer_ueber' that are otherwise opaque in 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 clearly identifies the tool as providing legal reference information on Entgeltfortzahlung under the German EFZG since 2015, and enumerates the specific topics it covers (duration, waiting period, deadlines, pay percentage, proof). It is not a tautology and is distinct in subject matter from siblings like hr_krankengeld, though it does not explicitly name a sibling or draw the boundary.

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 helpful context ('Nur Deutschland', EFZG, since 2015) and implies the tool is for questions about continued pay during sickness. However, it provides no explicit guidance on when to choose this tool over closely related siblings such as hr_krankengeld, and no when-not-to-use or alternative routing.

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 mark the tool as read-only, idempotent, and non-destructive. The description adds useful context that results are date-specific ('an einem Stichtag ab 2017') and limited to Germany, but it does not disclose return format or edge cases. The annotation coverage lowers the burden, so a mid-range score 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?

The description is compact and front-loads the key constraint ('Nur Deutschland') and core thresholds. The bilingual repetition is somewhat redundant, but it remains readable and not bloated.

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 read-only legal reference tool with no output schema, the description covers the main legal components and thresholds: 200/500 employees, 5/3-year reporting cycle, and the EU directive. It does not explicitly describe return values or the optional 'bestandteil' filter, but those are covered by the schema.

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

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

Schema description coverage is 100%, so the schema already documents 'datum' and 'bestandteil' with formats and enum values. The description adds no parameter-level detail, but none is needed beyond what the schema 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 identifies the tool's subject: German Pay Transparency Act thresholds and reporting duties at a reference date, plus EU Directive 2023/970. It is specific enough to distinguish from generic HR tools, though it does not explicitly name a sibling like hr_schwellenwerte_arbeitsrecht and lacks an explicit verb such as 'returns' or 'calculates'.

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 guidance is given on when to use this tool versus alternatives. It only states 'Nur Deutschland' and the legal scope, leaving the agent to infer usage from the topic rather than providing exclusions or sibling references.

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, and no destructive behavior, so the safety profile is covered. The description adds context by bounding the range to 2015–2035, limiting to Germany, and revealing that output includes weekdays, regional holidays, and one-time holidays.

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 short and front-loaded with the scope ('Nur Deutschland'), then the resource, parameters, and output elements. The English sentence is a near-duplicate but serves the bilingual audience; overall there is minimal waste.

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 simple read-only lookup with two optional parameters and no output schema, the description is largely complete: it states country, year range, federal-state selection, and key output features. It does not spell out the exact response shape or clarify 'einmalige Feiertage' further, but the missing detail is minor.

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 describes both parameters fully (range, enum, examples, defaults such as DE/current year), so baseline 3 applies. The description adds no meaning beyond what the schema already states, only repeating the Bundesland abbreviations and year bounds.

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 a statutory-holiday data resource for Germany, with year and state scope and recognized output elements (weekday, regional and one-off holidays). It is not a tautology and distinguishes the tool from typical HR calculators, but it lacks an explicit verb like 'get/list' and never compares itself to 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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative sibling tool is mentioned even though 23 related HR tools exist. 'Nur Deutschland' and the parameter hints describe scope and options rather than decision rules for selecting 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?

Annotations already provide readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds legal scope and time-frame context ('SGB V ab 2015'), but does not disclose output behavior, response shape, or edge cases such as invalid dates.

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 redundant: the German content is repeated in English, and it ends with an incomplete phrase 'dazu Kinderkrankengeld mit 90 …'. It is not tightly structured and contains filler rather than earning every sentence.

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?

As a simple read-only reference tool with fully documented parameters, the description is adequate. However, it does not explain how the optional bestandteil filter affects the result, what the output format is, or how the datum parameter interacts with the stated 'ab 2015' scope.

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 both parameters (datum and bestandteil) are already documented in the input schema. The description does not add meaningful parameter-level semantics beyond what the schema 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 subject: German statutory sickness benefit (Krankengeld) and child sickness benefit (Kinderkrankengeld), including the relevant legal sections and specific rates/caps/duration. This is specific enough to distinguish it from sibling tools like hr_entgeltfortzahlung or hr_mutterschutz.

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 usage guidance is provided beyond the geographic scope 'Nur Deutschland'. The description does not say when to choose this tool over related siblings, nor does it mention exclusions or typical use cases.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the legal basis and country restriction, and clarifies it computes statutory (not contractual) notice periods. It does not contradict annotations and provides useful context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is two sentences (German and English), front-loaded with the core function, and contains no filler. Every word serves a purpose, making it efficient 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?

For a read-only calculator with no output schema, the description adequately conveys inputs and what it returns (notice period and end date). It could specify the output format (e.g., months or date) but the intent is clear. Given the simplicity and annotation coverage, the description is complete enough.

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 all parameters are already documented in the schema with descriptions. The description only restates parameter names (Eintrittsdatum, Zugang, Probezeit, Seite) without adding additional meaning or clarifying edge cases. Baseline 3 is appropriate since the schema carries the semantic 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 clearly states the tool calculates the statutory notice period and end date under § 622 BGB, with specific inputs (start date, receipt date) and options (probezeit, Seite). It names the legal basis and distinguishes this tool from siblings like hr_urlaubsanspruch or hr_mindestlohn, which cover different HR topics.

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 explicitly restricts to Germany ('Nur Deutschland') but does not explicitly mention alternatives or exclusions. However, given the sibling list, this is the only tool for notice periods, so usage context is clear enough. It could have stated 'use for statutory notice period calculations' but the purpose implies it.

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 tool read-only, idempotent, and non-destructive. The description adds meaningful behavioral/data-scope context beyond that: Germany-only coverage, inclusion of announced future years ('verkündete Folgejahre eingeschlossen'), and the percent unit. It does not disclose return structure or error behavior, but for a simple lookup these are minor gaps given the strong annotation coverage.

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 compact, front-loads the geographic restriction, and gives the core definition before supplementary context. The bilingual English translation duplicates the German content and the payer sentence is background rather than call-critical, introducing slight redundancy, but it remains efficient and scannable.

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 simple read-only lookup with zero required parameters, fully documented optional parameters, and comprehensive annotations, the description covers the essential facts: what is returned (a percentage rate), the temporal and geographic scope, and the legal context. Without an output schema, a description of the exact response shape would be nice, but the expected value is simple enough that the gap is minor.

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%; jahr, datum, and bestandteil each have descriptions covering ranges, formats, defaults, and allowed values. The tool description adds no parameter-level detail, so the schema carries the full burden, which fits the baseline-3 case exactly.

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 names the resource – the Künstlersozialabgabe rate in percent per calendar year since 2015 – and scopes it to Germany ('Nur Deutschland'). It does not state an explicit verb like 'liefert' or 'returns', and it does not explicitly distinguish itself from siblings such as hr_beitragssaetze or hr_ausgleichsabgabe, though the specific levy makes the purpose reasonably 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 provides contextual signals that help an agent infer when to use the tool (needing the artists' social security levy rate in Germany for a given year) but never states explicit when-to-use versus alternative conditions. It names no sibling tools or exclusions, leaving usage guidance 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds contextual constraints (Germany, since 2015) and legal basis, but does not disclose any additional behavioral traits like rate limits, auth requirements, or side effects. This aligns with annotations; no contradiction.

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 moderately concise but includes both German and English text with an ellipsis, making it slightly longer than necessary. It is front-loaded with 'Nur Deutschland' and the legal reference, but the dual-language redundancy reduces efficiency.

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 read-only, informational tool with no output schema and fully documented parameters, the description is fairly complete. It states the legal basis, scope, and key concepts, which is sufficient for an agent to understand what it returns. The only minor gap is a lack of explicit mention of the output format, but that is not required given the absence of an output schema.

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%, and the description does not significantly expand parameter meaning. It mentions concepts like 'Grenzen' and 'Schonfrist' that map to enum values, but this is redundant with the schema. The baseline 3 applies because the schema carries the full documentation.

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: it provides German wage tax (Lohnsteuer) filing periods and deadlines according to § 41a EStG, with specific scope (since 2015) and topics (limits for monthly/quarterly/annual returns, filing day, grace period). This is specific and distinguishes it from sibling tools like hr_arbeitstage or hr_mindestlohn, which cover different HR topics.

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 context (only Germany, since 2015) but does not explicitly state when to use this tool versus alternatives or when not to use it. It implies usage through the distinct topic, but there is no direct guidance on selection or exclusions.

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, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by specifying the legal basis (§17 BBiG), the time period (since 2020), and that amounts are in euros per month. It does not contradict annotations and provides useful context beyond what annotations convey.

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 compact, two sentences (German and English), and front-loaded with the core purpose and scope. It avoids unnecessary detail and is easy to parse quickly, with no wasted words.

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 simple lookup tool with no required parameters and no output schema, the description is complete enough. It states the output is the statutory pay per training year and the dependency on start year. The schema covers parameter semantics, and annotations cover safety. Minor gaps like explicit mention that all four years are returned by default are implied by the schema.

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

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

Schema description coverage is 100%, with each parameter already documented in the schema. The description adds no additional meaning beyond restating the dependency on start year, which is also in the schema. Thus it meets the baseline of 3 but does not exceed it.

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 the statutory minimum pay for apprentices (Mindestausbildungsvergütung) per training year, based on §17 BBiG, for Germany since 2020. It specifies the resource (apprentice pay), the action (provides amounts), and the scope (per year, by start year), distinguishing it from general minimum wage tools like hr_mindestlohn.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context (Germany, apprentices, start year) but does not explicitly state when to use this tool versus alternatives like hr_mindestlohn. It mentions 'Nur Deutschland' as a constraint but does not provide exclusions or alternative guidance, leaving the choice to inference.

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 readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral context: the tool covers only Germany, accepts dates back to 01.01.2015, and includes legislated future minimum-wage stages. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is compact and front-loaded with the key constraint 'Nur Deutschland'. The German and English versions repeat the same information, which is slightly redundant but improves accessibility for multilingual agents without adding significant bulk.

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 simple, single-parameter lookup tool with strong annotations, the description is complete: it states the geographic scope, the exact values returned, the valid date range, and the inclusion of future stages. Nothing essential is missing for correct invocation.

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% and the single optional datum parameter is already well documented with format and default behavior. The description adds extra meaning by defining the valid date range (from 2015) and noting that future legislated stages are included, which the schema alone does not convey.

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 resource: Germany's statutory minimum wage (Mindestlohn) and mini-job earnings limit (Geringfügigkeitsgrenze), with the relevant units and date scope. It distinguishes itself from siblings like hr_pflegemindestlohn and hr_minijob_abgaben by naming the exact legal values it returns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: Germany only, valid for dates from 2015 onward, including already legislated future increases. It does not explicitly name sibling alternatives or state when not to use it, but the scope is specific enough for an agent to select it appropriately.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the operation is safe and deterministic. The description adds valuable context beyond annotations: it specifies the geographic restriction (Germany) and the date constraint (from 2015), which are not in annotations. It also lists the components returned, giving the agent an idea of the data scope. No contradictions with annotations exist.

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-loading the critical restriction 'Nur Deutschland' and the date scope. The German and English versions together are efficient, though the English translation repeats the German content, which is slightly redundant but not wasteful. The colon-separated list of components is well-structured and scannable.

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 tool has no output schema, and the description does not explain the return format or whether it returns a single value or a list. However, with zero required parameters and a well-defined schema for optional parameters, an agent can reasonably infer the tool returns contribution values for the requested date/component. The description covers the core purpose and constraints but lacks details on response structure, which is a minor gap given 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 input schema has 100% coverage with clear descriptions for both parameters: 'datum' (date in YYYY-MM-DD format, defaults to today) and 'bestandteil' (enum of component IDs). The description mentions 'an einem Stichtag' (at a date) and lists the components, but these are already captured in the schema. The description adds minimal extra semantics beyond the schema, so the baseline score of 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 provides employer flat-rate contributions, taxes, and levies for mini-jobs in Germany, listing specific components (health and pension insurance, flat-rate tax, U1/U2 levies). This is a specific resource and action, distinguishing it from sibling tools like hr_beitragssaetze which cover general contribution rates. The bilingual format ensures clarity for both German and English agents.

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 explicitly states 'Nur Deutschland' (only Germany) and 'an einem Stichtag ab 2015' (at a cutoff date from 2015), giving clear context for when the tool is applicable. It does not explicitly name alternative tools or state when not to use it, but the scope is narrow enough that an agent can infer its use for mini-job contribution queries. A clear exclusion of non-German contexts and pre-2015 dates is 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?

Annotations already mark the tool as read-only and idempotent, and the description adds meaningful domain context beyond them: the legal basis (§ 3 MuSchG), the Germany-only limitation, and the special-case threshold 'Fehlgeburt ab der 13. Woche'. No contradiction with the annotations; it could only be improved by stating expected output format or behavior when required inputs are missing.

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 German sentence is compact and front-loaded with the scope ('Nur Deutschland') before the action. The English restatement is slightly redundant, but it is short and useful for cross-language agent comprehension; there is no vague 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?

For a four-parameter calculator with fully described schema entries and safe, read-only annotations, the description covers what is computed, from which inputs, and for which jurisdiction. Since there is no output schema, the phrase 'Beginn und Ende der Mutterschutzfristen' sufficiently signals the return semantics.

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 adds meaning by grouping the inputs into a calculation narrative: expected due date, optional actual birth date, and optional special case. It also introduces the 13-week Fehlgeburt boundary, which is not directly visible in the parameter 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 verb ('Berechnet') and a precise legal resource ('Beginn und Ende der Mutterschutzfristen nach § 3 MuSchG'), so it is immediately clear what the tool computes. The Germany-only scope and the named special cases make it unmistakably distinct from the other HR calculator siblings.

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 clear usage context: only for Germany, based on the expected due date, with optional actual birth date and special cases such as Frühgeburt, Mehrlinge, Behinderung, and Fehlgeburt ab der 13. Woche. It does not explicitly name an alternative tool or say 'use X instead', but the scope and input conditions are clear enough for an agent.

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, and destructiveHint=false, so the safety profile is covered. The description adds two behavioral constraints: it is limited to Germany and only applies from 2015 onward. It does not describe return format or error handling, but the annotation coverage reduces the burden.

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 sentence with an appended list of examples and an ellipsis. It is moderately sized but somewhat unstructured, and the trailing '…' gives an unfinished impression. It could be more organized.

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 the tool returns. It mentions rates but never explicitly states that it returns a specific rate for a requested component, nor does it cover behavior for invalid dates or absent data. The listed components are partial, relying on the schema to fill gaps.

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 parameters are well-documented in the schema. The description only repeats a subset of the enum values without adding further semantic detail, so it provides no additional value 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 clearly identifies the subject matter (flat tax rates under § 40 EStG) and provides examples, distinguishing it from other HR tools. However, it lacks an explicit verb like 'returns' or 'provides', making the exact operation slightly ambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states 'Nur Deutschland' but offers no guidance on when to use this tool versus related siblings like hr_einkommensteuer_eckwerte or hr_steuerfreie_betraege. There is no mention of exclusions or alternative conditions.

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 establish that this is read-only, idempotent, and non-destructive, so the bar for the description is lower. The description still adds meaningful behavioral context by stating the legal source, the 6- and 9-hour thresholds, and that it also covers maximum working time and rest periods.

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 compact, front-loaded with jurisdiction and legal basis, and includes only a short bilingual restatement. The German and English versions overlap, which costs a little efficiency, but overall the structure is clear and scannable.

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

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

For a two-parameter, read-only calculator with a fully described schema and no output schema, the description provides the necessary legal and selection context. It does not spell out the exact return shape or units, but the intended result is strongly inferable from the stated purpose.

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 parameter names and descriptions already carry most of the semantic weight. The description goes beyond the schema by explaining how arbeitszeit_stunden maps to break thresholds and how jugendlich selects the JArbSchG branch, giving the agent useful calculation context.

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's domain and output: statutory minimum breaks and working-time limits under German law, covering both adults and young employees. It references specific legal sections and concrete break thresholds, so an agent can distinguish it from sibling HR tools, though it lacks an explicit verb like 'berechnet'.

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 explicitly limits the tool to Germany ('Nur Deutschland') and clarifies when youth regulations apply via the jugendlich parameter. It gives enough context for correct routing to this tool among the HR siblings, although it does not explicitly name alternatives or exclusions.

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 mark the tool as read-only and idempotent. The description adds meaningful behavioral context by disclosing that dates are shifted after weekends and that legal bases are included. It also states the Germany-only scope. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is compact and front-loads the Germany-only scope, then uses a concrete list of deadline types to convey coverage. The German and English versions repeat content, which is slightly redundant but useful for an international agent.

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 read-only calendar tool with no output schema, the description conveys the essential return content: deadlines, actual dates, and legal basis. The schema covers all five optional parameters. It does not describe output structure or sorting, but nothing critical is missing.

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

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

Schema description coverage is 100%, and the schema already documents jahr, land, kategorie, land_einzugsstelle, and lohnsteuer_zeitraum in detail. The description adds no parameter-level semantics beyond that, so the baseline of 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?

The description clearly states the resource and deliverable: all fixed payroll deadlines in a year, with actual dates after weekend shifts and the legal basis. The title reinforces 'Lohnjahr-Kalender', and the enumerated deadline categories distinguish it from single-topic siblings like hr_lohnsteuer_anmeldung or hr_sv_faelligkeit.

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 establishes the intended use: obtaining a comprehensive annual calendar of fixed payroll deadlines for Germany. It does not explicitly name when not to use it or point to alternatives, but the 'Alle festen Fristen' framing provides a clear context that separates it from more specialized 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: the legal basis (§ 850c ZPO), the date constraint (Stichtag ab 2015), the cap at five dependents, and the conditional behavior when net income is provided. This goes beyond the annotations and helps the agent understand what the API computes.

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 compact and front-loaded with the key constraint (Nur Deutschland) and the legal basis. The English translation at the end is slightly redundant but helps non-German-speaking agents. Every sentence earns its place, though the bilingual structure adds a little length without much new 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?

For a read-only, idempotent lookup tool with no output schema and fully documented parameters, the description covers the essential context: legal basis, date range, optional inputs, and the five-dependent cap. It does not describe the return format, but since there is no output schema and the tool is a simple lookup, the description is sufficiently complete for an agent to call it 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 the schema already documents all three parameters with formats, ranges, and examples. The description adds the legal cap at five dependents and the conditional calculation when netto is provided, which is useful but not extensive. Baseline 3 is appropriate because the schema carries the heavy lifting and the description adds only marginal semantic 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 states a specific verb and resource: it provides Pfändungsfreigrenzen for earned income under § 850c ZPO at a cutoff date from 2015 onward. It also clearly distinguishes itself from the sibling tools, which cover other HR topics like minimum wage, holidays, or travel costs. The optional net income and dependent count behavior is explicitly mentioned, so an agent can tell exactly what this tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: Germany-only, cutoff date from 2015, and optional parameters for dependents and net income. It does not explicitly name alternatives or say when not to use this tool, but the sibling list makes the domain clear and the description implies the use case. A small gap is the lack of explicit exclusion guidance, but the context is strong enough for an agent to select it correctly.

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, and destructiveHint=false, covering the safety profile. The description adds context about the data range (since 2015, East Germany until 2021) and extra vacation, but does not disclose additional behavioral aspects like rate limits or response format. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is fairly concise but has a truncated part ('nach der …') that leaves the sentence incomplete. It mixes German and English, which is acceptable but not ideal. The key information is front-loaded, but the incomplete phrase detracts from structure.

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 is incomplete due to the truncation, and it does not explain what the tool returns (e.g., a value, a list, or a breakdown). Given the tool's complexity (multiple qualifications, date-based values, extra vacation), the description lacks sufficient detail to fully guide an agent. No output schema exists, so the description should compensate, but it falls short.

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% for both parameters (datum and bestandteil), with clear descriptions in the schema. The description mentions 'by qualification' which aligns with the bestandteil enum but does not add new information beyond the schema. 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 provides minimum wages in long-term care (Pflegemindestlohn) for Germany, broken down by qualification, plus extra vacation, since 2015. It uses a specific verb ('provides' implied) and resource, and the mention of 'Pflegemindestlohn' distinguishes it from general minimum wage tools like hr_mindestlohn.

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 for long-term care minimum wage queries but does not explicitly state when to use this tool versus alternatives like hr_mindestlohn or hr_mindestausbildungsverguetung. It mentions 'Nur Deutschland' but no explicit when/when-not guidance or alternative names.

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, and destructiveHint=false, covering the safety profile. The description adds useful context about the data scope (West and East) and the types of values included, which goes beyond the annotations. It does not disclose any unexpected behaviors or side effects, but none are expected given the read-only, idempotent nature.

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 concise, with two short sentences that immediately state the scope and content. It is front-loaded with the key constraint ('Nur Deutschland') and lists specific items. The English translation is redundant for German speakers but may aid international agents; still, it does not waste space. The trailing '…' is slightly ambiguous but acceptable.

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 simple read-only retrieval tool with two optional parameters and no output schema, the description gives the core content and scope. However, it does not describe the output format or structure (e.g., whether it returns a list, a map, or separate West/East values), nor does it clarify the meaning of 'reference value'. While not severely incomplete, it leaves some ambiguity for an agent expecting a concrete response shape.

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 complete descriptions for both parameters (jahr and datum), including defaults and alternatives, with 100% coverage. The description adds no additional parameter-level meaning beyond what the schema already states. Baseline 3 is appropriate because the schema fully documents the 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 clearly states the tool returns social insurance contribution ceilings (BBG), compulsory insurance threshold (JAEG), and reference values for Germany, for years from 2015 onward. It names specific resources and is distinct from sibling tools like hr_beitragssaetze (rates) or hr_einkommensteuer_eckwerte (tax key figures).

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 a usage constraint ('Nur Deutschland') and the scope of what it covers, but it does not explicitly state when to use this tool versus alternatives or when not to use it. There is no reference to sibling tools that might be more appropriate for different needs (e.g., contribution rates). The guidance is implied rather than explicit.

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

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

Read-only and idempotent behavior is already covered by annotations, and the description adds what the tool produces: the retirement age, the date it is reached, and the earliest possible start. It also discloses the calculation rule and legal basis, which is context an agent cannot infer from annotations alone.

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 German description is front-loaded with scope and calculation details and packs the essential formula into one sentence. It loses a point for including a largely redundant English restatement and for the ellipsis after frühestmöglichen Beginn.

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 does enough by naming the three computed results and the legal rule. The schema covers the parameters, and annotations cover safety, so the main remaining gap is not explicitly spelling out the geburtsjahr/geburtsdatum alternative, though the schema descriptions already imply it.

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

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

Schema description coverage is 100%, so the schema already explains geburtsjahr, geburtsdatum, and vertrauensschutz. The description only loosely maps to them via Geburtsdatum and Jahrgänge, adding no new parameter-level 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?

The description names a concrete action (Berechnet), a specific resource (Regelaltersgrenze der gesetzlichen Rentenversicherung based on Geburtsdatum), and a hard scope (Nur Deutschland). The formula and legal basis further disambiguate it from all hr_* siblings.

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?

Nur Deutschland and the reference to § 235 SGB VI give a clear use context, and the formula says exactly which birth cohorts it applies to. It does not name an alternative tool or an explicit not-when condition, but no sibling appears to offer the same retirement-age calculation, so this is a minor omission.

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, and destructiveHint=false, so the safety profile is covered. The description adds useful context: the tool is Germany-only, applies to a Stichtag (cutoff date) from 2015 onward, and covers specific allowance components. It does not disclose return format or whether results are rounded, but the annotations carry the main behavioral burden.

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 compact and front-loaded with the key scope ('Nur Deutschland'). The German text is dense but informative, and the English summary adds clarity. It could be slightly more structured, but every sentence 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 read-only, idempotent lookup tool with two optional parameters and full schema coverage, the description is largely complete. It covers the domain, the date scope, and the main components. It does not explain the return value shape, but there is no output schema and the tool is a simple lookup, so this is a minor gap.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds the German-only scope and the 'since 2015' constraint, which helps interpret the datum parameter, but it does not add meaning beyond the schema for bestandteil. Baseline 3 is appropriate.

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

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

The description states a specific resource (German domestic travel expense per diems since 2015) and a clear verb context (providing/calculating allowances). It lists the main components (meal allowances, overnight stays, mileage) and explicitly scopes to Germany. It doesn't explicitly differentiate from siblings, but the resource is distinct enough among the HR 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 implies usage for German domestic business trip per diems and mentions the date threshold 'since 2015'. It does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. The sibling list contains no other travel-expense tool, so the lack of explicit alternatives is a minor 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?

Annotations already mark the tool as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds useful context about legal basis and output granularity, but it does not describe the return shape or default-year behavior, which is a minor gap given the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is compact and front-loaded with the most important scope constraint ('Nur Deutschland'). The English translation repeats the German content and is not strictly necessary, but it does not make the description bloated.

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 read-only lookup with two optional parameters and no output schema, the description conveys the domain, legal source, time range, and output granularity. Default behavior is left to the schema, which is acceptable.

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?

Both parameters are fully documented in the schema with types, ranges, format, and default behavior, so schema coverage is 100%. The description does not add parameter-specific details beyond what the schema already provides, so the baseline of 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 provides official German Sachbezugswerte under § 2 SvEV for a calendar year from 2015, covering meals and accommodation per month, day, and meal. This goes well beyond the title and distinguishes it from sibling HR value tools by naming the specific legal basis, domain, and granularity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear applicability context: Germany only, official values under SvEV, and years from 2015 onward. It does not explicitly name alternatives or when-not conditions, but the scope is specific enough for an agent to recognize when this tool is relevant.

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 tool read-only, idempotent, and non-destructive. The description adds useful constraints ('Nur Deutschland', 'Stichtag ab 2015') and lists legal areas, but it does not disclose output format or behavior for invalid/unsupported dates. With strong annotations, 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?

The description is short and front-loaded with the key restriction ('Nur Deutschland'). The bilingual repetition is mild and useful for an international agent, and the list of topics provides concrete examples without becoming an exhaustive catalog.

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 broad reference tool with two optional, well-described parameters and strong annotations, the description covers the essential scope: Germany, date threshold, headcount-based thresholds, and major legal areas. It does not specify the exact output shape, but the term 'Schwellenwerte' and the schema descriptions make the tool callable.

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 input schema already covers both parameters fully (100% coverage). The description adds human-readable meaning and example thresholds ('mehr als 10', 'ab 5'), plus the 2015+ date restriction, which helps map enum ids and the datum parameter to real-world concepts.

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 resource: German labor-law thresholds by employee count at a specific date, with concrete examples such as Kündigungsschutz (>10) and Betriebsrat (≥5). It is specific enough to be distinguished from sibling tools, though it lacks an explicit action verb like 'returns' or 'lists'.

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 implicit usage context: only for Germany, thresholds by headcount, and a date from 2015 onward. However, it does not name sibling alternatives or state when not to use this tool, so guidance remains 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?

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds useful behavioral context by scoping results to Germany and dates from 2015, and by mentioning both tax and social-security base pay limits. However, it does not disclose what happens for dates before 2015 or describe the response behavior beyond the rate values.

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 short but structurally messy: it mixes German and English, contains an incomplete phrase ('Weihnachten und 1.'), and the English portion merely restates the German content. Important information is front-loaded, but the bilingual duplication and broken sentence make it less effective than it should be.

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 read-only lookup with three optional parameters, the description plus schema is mostly sufficient: the legal basis, country scope, date constraint, and available components are covered. However, there is no output schema and the description does not explain the expected return structure or edge cases like unsupported dates, so some ambiguity remains.

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

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

Schema description coverage is 100%, with each parameter documented, so the description does not need to repeat parameter-level detail. The description does add useful legal context around base pay limits and premium categories, but it does not materially improve on the schema's own parameter descriptions.

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 names the tool's purpose: tax-free premium rates under § 3b EStG for Sunday, holiday, and night work, plus base pay limits. The 'Nur Deutschland' restriction and reference to a cutoff date from 2015 add useful scope. It does not explicitly differentiate from sibling tools, but the subject matter is specific and recognizably distinct.

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 the geographic scope ('Nur Deutschland') and a date restriction ('Stichtag ab 2015'), but it provides no guidance on when to choose this tool over siblings like hr_steuerfreie_betraege or hr_beitragssaetze. There is no mention of when not to use it or what kinds of questions it should answer versus others.

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, and destructiveHint=false, covering the safety profile. The description adds that it covers periods since 2015 but does not disclose return format, pagination, or other behaviors. Since annotations carry the main burden and the description does not contradict them, a 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?

The description is short but awkwardly structured, mixing German and English and ending with an ellipsis ('nachwirkender …') suggesting truncation. It front-loads the Germany-only constraint but lacks a clean structure. It is concise but not well-organized, and the incomplete ending detracts from 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?

There is no output schema, so the description must explain what the tool returns. It only says it provides periods, not the format or detail level. The bestandteil enum has many specific options that are not explained in the description. For a tool with two parameters and no output schema, the description is insufficient for an agent to fully understand the response.

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 input schema has 100% description coverage for both parameters, with clear descriptions for datum and bestandteil. The tool description adds no additional parameter details beyond what the schema already provides. With high coverage, the baseline of 3 is correct.

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

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

The description states it provides periods of special protection against dismissal since 2015, listing specific groups like Mutterschutz and Pflegezeit. It is not a tautology and distinguishes from the sibling hr_kuendigungsfrist by the 'special' qualifier. However, the list is incomplete and the English translation is vague, so it is clear but not fully explicit.

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 guidance is given on when to use this tool versus alternatives like hr_kuendigungsfrist. The description does not mention exclusions or provide context for selecting this tool over siblings. It simply describes what it does, leaving 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?

Annotations already declare read-only, idempotent, non-destructive behavior; the description adds useful context by limiting the tool to Germany and to data from 2015 onward. However, it does not disclose response shape or default behavior when no 'bestandteil' is supplied, so it adds only moderate value beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is short and front-loaded with the critical geographic and temporal scope, followed by concrete examples. The English sentence partly repeats the German content but is a helpful bilingual clarification rather than 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?

For a two-parameter read-only tool with a fully documented enum and schema, the description supplies enough domain context (employer benefits, employee lump sums, date applicability) to support selection and invocation. It does not describe return values, but no output schema exists and the values are self-evident from the component ids.

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%: the input schema fully documents 'datum' (format and default) and 'bestandteil' (allowed enum ids and their meaning). The tool description merely previews some enum values and does not add parameter-level detail beyond the schema, 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?

The description names a clear resource—tax-free amounts, exemption limits, and employee lump-sum allowances—and adds scope constraints ('Nur Deutschland', 'Stichtag ab 2015') that help distinguish it from sibling HR tax tools. It stops short of 5 because it has no explicit verb such as 'returns' or 'liefert'.

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 no guidance on when to choose this tool over alternatives such as hr_sachbezugswerte, hr_bav_hoechstbetraege, or hr_rechengroessen. 'Nur Deutschland' is a scope constraint, not an explicit when-to-use or when-not-to-use rule.

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, idempotentHint, and destructiveHint already provided, the description carries a lower burden. It adds useful behavioral context: country scope, monthly calculation, the relevant legal rules, and dependency on the collecting agency's state. It does not describe return shape, but the annotations already cover the safety profile.

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 not cleanly structured: it begins with a terse German sentence, includes a truncated legal citation ('§ 28f Abs. English:'), and then repeats the same information in English. The English tail is redundant rather than additive.

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 should at least indicate what the result looks like; it does not. It is still adequate for a simple read-only calculator because it covers purpose, legal basis, country scope, and state dependence, but the missing return-format and `datum` behavior prevent a higher score.

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's reference to 'your collecting agency's state' maps to the `land` parameter and 'je Monat' maps to `jahr`, but it adds little beyond the schema and does not mention the `datum` parameter.

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 ('Berechnet') and a precise resource: the monthly due date of German social security contributions and the contribution statement deadline, with legal citations. It does not explicitly differentiate itself from sibling tools, but the specialized legal terms make the purpose 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 clearly frames the use case ('Berechnet je Monat den Fälligkeitstag... und den Termin für den Beitragsnachweis') and restricts applicability to Germany. It does not mention alternative tools or explicitly state when not to use it beyond the country restriction, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the geographic and temporal scope (Germany, from 2015) and the presence of a formula, but no further behavioral details. This is adequate given the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two sentences (German and English) with no filler. The key scope ('Nur Deutschland') and legal reference are front-loaded. The English translation adds mild redundancy but aids international agents, keeping the description efficient.

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 read-only, idempotent tool with one optional parameter and no output schema, the description explains the output content and the constraints. It does not detail the exact output format, but given the simplicity and the annotations, an agent can call it correctly without further information.

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 covers the single datum parameter fully with format and default behavior. The description adds the constraint that the date must be from 2015 onward, which is not in the schema, providing extra semantic meaning beyond the structured data.

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 what the tool provides: the lower/upper limits of the German transition zone (Midijob) per §20 SGB IV, factor F, and the formula for contribution-based income. It is specific enough to be distinguished from sibling tools like hr_minijob_abgaben or hr_beitragssaetze, though it does not explicitly name them.

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 concrete usage conditions: Germany-only and for dates from 2015 onward. However, it does not explicitly state when to prefer this tool over siblings like hr_minijob_abgaben or hr_beitragssaetze, leaving the agent to infer from the name and 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 cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so no repetition is needed. The description adds genuinely useful behavior beyond structured data: the jurisdiction restriction ('Nur Deutschland') and, importantly, the legal rounding rule ('samt Rundung nach § 5 BUrlG'), which materially affects the computed result and cannot be inferred from the schema or annotations. A 5 would require output-format or edge-case disclosure.

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 German sentences plus a compact English paraphrase, with the most critical constraint ('Nur Deutschland') front-loaded. Each clause earns its place: legal basis, part-time applicability, mid-year entry/exit option, and the §5 BUrlG rounding rule. The German/English duplication is mild and reasonable given the German title and the need for English-speaking agents to match the tool correctly.

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 read-only calculator with 100% schema parameter coverage and safety carried by annotations, the description covers jurisdiction, legal basis, input categories, and the rounding rule. The main gap is the output format (no output schema exists to carry that burden), though the result — vacation days after legal rounding — is predictable from the tool name. Ambiguous parameter combinations (e.g., both eintritt and austritt supplied, or jahr conflicting with those dates) are unaddressed, keeping this below 5.

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 even without parameter details in the description. The description does add purpose-level meaning by mapping arbeitstage_pro_woche to 'Teilzeit' and eintritt/austritt to 'Teilurlaub', explaining why those parameters exist. It does not, however, add format, unit, or constraint details beyond what the schema already documents, so it stays at baseline.

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 opens with a specific verb and resource: 'Berechnet den gesetzlichen Mindesturlaub nach dem Bundesurlaubsgesetz' (calculates statutory minimum vacation per the Federal Vacation Act). It also names the exact scope inputs (part-time working days per week, mid-year entry/exit). Among 24 sibling HR calculators, this is the only vacation-entitlement toolaine, and the legal basis plus 'Nur Deutschland' boundary makes confusion with tools like hr_mindestlohn or hr_feiertage impossible.

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?

Clear context is given: Germany only, statutory minimum vacation, part-time scenarios, and partial vacation for entries/exits during the year. The phrase 'gesetzlichen Mindesturlaub' implies this excludes contractually/tariff-agreed vacation above the statutory floorause, though that exclusion is not explicit. No sibling alternatives are named, but the tool's legal domain is so distinct from its siblings that major misrouting is unlikely.

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 mark this as read-only, idempotent, and non-destructive. The description adds useful behavioral details beyond that: Germany-only scope, data only from 2015 onward, all stages in one call, and the fields included per stage. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is compact and front-loaded with the most important constraint ('Nur Deutschland'), then summarizes scope, output fields, and use cases in a single dense sentence. The optional English translation is redundant but adds accessibility without bloating the content.

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 no output schema, the description compensates by naming the returned components (Gültig-ab, Werten, Rechtsgrundlage, Quelle) and the available filters. This is sufficient for an agent to understand what it will receive. Minor details about output shape or error behavior are not covered, but the schema and annotations carry the rest.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description lightly mentions 'von, bis' and 'Bestandteil' but adds no semantic detail beyond the schema, matching the baseline of 3.

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 resource (German HR reference tables) and the action (retrieving their historical stages since 2015), and the word 'Verlauf' / 'history' distinguishes it from sibling tools that likely expose current values. However, it lacks an explicit verb like 'returns' or 'lists', so it stops just short of the strongest 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 gives concrete use cases: tracking development over years or finding all changes within a year. This is clear context for when the tool is appropriate, though it does not explicitly name sibling tools as alternatives or state when not to use them.

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, and destructiveHint, so the safety profile is covered. The description adds useful context about geographic scope, legal basis, and output components, but it does not disclose defaults or behavior when no parameter is provided.

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 compact and front-loaded with the geographic restriction, followed by a clear list of values and the year range. The English mirror sentence is slightly redundant but improves accessibility without bloating the text.

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 simple read-only lookup with two optional, fully documented parameters and no output schema, the description supplies the essential domain constraints: country, year range, legal references, and available components. The exact response shape is not described, but this is unlikely to prevent correct invocation.

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 input schema already documents both parameters fully, including the jahr bounds and the bestandteil enum values. The description adds only the 'Kohortenjahr' framing, which reinforces the meaning but does not provide new parameter-level details.

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 specific legal values (Versorgungsfreibetrag, Zuschlag, Altersentlastungsbetrag), their forms (percent and maximum amount), and the cohort-year range. It is unmistakably distinct from sibling tools, though it uses a noun phrase rather than an explicit verb like 'returns' or 'calculates'.

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 'Nur Deutschland' and cohort-year framing imply the intended context, and the legal references clarify the subject matter. However, the description gives no explicit when-to-use guidance or exclusions relative to related siblings such as hr_steuerfreie_betraege or hr_bav_hoechstbetraege.

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, and destructiveHint=false, so the description does not need to repeat those. It adds behavioral context by naming the legal aspects computed and the 'Stichtag' (cutoff date) requirement, but it does not specify the output format or any pagination/limits. Given the annotations cover safety, the description provides sufficient additional 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 concise and structured, with a German main sentence and an English summary. It front-loads the critical scoping ('Nur Deutschland') and then lists key topics. It could be slightly shorter, but it is not overly verbose and includes both languages for accessibility.

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 tool has complex subject matter (German labor law) and no output schema, yet the description does not explain what the tool returns (e.g., a text explanation, values, or a summary). It also does not state the default behavior when no parameters are provided (today's date and all components), which is implied by the schema but not described. For a specialized tool, this is a notable gap.

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

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

Schema description coverage is 100%, with both parameters (datum and bestandteil) already documented in the schema. The description does not add extra meaning beyond the schema; it lists topics but does not explain parameter usage in more detail. The baseline of 3 applies because the schema handles the parameter documentation adequately.

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 domain (German temporary agency work under AÜG) and lists specific legal aspects like maximum assignment duration, equal pay, and minimum wage. It distinguishes itself from sibling tools by naming the subject matter explicitly, and the English summary reinforces its scope for non-German speakers.

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 about what the tool covers (Germany, Zeitarbeit, since 2015, specific legal components), but it does not explicitly mention when not to use it or suggest alternatives. Since the sibling list covers many HR topics, an agent can infer this tool is for Zeitarbeit, but there is no direct exclusion or alternative guidance.

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