Deutsche Reisekosten-Pauschalen 2026: Verpflegung Inland und BMF-Auslandssätze, km-Pauschale.
Scored across 4 tools
Each tool has a fairly distinct purpose: mileage calculation, meal allowance calculation, and two rate-lookup tools. However, pauschalen_land and pauschalen_alle_laender overlap heavily (one filtered, one full), and pauschalen_land vs verpflegung_berechnen could be confused between looking up rates and computing a trip total.
All names are snake_case and in German, which is readable and consistent at that level. But there are two different patterns: action-oriented names ending in _berechnen and retrieval-oriented names starting with pauschalen_, so the verb/noun convention is mixed.
Four tools is a well-scoped set for a travel-expense allowance server. Each tool covers a distinct calculation or lookup need without obvious redundancy or bloat.
The core domain—mileage, meal rates, and meal allowance calculation—is well covered. Minor gaps remain: there is no dedicated accommodation-cost calculation for a trip and no aggregation tool for total trip reimbursement, though agents can work around these with the provided rates.
Berechnet die Kilometerpauschale für Dienst- und Geschäftsreisen mit dem eigenen Fahrzeug: PKW 0,30 € je km, Motorrad 0,20 € je km. Nicht die Entfernungspauschale für den Arbeitsweg.
| Name | Required | Description | Default |
|---|---|---|---|
| km | Yes | Gefahrene Kilometer, bei hin_und_rueck die einfache Strecke. | |
| fahrzeug | No | pkw | |
| hin_und_rueck | No | true verdoppelt die Strecke für Hin- und Rückfahrt. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already fully declare the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so no side-effect disclosure is needed. The description adds the pricing logic (0.30/0.20 € per km), which is useful behavioral context, but says nothing about boundaries beyond the schema (e.g. rounding, output 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?
Two tight sentences with zero filler, front-loading the core purpose and rates before the exclusion. Every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a pure calculation tool with no output schema, the description supplies the rate constants an agent needs to anticipate the result. Combined with annotations that cover the safety profile, only minor gaps remain (rounding/format of the returned value).
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 67% and already documents km and hin_und_rueck, while fahrzeug carries only an enum. The description compensates by mapping the vehicle enum values to their rates (PKW 0,30 €, Motorrad 0,20 €), adding meaning the schema does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (berechnet) and resource (Kilometerpauschale) and even names the exact rates. It explicitly excludes a related but distinct concept (Entfernungspauschale für den Arbeitsweg). However, it does not reference the sibling tools (pauschalen_land, verpflegung_berechnen), so sibling differentiation is left implicit.
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?
Clearly scopes usage to Dienst- und Geschäftsreisen with the employee's own vehicle, and gives an explicit exclusion (not the commuting Entfernungspauschale). It lacks any routing to the sibling pauschale/verpflegung tools, but the when-to-use condition is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liefert die Verpflegungs- und Übernachtungspauschalen 2026 für Deutschland und alle Länder der BMF-Tabelle als Liste.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the data scope and reference year (2026, BMF-Tabelle) and the list return shape, but says nothing about freshness, caching, or how the static table is sourced.
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?
A single front-loaded sentence that identifies the verb, the data, the year, the coverage, and the return format with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with no output schema, the description is nearly sufficient; only the per-entry field structure of the returned list is left unspecified, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool 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 ('Liefert') and resource ('Verpflegungs- und Übernachtungspauschalen 2026') with clear scope ('Deutschland und alle Länder der BMF-Tabelle') and output form ('als Liste'). The plural 'alle Länder' implicitly distinguishes it from the sibling pauschalen_land, though the sibling is never 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?
There is no explicit when-to-use or when-not guidance. The contrast with pauschalen_land (single country) is only inferable from 'alle Länder', and no alternative is named, so an agent must guess which sibling to pick for a one-country lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liefert die steuerlichen Verpflegungspauschalen 2026 für Deutschland oder ein Land der BMF-Tabelle: voller Tag, An- und Abreisetag (auch eintägig über 8 Stunden), Kürzungen für gestellte Mahlzeiten und die Übernachtungspauschale.
| Name | Required | Description | Default |
|---|---|---|---|
| land | No | Ländercode nach ISO 3166-1 alpha-2, z. B. DE, AT, FR. Ohne Angabe: Deutschland. |
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). Beyond that, the description discloses substantive domain behavior: which allowance categories are computed (full day, arrival/departure day including the >8h single-day rule, meal reductions, overnight rate). It does not state the return format or currency, but the added computational context is real value.
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?
A single front-loaded sentence that leads with the core purpose before enumerating the allowance categories. Dense but with no filler; the colon list of sub-allowances is slightly heavy but each item earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing what is returned, and it does so by enumerating the computed allowance categories. Combined with 100% parameter coverage and full annotation coverage, an agent has enough to call it correctly; only the value format (e.g., EUR amounts) is 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%: the single 'land' parameter is fully documented as an ISO 3166-1 alpha-2 code with a Germany default. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Liefert') and a precise resource ('steuerlichen Verpflegungspauschalen 2026') scoped to one country. The per-country scope implicitly distinguishes it from the sibling pauschalen_alle_laender, so an agent can route between them 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?
Usage is implied by the scope ('für Deutschland oder ein Land der BMF-Tabelle'), and the description names the default when no country is given. However, it never explicitly says when to prefer this over pauschalen_alle_laender or verpflegung_berechnen, leaving the agent to infer the choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Berechnet den Verpflegungsmehraufwand einer Reise: eintägig nach Stunden (mehr als 8 Stunden), mehrtägig mit An- und Abreisetag und vollen Tagen. Bei Reisen durch mehrere Länder gilt je Tag das Land aus laender. Gestellte Mahlzeiten je Reisetag werden gekürzt.
| Name | Required | Description | Default |
|---|---|---|---|
| land | No | Ländercode nach ISO 3166-1 alpha-2, z. B. DE, AT, FR. Ohne Angabe: Deutschland. | |
| tage | Yes | Kalendertage der Reise inklusive An- und Abreisetag. | |
| laender | No | Nur bei Reisen durch mehrere Länder: Land je Reisetag, Tag 1 ist der Anreisetag. Tage ohne Eintrag nutzen land. Nach BMF in der Regel das Land, das vor 24 Uhr Ortszeit zuletzt erreicht wird; am Abreisetag das Land des letzten Tätigkeitsorts. | |
| mahlzeiten | No | Gestellte Mahlzeiten (Arbeitgeber, Hotel, Veranstalter) je Reisetag, Tag 1 ist der Anreisetag. | |
| stunden_eintaegig | No | Nur bei tage = 1: Stunden abwesend von Wohnung und erster Tätigkeitsstätte. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive and closed-world behavior, so the description is free to add domain behavior — the >8-hour threshold for one-day trips, the treatment of arrival/departure days, and the deduction of employer-provided meals. That is substantive context beyond the structured fields, though it says nothing about the shape of 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?
Three dense sentences with the core operation front-loaded, then the multi-country rule and the meal deduction. No filler, though the clauses are packed tightly and could be slightly better separated.
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 rules-heavy tax calculation with a rich input schema but no output schema, the description covers the input-side logic well but never indicates what comes back (per-day amounts, total, breakdown) nor the link to the rate-lookup siblings. Adequate, but an agent lacks a picture of 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 the schema already documents land, tage, laender, mahlzeiten and stunden_eintaegig. The description restates the laender rule and adds that provided meals are 'gekürzt', which clarifies effect rather than syntax; with the schema doing the heavy lifting, the 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 verb and resource ('Berechnet den Verpflegungsmehraufwand einer Reise') and enumerates the calculation modes (single-day by hours, multi-day with arrival/departure plus full days). It does not explicitly contrast itself with the sibling pauschalen_* lookup tools, so an agent must infer that this one computes rather than returns raw rates.
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 context for the two calculation paths (eintägig vs. mehrtägig) and states the condition under which the 'laender' parameter applies ('Bei Reisen durch mehrere Länder'). It stops short of naming pauschalen_land or pauschalen_alle_laender as the alternative for pure rate lookup, so no explicit exclusion is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
verpflegung_berechnen1 field changedInput schema / properties / laenderAdded value: +{
+ "description": "Nur bei Reisen durch mehrere Länder: Land je Reisetag, Tag 1 ist der Anreisetag. Tage ohne Eintrag nutzen land. Nach BMF in der Regel das Land, das vor 24 Uhr Ortszeit zuletzt erreicht wird; am Abreisetag das Land des letzten Tätigkeitsorts.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "land": {
+ "description": "Ländercode nach ISO 3166-1 alpha-2, z. B. DE, AT, FR. Ohne Angabe: Deutschland.",
+ "pattern": "^[A-Za-z]{2}$",
+ "type": "string"
+ },
+ "tag": {
+ "minimum": 1,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "tag",
+ "land"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}kilometerpauschale_berechnenpauschalen_alle_laenderpauschalen_landverpflegung_berechnenCompliant per diems in one call: official US GSA, German BMF and UK HMRC rates, with a trip…
German 2026 tax and social-insurance thresholds, minimum wage and allowances, sourced.
IRS mileage rates 2011-2026 (76 cents from July 2026), GSA per diem by ZIP FY2026-27, high-low.
Travel allowances from bundled Polish, HMRC and GSA rate tables, with partial days and meals.
Add one secure layer between your agents and this server.
