Lintelly HR Deutschland

Elternzeit-Fristen

elternzeit_fristen

Read-onlyIdempotent

German employment law, Germany only: deadlines for parental leave (Elternzeit, §§ 15 to 18 BEEG). Returns the last day the request must reach the employer (7 weeks, 13 weeks after the 3rd birthday), the required form, start and end of protection against dismissal (Kündigungsschutz), the end of maternity protection for the mother and the possible cut of annual leave (Urlaubskürzung). Use it when an employee announces parental leave or a request has arrived.

Input Schema

Name	Required	Description
`ende`	Yes	Last day of parental leave (YYYY-MM-DD)
`beginn`	Yes	First day of parental leave (YYYY-MM-DD)
`geburt`	Yes	Child's date of birth, or the expected date if not born yet (YYYY-MM-DD)
`teilzeit`	No	Employee works part-time for you during parental leave
`elternteil`	No	Who takes the leave: mutter (mother) or anderer (father or other parent). Default anderer
`jahresurlaub`	No	Annual leave in days, optional, for the possible cut
`antrag_zugang`	No	Day the request reached the employer, optional (YYYY-MM-DD)
`beschaeftigte`	No	Employees without apprentices, optional, decides the claim to part-time (more than 15)
`errechneter_termin`	No	Mother only, child born: expected date of delivery if the child came early, extends maternity protection (YYYY-MM-DD)
`noch_nicht_geboren`	No	true if the child is not born yet, geburt is then the expected date
`mutterschutz_12_wochen`	No	Mother only: premature or multiple birth or disability, maternity protection 12 instead of 8 weeks after birth

Output Schema

Name	Required	Description
`stand`	Yes
`fallen`	No
`hinweis`	Yes
`quellen`	Yes
`ergebnis`	Yes	Result of the tool; its fields differ per tool
`rechenweg`	No
`herausgeber`	Yes
`naechster_schritt`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 31, 2026

addedInput schema / properties / antrag_zugang / format
```
Added value: +"date"
```
addedInput schema / properties / beginn / format
```
Added value: +"date"
```
addedInput schema / properties / ende / format
```
Added value: +"date"
```
addedInput schema / properties / errechneter_termin / format
```
Added value: +"date"
```
addedInput schema / properties / geburt / format
```
Added value: +"date"
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "ergebnis": {
+      "description": "Result of the tool; its fields differ per tool"
+    },
+    "fallen": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "herausgeber": {
+      "type": "string"
+    },
+    "hinweis": {
+      "type": "string"
+    },
+    "naechster_schritt": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "quellen": {
+      "items": {
+        "properties": {
+          "geprueft_am": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "grund": {
+            "type": "string"
+          },
+          "norm": {
+            "type": "string"
+          },
+          "status": {
+            "enum": [
+              "bestätigt",
+              "noch nicht bestätigt",
+              "Prüfung überfällig"
+            ],
+            "type": "string"
+          },
+          "url": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "norm"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "rechenweg": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "stand": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "ergebnis",
+    "quellen",
+    "hinweis",
+    "stand",
+    "herausgeber"
+  ],
+  "type": "object"
+}

First observedOct 23, 2026

TDQS

A3.9/5.0

Behavior4/5

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 useful context beyond that: it is a jurisdiction-bound (Germany only) statutory calculator, and it names the statutory rules it applies (7 weeks / 13 weeks after the 3rd birthday) plus which outputs depend on optional inputs. It does not say what happens when optional parameters are omitted.

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

Conciseness4/5

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

Two sentences, front-loaded with jurisdiction and legal basis before the output list. The output enumeration is dense but each item corresponds to something an agent must report back, so it earns its space. Slightly run-on, but no filler.

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

Completeness4/5

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

With an output schema present, the description needn't explain return values, yet it does so helpfully. For an 11-parameter statutory calculator, the main remaining gap is guidance on when the optional parameters (antrag_zugang, beschaeftigte, errechneter_termin) must be supplied versus left out; otherwise an agent has enough to call it correctly.

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

Parameters3/5

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

Schema coverage is 100% with per-field descriptions, so the schema already carries the parameter burden and the baseline is 3. The description indirectly maps outputs to optional inputs (Urlaubskürzung implies jahresurlaub, maternity-protection end implies elternteil/errechneter_termin/mutterschutz_12_wochen) but never states parameter-level meaning or conditions for supplying them.

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

Purpose4/5

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

States a specific verb-and-resource: computing statutory parental-leave deadlines under §§ 15-18 BEEG, scoped to Germany, and enumerates the concrete values returned (request deadlines, Kündigungsschutz window, maternity-protection end, leave cut). That is far more specific than the name alone. It stops short of naming which sibling it is not (e.g., mutterschutz, frist_merken), even though it partly overlaps them.

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

Usage Guidelines4/5

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

"Use it when an employee announces parental leave or a request has arrived" gives a concrete triggering situation rather than a vague hint. There are no explicit exclusions or alternative tools mentioned, which matters because mutterschutz and frist_merken sit adjacent in coverage. Clear context, but no routing.

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

All Lintelly HR Deutschland tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.