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 establish that this is a read-only, idempotent, non-destructive operation, so the safety profile is covered. The description adds useful behavioral context: it is Germany-only, returns a workflow with dates, roles and legal norms, names specialised follow-up tools, and accepts only dates, numbers and choices, never names. It does not describe pagination or error behavior, but those are minor for a workflow generator.

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 key scope and usage instruction, and the scenario examples are useful. However, it repeats 'Germany only' and 'German employment law, Germany only' awkwardly, and the long parenthetical list of scenarios makes the prose less tight than it could be.

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

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

For a complex 17-parameter orchestration tool with no output schema, the description explains what the output is (a complete HR workflow with dates, roles and legal norms) and how it relates to specialised sibling tools. Combined with 100% schema coverage, this is largely complete, though it could say more about the expected output structure or required anchor date.

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 itself documents all 17 parameters in detail, including enums and date semantics. The description adds only the high-level constraint that inputs are dates, numbers and choices rather than names, without explaining specific parameters beyond what the schema already provides.

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

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

The description names a specific resource - a complete German HR workflow (Ablauf) with dates, roles and legal norms for a situation - and gives concrete scenarios such as first hire, sick employee, pregnancy and dismissal. It clearly distinguishes itself from the many specialised sibling tools by positioning itself as the first workflow tool that then names those specialised 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?

It states explicitly when to use it first: when a founder describes a situation such as a first hire, sick employee, pregnancy or planned dismissal. It also states the follow-up pattern: use the specialised tools it names for details, which directly routes the agent among siblings.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered; the description adds genuinely new behavioral context: jurisdiction lock (Germany only), a privacy constraint (no facts about persons go into the tool, roles instead of names), and the fact that it produces a self-help template rather than an actual letter sent. Return shape is only sketched, not detailed.

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?

Effectively one dense paragraph that front-loads the jurisdiction and the deliverable, then the usage rule. It loses a little to redundancy — 'Germany only' appears twice in the first sentence — but no sentence is otherwise wasted.

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 eight-parameter, no-output-schema tool the description covers the essential ground: what the agent gets back (template, rules, checklist, pitfalls), the jurisdiction restriction, and the data-handling rule. It does not describe the response's structure or ordering, which is the main remaining gap absent an output schema.

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

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

Schema description coverage is 100%, so all eight parameters are already documented with enums, patterns and defaults; a baseline of 3 applies. The description hints at parameter intent (Rüge with date and time, verletzte Pflicht) but adds no format, default or edge-case guidance beyond the schema, and never mentions the optional earlier-warning or salutation inputs.

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 precisely what the tool produces: the components of a formal Abmahnung (Rüge, verletzte Pflicht, Hinweis, Warnung), a letter template with placeholders, writing rules, a checklist and pitfalls. This is a concrete deliverable, not a restatement of the name, and an agent can distinguish it from siblings like 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?

Gives an explicit trigger ('when an employer wants to warn an employee about misconduct') plus a procedure: ask the user for the facts, then fill the template, using roles instead of third-party names. It does not name a competing sibling or a when-not-to-use condition, 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?

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?

Beyond the read-only/idempotent annotations, the description explains the returned content in detail: mandatory parts, Zeugnissprache codes, grade-to-satisfaction formula, traps, and legal basis. It also clarifies the workflow after the call: the agent writes the reference text from the returned structure and lets the user fill in names.

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

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

The description is compact and front-loads the jurisdiction and usage trigger before listing what the tool returns. It wastes some space by repeating 'Germany only' twice in the opening sentence, but otherwise every sentence contributes useful information.

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

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

For a 14-parameter tool with no output schema, the description is complete enough: it explains what the tool returns, what the agent should do with the result, and the legal boundaries (never names, § 109 GewO). An agent has enough context to invoke it correctly and use the output appropriately.

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 14 parameters are already fully documented with enums, defaults, date formats, and conditional behavior. The description adds only a high-level reminder to provide the reference kind and grades per area, without adding parameter-level meaning beyond the schema.

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

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

