Lintelly HR Deutschland

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

The annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the description appropriately adds legal context: Germany-only scope, rule-of-thumb nature, no automatic legal entitlement, and the § 10 KSchG cap. It does not describe the return shape, but that gap is modest given the calculator nature and 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 core purpose and formula. Its main inefficiency is repeating 'Germany only' at the beginning and end, which slightly weakens conciseness.

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 full schema descriptions and clear annotations, the description provides enough legal and behavioral context to invoke it correctly. An explicit statement of the returned estimate would help because there is no output schema, but the calculator purpose is strongly implied.

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 real meaning by giving the calculation formula tying monthly pay, factor, and years of service. It still does not explain optional inputs such as sonderzahlungen, kleinbetrieb, or zugang_kuendigung, so it is helpful but not exhaustive.

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 that the tool computes German rule-of-thumb severance pay using monthly pay × factor × years of service, and that it is meant for sizing an offer or settlement. It is specific enough to separate the tool from sibling deadline, checklist, and contract-clause tools, though it does not explicitly name any sibling alternative.

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 says to use the tool to size an offer or settlement and warns that there is usually no legal right to severance. The Germany-only scope is stated, but there are no named alternatives or explicit when-not-to-use conditions beyond the legal caveat.

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 a safe read-only, idempotent, closed-world operation, so the bar is lower. The description adds meaningful context beyond them: jurisdiction is Germany only, the output is a workflow with dates, roles and legal norms, and inputs deliberately exclude names for privacy. Output structure is still only sketchy.

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?

Jurisdiction and scope are front-loaded and the sentence about founder-described situations earns its place. However, 'Germany only' is needlessly repeated at the start ('Germany only. German employment law, Germany only:'), a small structural flaw in an otherwise compact description.

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 17-parameter, no-output-schema tool, the description covers jurisdiction, trigger conditions, input privacy constraints and the nature of the result. What remains, such as the required art and the per-art meaning of datum, is fully handled by the exhaustive schema, so the description is complete enough to select and call 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% and the per-parameter documentation is unusually detailed, so the schema carries the semantics. The description only reinforces that inputs are dates, numbers and choices, without adding meaning to art, datum or the many optional fields; 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 states a specific resource, a complete HR workflow with dates, roles and legal norms, and enumerates the situations it covers (first hire, sickness, pregnancy, dismissal). It is clearly an aggregate workflow tool, but it never explicitly distinguishes itself from point-solution siblings such as probezeit or kuendigungsfrist_rechnen.

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

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

It gives a concrete trigger, use it when a founder describes a situation such as a first hire, sick employee, pregnancy or planned dismissal, and adds an input constraint (dates, numbers, choices only, never names). There are no explicit exclusions or named alternative tools, so it stops short of 5.

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

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

The annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior. The description adds useful context beyond that: the output includes legal required parts, a template, writing rules, checklist and pitfalls; the template uses roles instead of third-party names; and facts are not entered into the tool. It could still say more about exactly what the generated result looks like.

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 appropriately sized and front-loads the Germany-only constraint and the tool's purpose. It has minor redundancy in repeating 'Germany only' and 'German employment law, Germany only', but overall the information is well organized and useful.

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

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

Given the absence of an output schema, the description usefully enumerates what the tool provides: required parts, template with placeholders, writing rules, checklist, and pitfalls. It also states the scope and a privacy-related constraint. It is nearly complete, though it could clarify whether the output is fully generated text, guidance, or both.

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 parameters are already well documented in the input schema. The description mentions legal components such as Rüge with date/time and verletzte Pflicht, but it does not map these to parameters or add syntax/format guidance beyond the schema, 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 specific resource: generating/accessing content for a formal German warning letter (Abmahnung), including required legal parts, template, rules, checklist, and pitfalls. It also states the triggering scenario. However, it does not explicitly differentiate itself from nearby siblings such as kuendigungsschreiben or mitarbeitergespraech_leitfaden.

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

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

It gives a clear usage condition: use when an employer wants to warn an employee about misconduct, and it enforces a Germany-only scope. It does not name alternatives or explain when not to use it, so it falls short of full when/when-not guidance.

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

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

With readOnlyHint/idempotentHint already declaring this a safe, repeatable lookup, the description adds real value beyond them: it discloses that output includes rates, contribution ceilings and sources, and that Midijob returns only a lower bound rather than an estimate. That limitation disclosure is the kind of behavioral nuance annotations cannot express.

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 dense sentences with the geographic restriction front-loaded and the caveat placed last where it belongs. It is information-rich but every clause carries content; the parenthetical German terms are the only mild redundancy.

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, yet the description explains what comes back (monthly and annual costs, rates, ceilings, sources) and flags the one case with degraded precision. Combined with 100% schema coverage on inputs, that is close to complete, missing only return shape details.

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

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

Schema description coverage is 100%, so all five parameters are already documented, which sets the baseline at 3. The description only adds loose semantics by spelling out the German employment-type terms (Werkstudent, Minijob, Übergangsbereich); it says nothing extra about stichtag, pauschsteuer or gesetzlich_versichert beyond what the schema states.

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

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

Names a specific verb+resource (employer costs of one employee) with scope qualifiers (Germany only, per month and year, gross pay plus employer social-security share). It also enumerates the employment types covered, so an agent can tell it apart from siblings like minijob or mindestlohn_check without opening a schema.

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

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

"Germany only" is an explicit exclusion, and the four covered employment types plus the Midijob caveat define the valid context of use. It stops short of routing the agent to an alternative (e.g. the minijob sibling) for cases it doesn't cover, so it is clear but not fully prescriptive.

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 a read-only, idempotent, closed-world operation, so the safety profile is covered. The description adds real value beyond that by listing the returned components (mandatory parts, coded wording, satisfaction formula, forbidden codes/traps, statutory claim) and the 'never names' privacy constraint.

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 content is front-loaded with scope and usage before the return description. It loses a point for redundancy — 'Germany only' appears twice in the opening sentence — but otherwise every clause carries information.

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

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

With 14 optional parameters and no output schema, the description compensates well by enumerating what the response contains and constraining input (no names). Defaults and the leadership-grade interaction are left to the schema, which documents them adequately.

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 enums and defaults fully documented, so the schema does the heavy lifting. The description only restates the core inputs (kind of reference, grades from 1 to 5) and adds no meaning about interdependencies such as grade weighting for leadership.

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 concrete artifact (German employment reference / Arbeitszeugnis, Zwischenzeugnis, Endzeugnis) and states what the tool returns: structure, Zeugnissprache per grade, overall grade formula, forbidden codes, and the § 109 GewO claim. No sibling tool covers reference writing, so differentiation is implicit rather than explicit, and the verb is more 'returns content' than a crisp action verb.

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

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

