Lintelly HR Deutschland

Urlaubsanspruch

urlaubsanspruch

Read-onlyIdempotent

German employment law, Germany only: annual leave entitlement (Urlaubsanspruch, BUrlG) in working days, split into statutory minimum (gesetzlicher Mindesturlaub) and contractual extra leave (Mehrurlaub). Handles part-time (Teilzeit), alternating weeks, a change of working days during the year, entry or exit during the year (Teilurlaub) and extra leave for severe disability (§ 208 SGB IX). Use it when someone asks how many leave days an employee has.

Input Schema

Name	Required	Description
`jahr`	No	Leave year, default the current year
`austritt`	No	Last day of employment if in the year, optional (YYYY-MM-DD)
`eintritt`	No	Entry date if in or after the start of the year, optional (YYYY-MM-DD)
`mehrurlaub`	No	Contract rule for extra leave on entry or exit in the year: wie-gesetz (contract says nothing, follows the law) or anteilig (contract cuts it pro rata). Default wie-gesetz
`wechsel_ab`	No	Day the number of working days changes, optional (YYYY-MM-DD)
`bezugswoche`	No	Reference week of the contract: 5_tage (working days) or 6_tage (Werktage). Default 5_tage
`jahresurlaub`	Yes	Annual leave in the contract for full time, in days of the reference week
`wechsel_tage`	No	Working days per week from wechsel_ab
`schwerbehindert`	No	Recognised severe disability (GdB from 50), not equal status
`schwerbehindert_ab`	No	Recognised only from this date in the year, optional (YYYY-MM-DD)
`arbeitstage_pro_woche`	Yes	Days with work per week, each day counts fully however short; average for alternating weeks, e.g. 2.5

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.

Changed7 schema fields changedOct 31, 2026

addedInput schema / properties / austritt / format
```
Added value: +"date"
```
addedInput schema / properties / eintritt / format
```
Added value: +"date"
```
changedInput schema / properties / jahr / minimum
```
Previous value: -2000New value: +1950
```

changedInput schema / properties / jahr / type

Previous value: -"number"New value: +"integer"

addedInput schema / properties / schwerbehindert_ab / format
```
Added value: +"date"
```
addedInput schema / properties / wechsel_ab / 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

A4.4/5.0

Behavior4/5

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 needs no restating. The description instead adds real coverage context: which legal fact patterns are handled (Teilzeit, alternating weeks, mid-year working-day change, Teilurlaub, § 208 SGB IX) and the statutory-vs-contractual split, which tells the agent the valuation logic and its limits.

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?

Jurisdiction and resource are front-loaded in the first clause, and each subsequent enumeration maps to a supported input case rather than padding. It is dense and list-like but no sentence is disposable.

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

Completeness5/5

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

With 11 parameters and an output schema, the description still covers every scenario the inputs expose (part-time, alternating weeks, mid-year change, entry/exit, disability) and states the legal basis. Nothing critical is left for the agent to guess about scope or applicability.

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

Parameters4/5

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 supplies the legal concepts behind the parameters — gesetzlicher Mindesturlaub vs Mehrurlaub, Teilurlaub on entry/exit, and severe disability under § 208 SGB IX. That explains why inputs like mehrurlaub and schwerbehindert exist, adding meaning beyond the field-level text.

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

Purpose5/5

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

The description names a specific resource (annual leave entitlement under BUrlG) and states exactly what the tool returns: working days split into statutory minimum and contractual Mehrurlaub. The clause 'Use it when someone asks how many leave days an employee has' plus 'Germany only' cleanly separates it from adjacent siblings like urlaubsabgeltung (payout) and urlaubsverfall_hinweis (expiry).

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?

There is an explicit trigger ('when someone asks how many leave days an employee has') and a jurisdictional exclusion ('German employment law, Germany only'). No alternative is named for the neighbouring payout/forfeiture tools, so the agent must infer that boundary itself.

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.