The description identifies a specific resource (German employment reference, including Zwischenzeugnis and Endzeugnis) and states exactly what the tool returns: structure, coded wording per grade, overall grade formula, forbidden codes, and the § 109 GewO claim. It also distinguishes the tool from sibling employment-law tools by focusing on reference drafting rather than termination, contracts, or deadlines.

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 trigger: use it when a founder wants a reference written, and instructs the agent to supply the kind of reference and grades per area while never providing names. It does not name alternatives or when-not-to-use cases, but no sibling tool directly overlaps with reference creation.

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 on top: the German-only jurisdiction, the AGG legal basis, and a breakdown of the return payload (forbidden topics with reasons, allowed questions, rating anchors, interview flow). It stops short of any length/format or freshness details, which keeps it at 4.

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 return content is front-loaded and useful, but the opening is redundant — 'Germany only' appears twice in the first sentence, and the long run-on sentence listing returns is dense. Trimming the duplicated jurisdiction clause and splitting the payload list would make it tighter without losing information.

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

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

With no output schema, the description takes on the job of describing the return value, and it does so in reasonable detail. Both optional parameters are fully documented in the schema, so nothing an agent needs in order to call it correctly is missing; only the exact output shape remains loosely specified.

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

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

Schema description coverage is 100% and both parameters are enums with per-value explanations, so the schema fully carries parameter meaning. The description never mentions 'form' or 'senioritaet', so it adds nothing beyond the schema, which is the baseline 3 case.

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 (checklist for job interviews / Vorstellungsgespräch, Interviewfragen) and enumerates what it returns: forbidden and sensitive topics with reasons, allowed questions, a structured-question method with rating anchors, and the interview flow. This clearly separates it from siblings like stellenanzeige_check or mitarbeitergespraech_leitfaden, which cover different HR artifacts.

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: 'Use it when a founder prepares an interview or asks whether a question is allowed, e.g. about pregnancy, religion, health or age under the AGG.' That is concrete and actionable. It does not name an alternative sibling or state when NOT to use it, beyond the 'Germany only' jurisdiction constraint.

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?

The annotations already declare readOnlyHint, idempotentHint, non-destructive behavior, and closed-world scope. The description adds useful context: German employment law only, checklist output where each item includes its legal norm, and the covered topics. It does not detail return formatting beyond the checklist concept, but with no output schema and strong annotations this is adequate.

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

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

The description is front-loaded with jurisdiction and purpose, but it repeats 'Germany only' twice and includes a long enumeration of checklist topics. The content is useful, yet the redundancy and length keep it from being maximally concise.

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

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

For a two-parameter, read-only checklist tool with no output schema, the description is reasonably complete: it states jurisdiction, purpose, covered items, legal-norm orientation, and a key alternative. Minor gaps remain around exact output structure and boundaries with other related sibling tools.

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

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

Schema description coverage is 100%, with both parameters fully documented in the schema. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description states a specific resource: a checklist of formal requirements when an employer gives notice (Kündigung durch den Arbeitgeber), each item with its legal norm. It explicitly distinguishes itself from the sibling kuendigungsschreiben by saying that tool is for the end date and the letter.

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 context: 'Use it before a dismissal', and names an alternative for the end date and the letter: kuendigungsschreiben. However, it does not clarify boundaries against other related siblings such as sonderkuendigungsschutz_check or klagefrist.

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 declare readOnly/idempotent/non-destructive/closed-world, and the description adds genuinely useful behavior: names, addresses and signer remain square-bracket placeholders the caller must fill, and the output includes a pre-send checklist (Schriftform § 623 BGB, Zugang, Vollmacht, Klagefrist). It stops short of saying what the returned artifact looks like (plain text vs. structured document).

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 and the core action, then the legal basis, placeholder convention and exclusions — dense and purposeful. The redundancy 'Germany only. German employment law, Germany only.' wastes a phrase and is the only real slack.

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 frame, jurisdiction, placeholder contract, checklist contents and exclusion cases. The remaining gap is the return type/format and how the many optional parameters (Freistellung, Resturlaub, Betriebsrat) shape the letter, though the schema fields are self-documenting.

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

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

Schema description coverage is 100%, so the schema already carries per-parameter meaning (Zugang vs. Briefdatum distinction, Probezeit default, Tarifvertrag caveat). The description only adds the overarching calculation rule (end date from Eintritt and Zugang under § 622 BGB) rather than deepening any individual parameter's 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?