It gives a clear trigger ('use it when a founder wants a reference written') and an input convention (kind of reference plus a 1–5 grade per area, never names). There are no explicit when-not conditions or named alternatives, but the context is unambiguous.

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 (readOnly, idempotent, non-destructive, closed-world), so the description is free to add what they cannot: a hard jurisdiction constraint (Germany only) and a mode-dependent output difference (modus austritt yields a deletion plan rather than a single period). It stops short of stating return shape or legal-disclaimer caveats.

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

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

Front-loaded and readable, but the opening 'Germany only. German employment law, Germany only:' repeats the same constraint twice, and the document enumeration mirrors the schema enum instead of pointing to it, adding bulk 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?

With no output schema, the description carries the burden of describing results, and it does: it names the covered documents and explains that modus austritt produces a deletion plan after an exit date. The jurisdiction restriction is essential context that is included; only the exact output fields remain unspecified.

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 enum of document types and the meaning of datum/modus are already documented. The prose re-lists the document types and mentions modus austritt, which largely duplicates the schema rather than adding new semantics (e.g. how verfahren_laeuft interacts with the computed date).

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

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

States a specific resource (retention periods for named HR document types) and the concrete output (earliest deletion date, plus a Löschplan under modus austritt). No sibling tool covers retention/deletion periods, so the agent can route here unambiguously.

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 closing sentence gives an explicit trigger: 'when someone asks how long to keep employee documents or when they may or must be deleted.' It does not name an alternative tool or note when not to use it, but for this catalogue the trigger 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes further by enumerating the returned values (required places, employment rate, rate per place and month, levy, 31 March deadline) even though no output schema exists. It also pins the legal basis and the validity window, which matters for trusting the result.

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

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

Front-loaded with the key scope ('Germany only', what the levy is) and the input/output contract in a single dense sentence. It loses a point for repeating 'Germany only' verbatim at the end, which is pure redundancy.

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 carries the return-value burden itself and does so, plus inputs, legal basis, eligibility threshold and time window. An agent has everything needed to decide to call it and to interpret the result.

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 year enum, array bounds, the 18-hour/apprentice exclusion and the default 0 are already documented. The description only restates the 'one value or 12 monthly values' convenience and adds no format or edge-case detail beyond the schema, making 3 the correct 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?

States a specific resource (compensatory levy under §§ 154, 160 SGB IX) and a specific action (takes jobs and severely disabled employee counts, returns required places, employment rate, rate per place, levy and deadline). An agent can immediately tell this is a statutory levy calculator rather than a generic check, differentiating it from siblings like schwellen_check or bempflicht.

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

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

Gives real applicability conditions: 'Germany only', 'years 2024 to 2026', and the eligibility threshold 'Only employers with 20 or more jobs on annual average are affected' — all of which tell an agent when the tool is relevant. It stops short of naming a sibling alternative or stating an explicit when-not-to-use, so it is clear context without full 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 cover read-only/idempotent/non-destructive, and the description adds the substantive behavior: what findings are produced (Vorbeschäftigung, Schriftform, Verlängerung) and the statutory caps it applies (2 / 4 / 5 years). It stops short of saying what happens when limits are exceeded or how severe findings are weighted.

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

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

Three sentences, front-loaded with jurisdiction and purpose, then returns, then when-to-use. The opening 'Germany only. German employment law, Germany only' states the scope twice, which is pure waste in an otherwise tight definition.

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 carries the return-value burden and does so adequately by enumerating the returned end date, extension counts, and findings. For a 9-parameter legal calculator one might also expect a note on assumptions/defaults or the legal caveat, but it is essentially complete.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by tying specific caps to specific inputs — 4 years to 'new companies' (gruendung) and 5 years to 'age 52' (ab52) — which clarifies the meaning of otherwise optional fields.

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

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

States a concrete verb and legal resource ('checks a fixed-term contract without objective reason, § 14 TzBfG') and names the exact artifacts returned: latest allowed end date, extensions used/left, and traffic-light findings. No sibling tool covers Befristung, so the agent can immediately place it in the German labor-law suite.

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

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

'Use it before signing or extending a fixed-term contract' gives a clear timing cue for invocation, and 'Germany only' scopes jurisdiction. It doesn't name an alternative path (e.g. for Befristung with objective reason (sachlicher Grund), which this tool explicitly does not handle), leaving a mild gap.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds real value beyond that: it discloses the return payload (counts, the day the limit was crossed, next steps) and the scope rule applied from the first employee, which an agent cannot infer from 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?

One dense paragraph that front-loads the jurisdiction and the legal rule before the mechanics. The only waste is 'Germany only' repeated at the start and again as the final sentence, which is redundant.

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 three-parameter pure-calculation tool, the description covers jurisdiction, legal basis, threshold, counting method, and return contents. Minor gaps remain: it does not mention the 20-period cap or how overlapping periods are handled, but those are edge details carried 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 coverage is 100%, so the baseline is 3, but the description adds meaning: it clarifies the 12-month lookback that gives stichtag its purpose, and that counting is done both in calendar days and in working days, which explains why arbeitstage exists. The 'whatever the cause' and 'counted in calendar days' phrasing directly resolves ambiguities the schema leaves implicit.

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?

Names a specific verb (checks) and a precise legal resource (BEM obligation under § 167 Abs. 2 SGB IX), and states the exact legal threshold that defines the check. An agent can distinguish it from generic siblings like schwellen_check or entgeltfortzahlung because the description pins the answer to the BEM statute and the >6-week criterion.

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 triggering condition is spelled out explicitly (more than 6 weeks of incapacity within the last 12 months, counted in calendar and working days, any cause) and 'Applies from the first employee' removes the usual headcount question. It does not name a sibling alternative or an exclusion, so it falls short of a 5, but the context for calling it is unambiguous.

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

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

