Referendariat und Beihilfe für Lehrkräfte in allen 16 Bundesländern: Fahrplan, Fristen, Pension.
Scored across 6 tools
Each tool maps to a clearly separate question: pay level (anwaerterbezuege), state-specific rules (regeln_bundesland), application deadlines (starttermine), pension math (pension_berechnen), a personal action plan (fahrplan_erstellen), and an advisory link (beratung_anfragen). The boundary between the two state-parameter tools (pay vs. Beihilfe/fristen) is explicitly spelled out by the descriptions. An agent should have no trouble selecting the right one.
Three names follow a noun+verb pattern (fahrplan_erstellen, pension_berechnen, beratung_anfragen), but two are bare plural nouns (anwaerterbezuege, starttermine) and one is noun+noun (regeln_bundesland). The German compounds are readable and thematically coherent, but there is no single predictable pattern an agent can extrapolate from.
Six tools for a narrow niche (Referendariat guidance for one country's teacher trainees) is well-scoped and each tool earns its place. The surface is on the lean side — no lookup helper or cross-state comparison tool — but nothing feels redundant.
The lifecycle is largely covered: entry pay, deadlines, state rules, long-term pension, and a personalized deadline plan, plus a handoff to human advising. Minor gaps remain, e.g. no tool to compute net pay or insurance/Beihilfe cost impact, which the fahrplan deliberately only flags by need rather than by numbers. Agents can work around these but will hit a wall on cost estimation.
Anwärtergrundbetrag im Referendariat für ein Lehramt mit Eingangsamt A 13, je Bundesland mit Quelle und Stand. Brutto im Monat, ohne Familienzuschlag und Zulagen.
| Name | Required | Description | Default |
|---|---|---|---|
| land | No | Bundesland als Slug, Name oder Kürzel, zum Beispiel bayern, Nordrhein-Westfalen oder BW. Weglassen für alle Länder. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotent/non-destructive, so safety is covered. The description usefully adds scope beyond that: values are gross monthly, exclude Familienzuschlag and Zulagen, and each figure carries a source and as-of date — meaningful context about what the data does and does not represent.
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, front-loaded with the core resource and followed by the qualifiers (brutto, ohne Zusatzleistungen) and provenance. 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 single-optional-parameter read tool with no output schema, the description communicates what the returned figure represents and its caveats. Adding a hint about the response shape or the source/Stand format would make it fully 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% and the 'land' parameter already documents slug/name/abbreviation forms and the omit-for-all behavior. The description adds no further parameter detail, 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 resource (Anwärtergrundbetrag im Referendariat für Lehramt A 13) and the granularity of the result (je Bundesland mit Quelle und Stand). It is clearly distinguishable from siblings like pension_berechnen or regeln_bundesland, though it never names or contrasts them.
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 only implied: the reader infers this is a lookup for trainee base pay, and the schema alone says to omit 'land' for all states. There is no explicit when-to-use/when-not or pointer to alternatives such as pension_berechnen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gibt einen vorbefüllten Link zum Ref-Check oder zum Kontaktformular von Lehrerbegleiter zurück. Sendet selbst nichts ab und legt keine Anfrage an: Die Person öffnet den Link, prüft ihre Angaben und schickt sie selbst ab. Keine Gesundheitsdaten übergeben.
| Name | Required | Description | Default |
|---|---|---|---|
| weg | No | ref-check = Fahrplan und Anfrage in einem (Standard), kontakt = kurze Nachricht an den Makler | |
| land | No | Bundesland als Slug, Name oder Kürzel, zum Beispiel bayern, Nordrhein-Westfalen oder BW. | |
| start | No | JJJJ-MM | |
| status | No | ||
| themen | No | Themen für das Gespräch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false. The description goes beyond them by explaining the handoff mechanism (the recipient reviews and submits) and adding a privacy constraint not to pass health data, which is genuine behavioral context. Link lifetime/validity and what a generated link looks like are still undisclosed, so not 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?
Three tight sentences: what is returned, what it explicitly does not do, and the data-protection caveat. The key constraint is front-loaded and no sentence is 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?
With five optional parameters, no output schema and strong annotation coverage, the description gives enough for correct invocation, including the safety-relevant caveat. It could say more about which parameters are meaningless for which 'weg' branch, but nothing essential 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 80% and each parameter carries its own description, including the enum meanings for 'weg' and slug examples for 'land'. The description adds no parameter-level information, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and resource: it returns a pre-filled link to either the Ref-Check or the Kontaktformular. The two output paths are named, so the agent understands what is produced. It never references the sibling tools (fahrplan_erstellen, starttermine, etc.), so explicit differentiation is missing, which keeps it at 4.
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 makes the usage model clear: the tool only hands off a link and the person completes the submission themselves, so the agent must not treat it as an inquiry-submission tool. It clearly excludes the submit/creation use case, but it offers no explicit guidance on when to prefer it over the sibling planning/calculation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Erstellt den persönlichen Fahrplan für Krankenversicherung, Beihilfe, Diensthaftpflicht, Dienstunfähigkeit und Pension rund um das Referendariat, mit Fristen als Datum. Nennt Bedarf und Fristen, keine Tarife und keine Versicherer.
| Name | Required | Description | Default |
|---|---|---|---|
| kv | No | heutige Krankenversicherung | |
| land | Yes | Bundesland als Slug, Name oder Kürzel, zum Beispiel bayern, Nordrhein-Westfalen oder BW. | |
| start | No | Beginn von Referendariat oder Planstelle als JJJJ-MM | |
| kinder | No | ||
| status | No | studium = noch im Studium, zusage = Ref beginnt bald, ref = schon im Ref, planstelle = Beamter auf Probe | |
| verband | No | Mitglied in GEW, VBE oder Philologenverband |
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, closed-world operation. The description adds useful behavioral context beyond annotations: it returns a personal plan with deadlines as dates and names needs and deadlines, while explicitly excluding tariffs and insurers.
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 two tightly written sentences. It front-loads the main purpose and follows with the output scope and exclusions, with no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, high schema coverage and rich annotations, the description is largely complete. It clarifies the plan's content and deadlines and sets exclusions, though it could say more about when to choose this tool over its siblings.
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 high at 83%, so the schema already documents most parameters including land, start, status, kv, kinder and verband. The description does not add parameter-level 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 verb and resource: it creates a personal roadmap covering Krankenversicherung, Beihilfe, Diensthaftpflicht, Dienstunfähigkeit and Pension around the Referendariat. It is clear what the tool does, though it does not explicitly differentiate itself from siblings such as pension_berechnen or starttermine.
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 phrase 'rund um das Referendariat' implies the usage context, and the exclusion of tariffs and insurers sets a content boundary. However, it does not explicitly say when to use this tool instead of siblings like pension_berechnen, starttermine or regeln_bundesland.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rechnet den Ruhegehaltssatz nach § 14 BeamtVG: 1,79375 Prozent je ruhegehaltfähigem Dienstjahr, höchstens 71,75 Prozent. Optional mit Abschlag von 3,6 Prozent je Jahr vor der Altersgrenze, höchstens 10,8 Prozent, und mit Betrag in Euro.
| Name | Required | Description | Default |
|---|---|---|---|
| bezuege | No | ruhegehaltfähige Dienstbezüge in Euro brutto im Monat (optional) | |
| dienstjahre | Yes | ruhegehaltfähige Dienstjahre, Teile eines Jahres als Dezimalzahl | |
| jahre_vor_altersgrenze | No | Jahre, die der Ruhestand vor der Altersgrenze beginnt (optional, für den Abschlag) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive, lowering the burden. The description adds useful calculation details (rate per year, caps, discount logic), but does not describe the return format or output structure.
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 sentence packs the core formula, limits, and optional discount details without redundancy. The main calculation is front-loaded, and every phrase contributes to understanding the tool's behavior.
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 calculation tool with rich schema coverage and safety annotations, the description provides sufficient detail on the formula and parameter effects. However, it does not describe what the tool returns (e.g., a number or object), which is a minor gap given no 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 coverage is 100%, so the schema already defines each parameter. The description adds semantic meaning by linking parameters to the calculation logic (e.g., 3.6% discount per year before age limit, maximum 10.8%), going beyond the schema's field descriptions.
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 ('Rechnet') and resource ('Ruhegehaltssatz nach § 14 BeamtVG'), and gives the exact formula. It does not explicitly differentiate from sibling tools, but the purpose is unambiguous.
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 calculation nature; no explicit when-to-use or when-not-to-use guidance is given, and alternatives are not mentioned. An agent can infer the tool is for pension rate computation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Beihilfe-Sätze, pauschale Beihilfe, zuständige Beihilfestelle, Fristen, Dauer des Vorbereitungsdienstes und Altersgrenze für die Verbeamtung eines Bundeslands. Jeder Wert mit Quelle und Stand.
| Name | Required | Description | Default |
|---|---|---|---|
| land | Yes | Bundesland als Slug, Name oder Kürzel, zum Beispiel bayern, Nordrhein-Westfalen oder BW. |
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 fully covered. The description adds one genuinely useful behavioral fact — every value carries a source and as-of date — but says nothing about what happens with an unrecognized Bundesland input.
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 compact sentences, no filler, with the substantive field list front-loaded and the provenance caveat placed last. Every clause maps to something 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?
With no output schema, the description usefully enumerates the returned fields, which is exactly what an agent needs to judge relevance. For a read-only single-parameter lookup whose annotations already cover safety, only error behavior for invalid state inputs 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 single 'land' parameter already documents accepted forms (slug, full name, abbreviation with examples). The description adds no further detail about the parameter, 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 enumerates exactly what the tool returns for one Bundesland: Beihilfe rates, pauschale Beihilfe, competent office, deadlines, Vorbereitungsdienst duration and age limit. It is specific about the resource but never frames the action ('liefert/ruft ab'), and it does not name which sibling handles the adjacent questions (pension_berechnen, anwaerterbezuege).
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 only implied: an agent can infer this is the reference-lookup tool for state-specific Beamten rules. There is no explicit when-to-use, when-not-to-use, or pointer to an alternative such as pension_berechnen for actual calculations, even though siblings overlap in domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Nächste Einstellungstermine für den Vorbereitungsdienst (Referendariat) und die zugehörigen Bewerbungsfristen, für ein Bundesland oder alle 16.
| Name | Required | Description | Default |
|---|---|---|---|
| ab | No | Nur Termine ab diesem Tag (JJJJ-MM-TT), Standard heute | |
| land | No | Bundesland als Slug, Name oder Kürzel, zum Beispiel bayern, Nordrhein-Westfalen oder BW. Weglassen für alle Länder. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld=false=false, so the safety profile is covered. The description adds that only upcoming dates ('Nächste') are returned with their application deadlines, but it says nothing about the shape of each result (e.g. Land, Termin, Frist), which would be the valuable extra context here.
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 with zero filler; the resource, the pairing with deadlines, and the scope are all stated before any parameter detail. Nothing repeats the title or annotations unnecessarily.
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 low-complexity, read-only, two-optional-parameter tool with full schema coverage and rich annotations, the description is sufficient to call it correctly. The only minor gap is the absence of any hint about the returned entry structure, which matters slightly given there is no 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 both 'ab' and 'land' are already documented with format, examples and defaults. The description reinforces the 'alle 16' behavior of 'land' but adds no syntax or format detail beyond the schema, matching the baseline for full-coverage schemas.
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 — upcoming Einstellungstermine for the Referendariat together with their Bewerbungsfristen — and states the scope (one Bundesland or all 16). It does not name a sibling, but no sibling tool overlaps in topic, so an agent can still select it 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?
It gives clear context for the two usage modes ('für ein Bundesland oder alle 16'), which maps directly onto the optional 'land' parameter. There are no explicit exclusions, but none are needed since the sibling tools address unrelated topics.
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.
anwaerterbezuegeberatung_anfragenfahrplan_erstellenpension_berechnenregeln_bundeslandstarttermineDeutsche Reisekosten-Pauschalen 2026: Verpflegung Inland und BMF-Auslandssätze, km-Pauschale.
German AVGS/AZAV tools: B-DKS 2026 cost rates, AVGS deadlines, official BA forms, glossary
German yoga teacher trainings: hours, format, certification, Bildungsurlaub, with sources.
German public tenders (190k+) and procurement-law calculators with legal basis. Free, no sign-up.
Add one secure layer between your agents and this server.