States a specific verb+artifact ('Builds an employer's termination letter (Kündigungsschreiben, ordentliche Kündigung) in DIN 5008 form') with the calculation basis (§ 622 BGB from Eintritt and Zugang). It explicitly distinguishes itself from siblings by excluding summary dismissal (overlaps with sonderkuendigungsschutz_check/sofortmeldepflicht territory) and apprentices, and by scoping to Germany only.

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

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

Clear when-not guidance: 'Not for summary dismissal (fristlose Kündigung) or apprentices,' plus a jurisdiction gate ('Germany only') repeated for emphasis. It does not name the alternative sibling tools (e.g. kuendigungsfrist_rechnen for pure date math), so routing is implied rather than explicit.

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

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

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 cover the read-only, idempotent, non-destructive profile, and the description goes well beyond them: it discloses the returned sections (duration, preparation, phases, difficult moments, minutes template, legal traps like BEM/works council) and adds a follow-up workflow instruction ("write the exact wording for each phase"). The only blemish is the duplicated "Germany only" scoping rather than a single clean 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 useful and mostly front-loaded, but "Germany only" appears twice in the first sentence, and the last sentence is an instruction that could be a single clause. Small redundancies cost a point but nothing is bloated overall.

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

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

There is no output schema, so the description carries the return-value burden, and it does so explicitly by listing every returned section plus the expected follow-up step. Complete enough to call correctly; only the effect of the `betriebsrat` parameter on the returned legal traps 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%, including an enum description for `art`, so the baseline is 3. The description restates the four meeting types that map to the enum and hints that BEM/works-council traps exist, which loosely relates to the `betriebsrat` flag, but it does not explain what that flag actually changes in 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 specific resource (a guide for Mitarbeitergespräche) and enumerates the four concrete meeting types (Kritik-, Probezeit-, Jahres-, Rückkehrgespräch). No sibling tool produces meeting-conduct guides, so the agent can place it immediately without opening the 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 when a founder has to hold such a meeting" gives a usage context, but it never addresses when NOT to use it or how it relates to nearby siblings such as probezeit or abmahnung, which an agent could plausibly confuse with a probation-review guide. Usage is implied rather than disambiguated.

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 declare readOnly/idempotent/non-destructive, so safety is covered; the description adds real behavior — it works with partial input (start date alone yields the three deadline tiers), unanswered items are treated as open, and it evaluates form variants including the 2025 text-form rules. It does not describe the shape of the returned checklist, but with no output schema that gap is modest rather than severe.

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 scope and legal basis, and the three modes (deadlines, gap check, form check) are ordered logically. The phrase 'Germany only' appears twice and the opening sentence is long, which costs some efficiency.

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

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

Six optional parameters, a nested item list, and no output schema — the description nonetheless explains what each mode returns and the deadline model, which is what an agent needs to call it correctly. Only the concrete result format (per-item status vs. overdue flag) is left to inference.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds domain meaning the schema cannot: what the 15 items are used for, why the start date matters (deadline tiers of first working day, 7th calendar day, one month), and how form + fixed-term + paper-only industry interact. This is genuine added semantics rather than restatement.

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 and legal basis: a checklist of the 15 mandatory written terms under § 2 Abs. 1 NachwG, plus form requirements. It scopes the tool to Germany and to hiring/contract-checking, which separates it from siblings such as kuendigung_pflichtangaben (termination) or vertragsbaustein (drafting a clause).

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 hires someone or checks a contract', and describes the two input modes (start date only → deadlines; per-item answers → gaps/overdue). It also names the follow-on action (draft the missing clauses or written statement), but never points to a named sibling tool for that drafting step, so routing is implied rather than explicit.

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

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

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 declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description goes further by enumerating what comes back — the value valid on the given date, all dated values, the legal norm, the official source link, the last-checked date and its status — which matters because no output schema exists. It stops short of describing error behavior when a key is unknown or the value is absent for a date.

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 with no filler; the geographic scope and the lookup action lead, the return contents follow, and the escape hatch to rechtswerte_suchen closes it. Every sentence carries distinct 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 annotations covering safety and no output schema, this description covers scope, both parameters, return contents and the alternative tool — enough to call it correctly. The only residue is the not-found/no-value-for-date path, which is only obliquely implied by the pointer to rechtswerte_suchen.

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 earns more by naming four valid key spellings (mindestlohn, minijobGrenze, bbgRv, urlaubMindest) that illustrate the kennung naming convention. "Returns the value valid on the given date" also clarifies that stichtag selects the applicable value rather than filtering a list.

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 ("look up one German employment law value (Rechtswert) by its key") and immediately grounds it with four concrete key examples. The scoping prefix "Germany only" and the 1:1 lookup framing distinguish it cleanly from the sibling rechtswerte_suchen, the only other value-related 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?

It states the geographic applicability upfront ("Germany only") and explicitly routes the agent: "Use rechtswerte_suchen first if you do not know the key." That is a direct when-to-use-this-vs-alternative rule with the selecting condition named, leaving nothing to inference.

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

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

Annotations already 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 readOnly/idempotent/non-destructive, and the description adds genuinely useful behavior: the ad text is neither stored nor returned, and the response format (risky word + Merkmal + reason + better wording, plus good-ad parts) is disclosed. This goes beyond what the annotations provide.

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?

Mostly front-loaded with the scope, usage, and return value in a tight sequence. The phrase 'Germany only' is repeated twice, which is minor wasted space.

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 fully covers the return shape and privacy behavior, and the single parameter is documented in the schema. An agent has everything needed to call and interpret 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 coverage is 100% and the schema already documents anzeigentext (max 3000 chars, no names/contact details). The description only says 'pass the ad text', adding no format or syntax 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 (checks) and resource (a German job ad) against a named legal standard (AGG), and scopes it to Germany twice. This is clearly distinct from the other check siblings such as interviewfragen_check or klausel_pruefen.

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 when to use it — before a founder publishes an ad or after drafting one — and how to call it (pass the ad text). It doesn't name an alternative tool or exclusion cases, which keeps it just below 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?

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 handle the safety profile (readOnly, idempotent, closed-world, non-destructive), so the bar is lower. The description goes beyond them by disclosing the shape of the results: matching clauses with keys and applicability, plus red-list void clause types with reasons and safe alternatives — non-obvious content the agent would not otherwise anticipate.

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 short sentences, front-loaded with the 'Germany only' constraint and the corpus size, then the result shape, then the follow-up action. Every sentence carries distinct information with no repetition of the schema.

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 correctly takes on the job of explaining return values (keys, fit conditions, red-list entries with reasons and alternatives). Combined with the explicit hand-off to vertragsbaustein, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by supplying concrete German query vocabulary (Homeoffice, Überstunden, Dienstwagen, Wettbewerbsverbot, Probezeit) that guides how to phrase suchtext, beyond the single example already in the schema.

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

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

States a specific verb and resource ('Search 126 German employment contract clauses'), quantifies the corpus, and enumerates concrete clause topics so the agent knows exactly what is indexed. It also clearly separates itself from the sibling vertragsbaustein, which retrieves the actual text.

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

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

Explicitly defines the workflow: search here first, then call vertragsbaustein with the returned key to get the text, and it scopes the tool to Germany only. It stops short of stating when not to use it (e.g., versus klausel_pruefen for reviewing an existing clause), so there is still a small inference 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 establish readOnly, idempotent, non-destructive, and closed-world behavior, so the description only needs to add context. It does add jurisdiction scope ('Germany only. German employment law'), the template nature of the output, and the all-ten listing default. It does not describe output shape in detail, but annotations carry the safety profile.

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

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

The scope statement is front-loaded and every sentence carries routing or content information. The opening repeats itself slightly ('Germany only. German employment law, Germany only:'), which is minor redundancy but not wasteful enough to obscure the message.

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

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

A single optional enum parameter, read-only annotations, and no output schema mean the description's burden is low, and it still covers jurisdiction, what each workflow contains, the listing default, and the sibling to use for concrete dates. Nothing needed for correct invocation 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 the enum is fully documented, so the baseline is 3. The description goes further by mapping the German enum keys to real-world cases ('sick leave with eAU and BEM', 'fixed-term contract signed before start') and by clarifying that omitting kennung returns the full list, which helps an agent pick a value.

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

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

States a specific resource (the ten HR follow-up workflows of the Lintelly workbench) and enumerates concrete cases like payroll deadline, sick leave with eAU/BEM, maternity protection, and probation. It also defines the shape of what is returned ('when ... then ...' chains with default days and roles), which makes it clearly distinguishable from siblings such as ablauf.

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 routes the agent: 'Use it as a template for your own reminders; for dates in a concrete case use ablauf.' It also states the listing behavior when kennung is omitted, so both the when-to-use and when-not-to-use cases are covered.

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