Annotations already declare this as a read-only, idempotent, non-destructive calculation. The description adds useful behavioral context beyond the annotations, including the legal basis, jurisdiction, and the specific outputs returned such as the last request date, dismissal protection period, and leave reduction. It does not contradict 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 front-loaded and compact, with the jurisdiction and legal basis stated first and concrete outputs listed next. It wastes a few words by repeating 'Germany only' twice, preventing a top score.

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 an 11-parameter legal calculation tool with no output schema, the description is complete enough: it states jurisdiction, legal basis, usage context, and the specific values the tool returns. The schema itself fully documents all inputs.

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 every parameter is already documented in the input schema. The description adds some general context about request receipt, annual leave, and maternity protection, but does not explain parameter syntax or interactions 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 names a specific resource (deadlines for parental leave under §§ 15–18 BEEG), a specific action (returns computed legal deadlines), and a clear jurisdiction (Germany only). It does not explicitly differentiate itself from sibling tools such as mutterschutz or urlaubsanspruch, despite touching overlapping 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 gives a clear usage context: use it when an employee announces parental leave or a request has arrived. It does not state when not to use it or name alternative tools for related questions.

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 a safe read-only, idempotent calculation. The description adds valuable behavior beyond that: waiting-period rules, the 6-week cap, repeated-sickness handling, U1 refund logic, and BEM timing. It does not explain edge-case or error behavior in much detail, but the core calculation model is disclosed.

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

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

Front-loads the Germany-only scope and explains the calculation efficiently in a few sentences. Minor waste from repeating 'Germany only' at start and end, but the content is appropriately sized for a legal calculation tool.

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 usefully lists the return values: paid days, last paid day, Krankengeld start, U1 refund, and BEM due. It covers the main legal concept and scope, though it could be slightly more explicit about output shape or ambiguous sickness cases.

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 both parameters and the nested period fields are already well documented. The description adds legal context for the waiting period and same-illness periods, but does not add per-parameter syntax or distinctions beyond the schema, so 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?

States a specific legal calculation (Entgeltfortzahlung under § 3 EFZG), names the key rules (6 weeks, waiting period, Fortsetzungserkrankung), and lists the outputs. An agent can tell this is the sickness-pay calculator rather than a generic HR tool.

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

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

Explicitly says to use it when an employee is or was sick and restricts it to Germany. It gives clear context but does not name when-not-to-use cases or point to sibling alternatives such as bem_pflicht.

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

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

Beyond the readOnlyHint/idempotentHint annotations, the description discloses the privacy posture ('has no memory and stores no personal data'), the actual return artifacts (iCalendar text the user can save, plus a calculator link), and the double opt-in for reminders. These are exactly the behavioral traits an agent needs and cannot infer from 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 single dense sentence front-loads the jurisdictional scope and then covers mechanism, return values, and privacy. Every clause carries information, though the run-on structure makes it slightly harder to scan than a short two-sentence split would.

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 correctly compensates by naming the return values (iCalendar text and a URL). It is complete enough to call correctly, though it doesn't say anything about the calendar entry's contents or how the calculator link is parameterized.

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%: the date format pattern and the twelve-value deadline enum are fully documented in the schema. The description adds no parameter-level detail (e.g. which deadline kinds map to which calculator), 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 states a specific verb and resource ('Remember an HR deadline') and immediately clarifies the mechanism: it returns an iCalendar entry plus a link instead of persisting data. That distinguishes it from the many sibling calculators (kuendigungsfrist_rechnen, elternzeit_fristen) that compute dates rather than record them, though no sibling is named 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?

'Germany only' is a clear jurisdictional constraint, and the mention of the e-mail reminder via lintelly.com hints at the follow-up flow. However, there is no explicit guidance on when to pick this over calculator siblings (e.g. compute the date first, then remember it) and no stated preconditions beyond the two required fields.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered; the description adds real value by disclosing the returned content (forbidden topics with reasons, allowed questions, rating anchors, interview flow). This matters because no output schema exists to convey the payload.

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

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

Front-loaded and dense with useful specifics, but the phrase 'Germany only' is stated twice in the opening sentence, which is pure redundancy in an otherwise tight block. The long enumeration of return contents is justified, the repetition is not.

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 enum parameters and no output schema, the description covers what the agent gets back and the jurisdictional constraint. The only gap is how the two optional parameters modulate the result.

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

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

Schema description coverage is 100% and both enums are fully documented in the schema, so the baseline is 3. The description never mentions form or senioritaet and adds no guidance on how the choice of interview setting or seniority changes the output.

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

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

States a concrete resource (a checklist of allowed/forbidden interview questions under the AGG) and enumerates the concrete content it covers: pregnancy, religion, health, age. The 'interview' framing cleanly separates it from siblings such as stellenanzeige_check or mitarbeitergespraech_leitfaden.

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

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

Gives an explicit trigger ('when a founder prepares an interview or asks whether a question is allowed') plus examples of the topics that qualify. The repeated 'Germany only' also functions as a scope exclusion, but no sibling alternative is named for the non-German or non-interview case.

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

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

Annotations already declare a safe, read-only, idempotent, closed-world calculation. The description adds real domain context beyond that: the 'Germany only' constraint, the underlying 3-week rule with statutory citations, and the weekend/holiday rollover logic — enough for the agent to trust and interpret the result.

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

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

Front-loaded with the 'Germany only' guard, then the rule, then the use case — a sensible order with no filler. Minor redundancy in repeating 'in Germany' after the opening guard.

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 calculator with no output schema, the description covers scope, legal basis and edge-case handling. It never states what the tool returns (presumably the computed deadline date), which is the one remaining gap an agent would want closed.

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 schema already defines both parameters, making 3 the baseline. The description earns a notch above by explaining the weekend/public-holiday rollover rule, which implicitly tells the agent why `bundesland` matters for the calculation.

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

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

States a specific verb and a precisely scoped legal resource: calculating the Klagefrist (Kündigungsschutzklage deadline) under § 4 KSchG. The specificity of 'Klagefrist' versus the sibling 'kuendigungsfrist_rechnen' (notice periods) makes the distinction clear without opening either schema.

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

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

'Use it to know from when a dismissal can be treated as final' gives a concrete use context, and 'Applies in small businesses too' pre-empts the most common scope doubt (KSchG threshold). It stops short of naming alternatives or stating when-not to use 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 readOnly/idempotent/non-destructive/closed-world, so the bar is lower; the description still adds real value by disclosing the return contents (reason, norm, safe alternative clause) and the privacy behavior ('only read, never stored'). The missing piece is what an empty result looks like or any rate/size caveat beyond the schema's 3,000-char limit.

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?

Five short sentences, front-loaded with the jurisdiction and the core action, then return values, caveat, and privacy in descending priority. The 'e.g.' examples of void clause types earn their place by making the rote Liste concrete.

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?

No output schema exists, and the description compensates by stating what matches contain and by flagging the 'no match' interpretation caveat — the two things an agent most needs to report results responsibly. Minor gaps remain, such as whether input must be German-language text or how many matches to expect.

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?

Single parameter with 100% schema description coverage (type, maxLength 3,000), so the schema carries the semantics and baseline 3 applies. The description adds only the 'one clause' framing, which is already implied by the schema, and does not clarify language or format expectations for the clause text.

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?

Specific verb and resource: reads one clause of a German employment contract against 17 named clause types ('rote Liste'), with concrete examples of what those types are. The jurisdictional scope (Germany only) and unit of work ('one clause') let an agent distinguish it from siblings like vertragsbaustein (drafting) or stellenanzeige_check (job ads).

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?

Sets clear preconditions: Germany only, single clause input, and an explicit limit ('No match is not a legal review of validity'). It does not name an alternative tool for, say, checking a whole contract or drafting a compliant clause, so routing against siblings is left implicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds value beyond that by disclosing the return substance (each item paired with its legal norm) and the jurisdictional restriction, which annotations cannot convey. It stops short of saying whether output is a generic checklist or tailored to the supplied employee/works-council inputs.

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

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

Front-loading the scope is good, but "Germany only. German employment law, Germany only." says the same thing three times in two short sentences — pure waste in the most prominent position. The checklist enumeration is dense and earns its length, but the opening redundancy is a structural flaw.

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 usefully compensates by enumerating what the checklist contains and noting each item carries its legal norm. For a two-parameter read-only tool this is close to sufficient; only the input-to-output relationship (does beschaeftigte/betriebsrat change the items returned?) is left unstated.

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 (betriebsrat, beschaeftigte with the § 23 KSchG counting rule) are already fully documented, making 3 the baseline. The description's mentions of "works council hearing" and "small business ... up to 10 employees" loosely signal what the two inputs gate, but it does not explicitly tie either parameter to a checklist branch.

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

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

States a concrete resource and verb: a checklist of the formal requirements for an employer-issued Kündigung, with the substantive coverage enumerated (written form, Zugang, notice period, works council hearing, Sonderkündigungsschutz, etc.). An agent can tell it is the formalities checklist rather than a calculation or drafting tool, but the description never names the overlapping siblings (kuendigungsfrist_rechnen, sonderkuendigungsschutz_check, klagefrist, kuendigungsschreiben), so the differentiation must be inferred.

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

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

"Use it before a dismissal" gives clear situational context for invoking the tool. However, it offers no exclusions and no routing to alternatives, which is a real gap given that several listed checklist items (notice period, special protection, 3-week claim deadline) have dedicated sibling 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered; the description adds real value by stating the legal rule set, enumerating the computed return values (which no output schema provides), and flagging that warnings are emitted (e.g. Sunday receipt). It does not mention limits such as non-binding/non-legal-advice status or how the tarifvertrag special case is treated.

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 jurisdictional constraint is front-loaded in two words, followed by the verb, legal basis, outputs, coverage and use cases in a dense ~90-word block with no filler sentences. Every clause carries information the agent needs.

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 10-parameter, no-output-schema calculator, the description covers scope, legal basis, computed return values and the main case dimensions, which is enough to invoke it correctly. Minor gaps remain around how the collective-agreement flag changes results and the non-binding nature of the outcome.

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 already 100%, so the baseline is 3; the description adds meaning by pre-grouping the case dimensions it handles (probation, length of service, small businesses, longer contractual periods), which maps to probezeit_monate, kleinbetrieb_vier_wochen and vertrag_monate. It does not explain individual enum values or defaults beyond what the schema states.

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

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

A specific verb ('Calculate') and resource ('notice period / Kündigungsfrist') are given, along with the legal basis (§§ 187, 188, 622 BGB) and the exact outputs (end of employment, latest receipt date, next three end dates, rule applied, warnings). It does not explicitly name a sibling such as klagefrist or kuendigungsschreiben to differentiate, so it is clear but not fully disambiguating.

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?

'Germany only' sets a hard scope, and 'Use it for dismissals by the employer and resignations' names the two directions of use, matching the wer_kuendigt parameter. There is no explicit when-not guidance or named alternative tool for adjacent questions (e.g. writing the notice letter).

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 (readOnly, idempotent, non-destructive, closed-world), and the description adds posture beyond that: names/addresses/signer remain square-bracket placeholders, the notice period is derived rather than user-supplied, and a pre-send checklist (§ 623 Schriftform, Zugang, Vollmacht, Klagefrist) is included. It doesn't say what the response payload looks like, but that is the only notable gap.

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

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

Front-loaded with jurisdiction, then purpose, then legal mechanism, then exclusions in a single tight paragraph. Slightly wasteful repetition of 'Germany only' twice in the first sentence ('Germany only. German employment law, Germany only.'), which costs a point but otherwise nothing is padded.

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 17-parameter generator with no output schema, the description supplies the legal basis, output format (DIN 5008, placeholders retained), the computed end date, and the accompanying checklist. What's missing is a short statement of what is actually returned (letter text vs. structured fields) and confirmation that the 'ausbildung' flag exists only to reject/warn, given the prose says the tool is not for apprentices.

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

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

Schema description coverage is 100%, so all 17 parameters are already documented, including the critical distinction between briefdatum and zugang. The description only reinforces the eintritt + Zugang → end date relationship; the other 15 inputs (freistellung, betriebsrat, unterschrift, etc.) get no added meaning from the prose, so the baseline 3 applies.

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

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

States a concrete verb and artifact: builds an employer's Kündigungsschreiben in DIN 5008 form, with the § 622 BGB end date computed from start date and Zugang. This is clearly distinct from siblings like kuendigungsfrist_rechnen (period only) or kuendigung_pflichtangaben (mandatory content check).

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?

Explicit exclusions are given: not for fristlose Kündigung and not for apprentices, plus a hard 'Germany only' jurisdiction gate. It stops short of naming which sibling to use for those excluded cases (e.g. the summary-dismissal tool), leaving the routing inference to 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 declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds genuinely useful behavior not in annotations: the 13/3 weeks-per-month payroll convention and the exact set of returned figures (hourly wage, minimum wage, required monthly pay, shortfall). Missing only things like which minimum-wage table/version is used or edge-case handling.

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 dense sentences: scope constraint, purpose, outputs, calculation convention, and exclusion — all front-loaded with zero 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?

Although there is no output schema, the description explicitly names the four returned values, so an agent knows what it will get. Combined with fully documented inputs and read-only annotations, nothing material 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% with per-parameter descriptions, patterns and ranges, so the baseline is 3. The description restates the two main inputs and adds the interpretation convention (13/3 weeks per month) but gives no extra semantics for stichtag beyond what the schema documents.

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

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

States a specific verb+resource ('Check a monthly salary and weekly hours against the German statutory minimum wage') and even enumerates the computed outputs. The 'Germany only' scope and the apprentice exclusion separate it cleanly from generic payroll siblings like arbeitgeberkosten or minijob.

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

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

Gives clear applicability constraints ('Germany only', 'Not for apprentices (they have a minimum training allowance)'), which is real when-not guidance. It does not, however, name which sibling to use instead for those excluded cases, so it falls short of a full routing statement.

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/non-destructive, so the description's burden is lighter; it still adds substantive domain behavior by enumerating which legal checks are computed (hours cap, Mindestlohn, annual limit including one-off payments, Pauschalabgaben) and the 2026/2027 scope. It does not describe the shape of the returned figures, but no output schema exists to cover that either.

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?

Scope and legal basis are front-loaded in the first clause, and the usage instruction follows immediately. "Germany only" appears twice, which is redundant padding in an otherwise tight three-sentence definition.

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 8 fully documented params and no output schema, the description supplies the legal framing, the year scope, and the pre-hire/pre-change trigger. The main omission is any hint about the returned result set (e.g., max hours vs. cost breakdown), which matters given the 'leave out stunden to get only maximum hours' 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?

Schema description coverage is 100%, so baseline is 3. The description only loosely echoes parameters (one-off payments, minimum wage) without adding format or default semantics beyond what the schema already documents for jahr, stunden_je, pauschsteuer, and the insurance flags.

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

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

States a specific verb+resource: a mini-job check under § 8 SGB IV for 2026/2027 covering max hours, minimum-wage check, annual limit with one-off payments, and employer flat-rate contributions. The scope (mini-job vs. general minimum wage) implicitly separates it from siblings such as mindestlohn_check and arbeitgeberkosten, but no sibling is named 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?

"Use it before hiring a mini-jobber or changing hours or pay" gives a concrete trigger scenario, and "Germany only" (stated twice) sets an explicit applicability boundary. No alternative tool is named for cases outside that boundary, so it stops short of full routing guidance.

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

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

Annotations already declare a safe, read-only, idempotent lookup, so the bar is lower; the description still adds real value by disclosing the return contents (duration, preparation, phases, difficult moments, minutes template) and flagging legal traps such as BEM and works council rights. The 'Germany only' jurisdiction constraint is stated twice, which reinforces a genuinely important behavioral boundary.

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 content is dense and front-loaded with jurisdiction, but 'Germany only' is repeated in two consecutive clauses and the middle enumeration is list-like. Roughly one sentence could be trimmed without loss.

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 parameters, no output schema, and full schema coverage, the description covers what the tool is, when to call it, and what it returns. The only gap is that it never says how the betriebsrat flag alters the result.

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 enum values are fully documented in the schema, so the baseline is 3. The description adds only an indirect hint: mentioning works council rights (Betriebsrat) implies the betriebsrat flag tailors output, but no explicit statement of what true vs false changes.

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

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

States a specific resource (a guide for Mitarbeitergespräche) and enumerates the four covering types (Kritik-, Probezeit-, Jahres-, Rückkehrgespräch), which lets an agent separate it from siblings like abmahnung or probezeit. It does not explicitly name a sibling to prefer instead, 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?

'Use it when a founder has to hold such a meeting' gives a clear triggering context. There are no exclusions or named alternatives, so the agent gets positive guidance but no routing rules.

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/non-destructive, so the safety profile is covered. The description adds real context beyond that: the jurisdictional restriction to Germany and the substantive scope of what the calculation addresses, including the employer-duty branches of the output. It says nothing about return format, but annotations lower the bar.

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?

Jurisdiction is front-loaded in the first two words, which is good, but 'Germany only' is repeated twice in adjacent phrases and the middle sentence is a long comma-spliced list. Content earns its place, but the redundancy costs it a point.

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 9-parameter, entirely optional-parameter calculator with no output schema, the description supplies the domain and the triggering situation adequately. It does not explain the conditional interplay between 'fall', the two date fields, and flags like ab_500_gramm, but the 100%-covered schema carries that burden.

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 every parameter already carries its own description; the baseline of 3 applies. The description loosely maps to parameters (extension for premature/multiple birth, miscarriage/stillbirth) but adds no syntax, defaults, or dependency logic beyond what the schema states.

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

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

The description names a specific legal domain (MuSchG maternity protection) and enumerates the exact calculations covered: pre/post-birth periods, extensions for premature/multiple birth, the Kündigungsverbot, and employer duties (Aufsichtsbehörde notification, U2 refund). An agent can tell this apart from generic tools, though it does not explicitly distinguish itself from adjacent siblings like elternzeit_fristen or sonderkuendigungsschutz_check.

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 an explicit trigger: 'Use it when an employee is pregnant, has given birth or lost a pregnancy', plus a hard jurisdictional gate ('Germany only'). It stops short of naming exclusions or pointing to a sibling for the non-German or post-employment-relationship 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 already cover safety (readOnly, idempotent, closed-world), and the description adds real substance beyond them: deadline tiers (first working day, 7th calendar day, one month), the 2025 text-form condition, paper-only industries, and fixed-term handling. It stops short of describing output shape, but it does say results show what is missing or overdue.

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

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

Front-loaded and mostly efficient, but 'Germany only' appears twice in the first sentence and 'Arbeitsvertrag-Check' re-states the title. The second sentence is long and carries a dense parenthetical clause, costing some readability.

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

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

For a read-only, closed-world checker with six optional parameters and no output schema, the description covers what the tool returns (deadlines, missing/overdue items, form verdicts) and the conditional rules that determine those results. A brief note on the default behavior with no parameters supplied would make it complete.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds value by explaining how parameters interact (start date drives the three deadline tiers, per-item answers produce missing/overdue flags, text form is conditional on 2025 rules). It does not add syntax or format detail beyond the schema, so it does not reach 5.

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

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

States a specific resource (mandatory written terms under § 2 Abs. 1 NachwG, 15-item checklist) and a specific verb (checklist/checks), plus a secondary scope (form requirements). It does not explicitly differentiate itself from the similarly named sibling kuendigung_pflichtangaben, which keeps it from 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?

Gives a clear use situation: 'when a founder hires someone or checks a contract', and explains both modes (with a start date it computes deadlines; with per-item answers it reports gaps). No explicit exclusions or named alternatives, 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 readOnly/idempotent/non-destructive and closed-world, so safety is covered. The description still adds real value by naming the legal basis applied (ArbZG vs. stricter JArbSchG) and by enumerating what comes back — working time, required vs. actual break per day, rest period and each violation — which matters because there is no output schema.

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

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

The scope constraint is front-loaded and the return-value summary earns its place, but "Germany only. German employment law, Germany only:" repeats the same constraint twice in the opening sentence — visible waste in an otherwise tight definition.

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 single-purpose checker the description covers jurisdiction, legal regime, inputs' intent and return content, which is what an agent needs to call it correctly. Minor gaps remain around how missing dates affect weekly totals and how violations are keyed, but nothing that would cause a wrong 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 description coverage is 100%, so every parameter (tage, jugendlich, vortag_ende, branche_10_stunden_ruhezeit) is already documented, including the § 5 Abs. 2 ArbZG industry exception. The description only restates the domain concepts and adds no format, ordering or edge-case guidance 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?

States a specific verb and resource: checks shifts against ArbZG (and JArbSchG for under-18s) rules on breaks, maximum daily/weekly working time and rest between shifts. This is precise enough that an agent can tell it apart from the many other German labour-law siblings without inspecting any schema.

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

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

"Use it to check a shift plan or a time sheet" gives a clear usage context, and the ArbZG/JArbSchG split tells the agent which regime applies when. There are no explicit exclusions or named alternatives, which keeps it 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 readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description adds worthwhile context the annotations cannot: the German-law jurisdiction restriction and the specific statutory bases (§ 622 Abs. 3 BGB, KSchG, BBiG) that determine the computed results. It stops short of describing output shape, but no output schema exists and the enumerated results partially substitute.

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?

Content is dense and front-loaded toward the computed outputs and the usage trigger, but 'Germany only. German employment law, Germany only:' repeats the same constraint twice in the opening, and the second sentence is an overlong list that could be split. The redundancy costs it a point.

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 six-parameter calculator with full schema coverage and no output schema, the description enumerates what the agent will get back (probation end, dismissal deadline, Kündigungsschutz start, review dates) and covers jurisdiction and special cases (Ausbildung, Befristung). That is sufficient for correct invocation; only an explicit note on the beschaeftigte threshold effect would strengthen 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 carries all parameter meaning (dauer/einheit, beginn, ausbildung, befristet_bis, beschaeftigte). The description only loosely connects to parameters by mentioning apprenticeships and fixed-term contracts, without adding syntax or constraint detail beyond the schema. 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 the specific computed outputs — probation end date, last day for two-week notice dismissal under § 622 Abs. 3 BGB, Kündigungsschutz start, and review-meeting dates — rather than restating the title. It also scopes coverage to apprenticeships (BBiG) and fixed-term contracts (Befristung), which separates it from siblings like befristung or kuendigungsfrist_rechnen.

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 explicit trigger conditions: 'Use it when someone asks when a probation period ends or until when they can still dismiss with the short notice.' The repeated 'Germany only' framing establishes jurisdiction context, though no sibling tool is named as a fallback for non-German or non-probation questions.

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 safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds meaningful behavioral detail: each entry pairs a new value with the previous one and its source, and values not yet officially published are flagged — a valuable edge-case disclosure an agent would not otherwise know.

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 dense sentences with zero filler, and the jurisdiction constraint is front-loaded before the purpose. The parenthetical and example list are compact rather than padded.

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, but the description explains what is returned (new value, previous value, source, provisional flags), which substitutes well. Combined with full parameter documentation and rich annotations, an agent has nearly everything needed; only explicit sibling routing 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 coverage is 100% and both parameters (von/bis) are documented with formats and defaults. The phrase 'between two dates' merely restates the schema without adding interpretation, 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 names a specific resource (calendar of changes in German employment law values) and a specific operation (list changes between two dates), with concrete examples (minimum wage, mini-job limit, contribution ceilings). It clearly differentiates itself from value-lookup siblings like rechtswert/rechtswerte_suchen by framing the output as a dated calendar of transitions.

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 'Germany only' jurisdiction constraint and the 'what changes on 1 January' example give clear context for when this tool applies. It does not explicitly name alternatives (e.g. rechtswerte_suchen) or state when not to use it, so it falls short of full routing guidance.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds real value by enumerating what comes back — the value in force on the date, all dated values, the legal norm, official source link, last-checked date and status — which no structured field provides.

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 with zero filler: the country scope is front-loaded, then the verb+resource+key examples, then the return contents. Every clause carries information an agent needs.

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, closed-world, idempotent single-value lookup with no output schema, the description is nearly complete because it enumerates the response fields itself. The remaining gap is failure behavior — what happens with an unknown or misspelled key, and whether keys are case-sensitive — which matters given a required free-form key parameter.

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 both parameters are already documented, establishing a baseline of 3. The description earns one step above baseline by clarifying that stichtag selects which dated value is returned ('the value valid on the given date, all dated values'), tying the parameter to observable output behavior rather than just restating 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?

States a specific verb and resource ('Look up one German employment law value (Rechtswert) by its key') with concrete key examples (mindestlohn, minijobGrenze, bbgRv, urlaubMindest) that make the resource tangible. It implicitly separates itself from the search-style sibling rechtswerte_suchen by emphasizing 'one ... by its key', but never names that sibling.

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 scope constraint 'Germany only' and the key-based lookup model are clear, and the key examples show the expected input shape. However, it never routes the agent: there is no statement about what to do when the key is unknown (presumably use rechtswerte_suchen) or when not to use this tool, so usage is only implied.

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 read-only, idempotent, non-destructive, closed-world. The description adds genuinely new behavior: the corpus size (215 values with norm, official source and review date), the hard result cap of 20 matches, and the effective-date semantics of returned values. It stops short of describing no-match behavior or whether the review date affects result ranking.

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, no filler. The jurisdiction gate ('Germany only') is front-loaded, followed by scope, corpus, and return shape in a natural scan order.

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 the work of naming the returned fields (key, title, value on the date, status), which is the critical gap filled. Missing only edge-case behavior — what happens with zero matches, and whether all three optional filters combine with AND 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 description coverage is 100% and the gebiet enum is fully enumerated, so the schema carries parameter meaning. The description adds only light context — that values are returned 'on the date' (explaining stichtag's effect) and that queries span domains like minimum wage or notice periods — but no syntax or matching-behavior detail 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?

Specific verb and resource: 'Search the register of German employment law values', scoped to 'Germany only' and quantified (215 values, up to 20 matches). It implicitly distinguishes itself from the singular sibling 'rechtswert' by framing this as a multi-result search, but never names that sibling explicitly, so it falls short of full 5-level sibling routing.

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 'Germany only' jurisdiction constraint and the notion of values applying 'on the date' imply when the tool is appropriate, but there is no explicit when-to-use/when-not guidance and no pointer to alternatives such as rechtswert or mindestlohn_check. Usage is inferable rather than stated.

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/closed-world, so safety is covered. The description adds real domain behavior beyond that: each threshold is counted the way its own statute counts (heads, part-time weighting, apprentices), and the result also reports what changes at the next threshold — context an agent needs to interpret the answer.

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?

Dense and front-loaded: jurisdiction, subject, counting logic, coverage list, then the trigger sentence. The only waste is the redundant 'Germany only' repeated at the start and end of a fairly long single block.

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 9-parameter tool with no output schema, the description conveys what the answer contains (applicable duties and the next-threshold deltas) and how inputs are interpreted. It does not say what the response format is or which of the many listed regimes are returned when several apply, 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 coverage is 100%, so the baseline is 3; the description goes slightly beyond by explaining that counting bases differ per statute, which is exactly why separate head-count, part-time-band and apprentice parameters exist. It does not map individual parameters, so it stays below a full 5.

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

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

States a specific domain and operation: German employment-law size thresholds (Schwellenwerte) and which duties apply at how many employees. It enumerates the concrete regimes covered (Betriebsrat, KSchG >10, U1 levy, BEM/quota, DPO, whistleblower), so an agent can tell instantly that none of the siblings answer 'what applies at our headcount'.

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?

Explicit trigger given: 'Use it when a founder asks what applies to a team of their size or what changes with the next hire.' That is a clear usage context, though no sibling alternative or exclusion case (e.g. individual dismissal questions go to kuendigungsfrist_rechnen) is named.

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

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

Annotations already declare this as a read-only, idempotent, non-destructive check with no open-world behavior. The description adds useful legal framing beyond annotations, including the trigger timing ('before the first working hour') and the statutory basis, though it does not describe the response shape.

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 front-loaded with the country restriction, then clearly states the check and the statutory industry scope. The industry list is long but each item is functional because it defines the legal applicability boundary.

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

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

For a one-parameter read-only legal check with no output schema, the description supplies the key missing context: country scope, legal basis, timing, and covered industries. It could be slightly more complete by explaining what the check returns or how 'keine' is interpreted, but the essential decision context is present.

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 parameter is a single required enum, so the schema already does most of the work. The description still adds meaningful semantics by translating the enum categories into English industry labels and tying them to the Sofortmeldepflicht sectors, although it does not explain the 'keine' option.

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: checking whether an employer must file an immediate registration (Sofortmeldung), with a clear legal basis (§ 28a Abs. 4 SGB IV). The scope is further narrowed by country and industry, making it easily distinguishable from unrelated sibling tools such as urlaubsanspruch or kuendigungsfrist_rechnen.

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: it applies only to Germany and is used to determine Sofortmeldepflicht by industry. It does not explicitly name alternatives or say when not to use it, but for this niche legal check the applicable context is sufficiently clear.

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

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

Annotations already declare this is a read-only, idempotent, closed-world check, so safety is covered. The description adds real context beyond that: it is Germany-only and it discloses the shape of the result (traffic light, authority whose consent is needed, protected period, steps before notice), which matters since no output schema exists.

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?

Four sentences, front-loaded with the jurisdiction gate and the outcome preview. The only waste is the repeated 'Germany only' at the start and end, which is redundant but plausibly intentional emphasis.

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 13-parameter, all-optional check with no output schema, the description supplies the missing return-value context and the pre-dismissal timing. It does not restate the 'unanswered counts as nein' default behavior, but the schema covers that, so nothing critical is absent.

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?

With 100% schema description coverage, each of the 13 enum parameters is already fully documented with ja/nein/unklar semantics and defaults. The description only lists ground categories, which roughly map to parameters but adds no interpretation beyond what the schema states, so baseline 3 applies.

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

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

States a specific verb and resource ('checks special protection against dismissal under German law'), enumerates the 11 grounds it evaluates, and previews the outputs (traffic light, consenting authority, protected period, next steps). This is unmistakably distinct from siblings like kuendigungsfrist_rechnen or kuendigung_pflichtangaben.

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?

Explicitly directs usage: 'Use it before any dismissal, also in small businesses,' which signals that the normal KSchG size threshold does not excuse skipping this check. It stops short of naming a sibling tool or stating when-not to use it, so it lands at 4 rather than 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds real value beyond them: it discloses what is returned (each risky word with Merkmal, reason, better wording, plus elements of a good ad) and the privacy trait that the ad text is neither stored nor returned. That storage policy is the kind of behavior an agent needs and cannot infer from 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 scope constraint is front-loaded and every sentence carries information (scope, when-to-use, return shape, privacy). However, "Germany only" appears twice in the same sentence, which is avoidable repetition.

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

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

For a single-parameter read-only check with no output schema, the description covers scope, trigger conditions, privacy behavior, and the shape of the response. Nothing an agent needs in order to call it or interpret the result 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%, so the constraint of 3000 characters and the "no names or contact details" rule are already documented in the schema. "Pass the ad text" adds no syntax or format detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (checks) and specific resource (German job ad / Stellenanzeige) with the governing legal framework (AGG). The resource is clearly distinct from every sibling tool (interviewfragen_check covers interview questions, klausel_pruefen covers contract clauses), so an agent can route to it on the resource alone.

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

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

"Use it before a founder publishes a job ad or after you drafted one: pass the ad text" gives explicit timing and a concrete call instruction. No exclusion or explicit alternative is named, which keeps it at 4 rather than 5.

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

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

The annotations already establish that this is a safe, read-only, idempotent calculation. The description adds meaningful context beyond that: the legal basis, the calculation sequence, the 13-week reference period, and the treatment of carry-over and days taken.

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 front-loaded with scope and purpose, then moves to the calculation method and usage trigger. It wastes some space by repeating 'Germany only' at both the beginning and the end.

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 complex legal calculation with 12 parameters and no output schema, the description provides the legal basis, calculation logic, and scope. It could say more about the return value or edge-case behavior, but the schema fully documents the inputs.

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 value by explaining how inputs interact: it describes adding carry-over, subtracting days taken, and multiplying open days by a daily rate derived from the last 13 weeks' pay. It does not map every parameter by name, but it adds useful calculation semantics.

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 calculation (payment in lieu of untaken holiday when employment ends), the legal basis, and the jurisdiction. It clearly distinguishes the tool from ongoing holiday-entitlement siblings by emphasizing the employment-ending scenario.

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

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

It gives a clear trigger: 'Use it when someone leaves with holiday left,' and a firm scope: 'Germany only.' It does not explicitly name alternatives such as urlaubsanspruch or explain when not to use it, so it falls short of the top score.

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 certify read-only, idempotent, non-destructive, closed-world behavior, so the description is free to add domain behavior instead: it discloses the legal basis (BUrlG, § 208 SGB IX), the fact the answer is split into statutory and contractual portions, and which edge cases are modelled (Teilzeit, alternating weeks, mid-year day changes, Teilurlaub). It does not say how the day counts are rounded, which matters for a calculation tool.

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

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

It is front-loaded and dense: scope, legal basis, computed quantities, handled cases, then the usage trigger. The only waste is the redundant "Germany only" appearing twice in the opening 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?

With 11 parameters and no output schema, the description does well to state that the result is a split between statutory minimum and Mehrurlaub. However, it never explains the shape or rounding of the returned day figures, which is exactly the information the missing output schema would otherwise have supplied.

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 per-field documentation already carries the weight and the baseline is 3. The description's enumeration of scenarios (part-time, alternating weeks, mid-year change, entry/exit, severe disability) does help an agent map a real question onto the right optional fields, but it adds no format or value semantics beyond what the schema states.

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

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

It names a precise resource (annual leave entitlement under BUrlG, in working days) and breaks it into statutory minimum versus contractual extra leave, so an agent immediately knows what is computed. It does not name or differentiate itself from close siblings such as urlaubsabgeltung or urlaubsverfall_hinweis, which keeps it from 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?

"Use it when someone asks how many leave days an employee has" is an explicit, actionable trigger, and "Germany only" is stated twice as a hard scope gate. There is no statement of when *not* to use it or which sibling to pick for the adjacent leave questions (payout, forfeiture).

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, non-destructive, and non-open-world behavior. The description adds meaningful context beyond that: it identifies the legal basis, says the output is a letter with placeholders, and summarizes returned fields including open days, expiry date, carry-over end, and lateness.

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 content is front-loaded and useful, but the opening repeats the same jurisdiction constraint redundantly: 'Germany only. German employment law, Germany only:' wastes space. The rest is reasonably efficient for a legal-domain tool.

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 ten-parameter legal tool without an output schema, the description covers the purpose, jurisdiction, legal basis, usage timing, and key return values. Parameter details are left to the schema, which is fully documented, but sibling routing could be more explicit.

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

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

Schema description coverage is 100%, so all ten parameters are already documented in the schema, including defaults, enums, and ranges. The description does not add parameter-level meaning beyond what the schema provides, so the baseline score 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 states a specific verb and resource: it writes the German employer notice required before unused leave expires, as a finished letter with placeholders. This is clearly distinct from entitlement or compensation tools, though it does not explicitly name sibling alternatives such as urlaubsanspruch or urlaubsabgeltung.

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 timing: at the start of the year or in autumn when someone asks how to prevent leave from accumulating or whether leave expires. It does not explicitly state when not to use it or name the most relevant alternatives.

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/non-destructive/closed-world, so the bar is lower, and the description still adds substantial behavior: it enumerates the return payload (fit, inputs with limits and defaults, norms, court rulings, safeguards, blocked items, German clause text with [Name] placeholder) and the partial-input failure mode. It does not cover localization beyond 'Germany only' or any caveats about the legal-informational nature of the output, which would have pushed this to a 5.

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

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

Front-loaded with the jurisdiction constraint and the core action in the first clause, then dense but load-bearing detail. The long enumeration of return contents is justified by the absence of an output schema, though it reads as a run-on list rather than cleanly separated points.

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

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

With no output schema, the description takes on the full burden of describing the return shape and does so field-by-field, plus the missing-input branch and the retry path. Jurisdiction, key format, and placeholder convention are all covered — an agent has everything needed to call this correctly on the first or second attempt.

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 baseline is 3, but the description adds real semantics: it explains that angaben is the retry channel for fields the tool reported as missing, and it illustrates key format and placeholder substitution. The specialized optional fields (eintritt, gehalt_monat, wochenstunden) are still only explained by the schema's 'only if the clause needs it' wording, not by the description.

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

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

States a specific verb and resource: 'Get one German employment contract clause (Vertragsbaustein) by key', reinforced by concrete key examples (B3, C2, D18). The 'by key' framing implicitly separates it from the search-oriented sibling vertragsbausteine_suchen, but that sibling is never named, so the differentiation is left to inference.

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

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

Gives a clear operative workflow: if required inputs are missing it lists them rather than emitting a gapped clause, and the agent should 'call again with angaben'. What is absent is the upstream routing — there is no mention of using vertragsbausteine_suchen to obtain the kennung, nor any when-not-to-use guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral information: results include the clause key and fit context, and void clause types are returned with the red-list reason and a safe alternative — a notable return-behavior detail absent from any structured field.

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 tight sentences with the jurisdictional constraint front-loaded and no filler. The parenthetical German term list is long but earns its place by anchoring search vocabulary for a non-English corpus.

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 carries the return-shape burden and does so adequately: matches plus keys plus fit, and separate void-clause results with reason and alternative. The only gap is how results are ranked or limited, which an agent might want to know before calling.

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 are already documented in the schema, including the German-language hint and the default for 'vertragsart'. The description's topic examples help query formulation but restate rather than extend 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?

Specific verb (search) plus a precisely scoped resource (126 German employment contract clauses), with concrete example topics that tell an agent exactly what corpus this covers. It stops short of explicitly naming the singular sibling 'vertragsbaustein' (the likely fetch-by-key tool), though 'returns matching clauses with key' hints at that handoff.

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?

'Germany only' sets a jurisdictional precondition, and the topic examples imply when to reach for this tool (looking up a clause subject). But there is no explicit statement of when to prefer it over siblings like 'vertragsbaustein' or 'klausel_pruefen', and no exclusions or when-not guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds that each entry contains a when/then chain with default days and roles and that omitting kennung returns all ten, but says nothing about output shape or size beyond that.

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 core content comes first, but the description opens with the fragment 'Germany only.' immediately repeated as 'German employment law, Germany only', which is wasted space. The example list is long and partly redundant with the enum values.

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 responsibly explains what each returned item contains (when/then chain, default days, roles) and the no-argument default. It falls short only on how entries relate to the overlapping sibling tools.

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

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

Schema coverage is 100% and the enum is self-explanatory, so the baseline is 3. The description earns an extra point by explicitly documenting the default behavior when kennung is omitted ('Without kennung it lists all ten'), which the schema itself does not state.

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

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

States a specific resource: the ten HR follow-up workflow templates of the Lintelly workbench, and explains their form ('when ... then' chains with default days and roles). It does not differentiate from siblings whose names mirror the kennung values (probezeit, mutterschutz, befristung, bem_pflicht), so an agent could confuse this collection with those detail 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?

'Use it as a template for your own reminders' gives one implied use case, but there is no statement of when to prefer a sibling (e.g. probezeit or mutterschutz) or when this tool is the wrong choice. Usage is inferable but not guided.

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