arbeitsagentur-mcp

Overview Schema Source Related Servers Discussions Admin

draft_letter

Drafts letters to the Agentur für Arbeit or Jobcenter using profile details for user review and signing; nothing is sent automatically.

Instructions

Draft a letter to the Agentur für Arbeit / Jobcenter using the profile (sender, Kundennummer, responsible office). The user must check, sign and send it; nothing is sent from here.

Input Schema

TableJSON Schema

Name	Required	Description
`log`	No	Also record the letter as outgoing correspondence
`kind`	Yes	widerspruch: Widerspruch gegen einen Bescheid. Params: decision_date, decision_subject, [reasons, request, reference, attachments]. Ohne reasons: fristwahrender Widerspruch mit Antrag auf Akteneinsicht.; akteneinsicht: Akteneinsicht (§ 25 SGB X) + DSGVO-Auskunft. Params: [topic, reference]; ueberpruefungsantrag: Überprüfungsantrag nach § 44 SGB X (auch nach Ablauf der Widerspruchsfrist). Params: decision_date, decision_subject, [reasons, reference]; veraenderungsmitteilung: Änderung der Verhältnisse melden (Umzug, Nebenjob, Arbeitsaufnahme, Familie, Einkommen). Params: change, effective_date, [attachments]; terminabsage: Termin absagen und Verlegung erbitten (nur mit wichtigem Grund). Params: appointment (z. B. '20.10.2026, 9:30 Uhr'), reason, [alternatives, attachments]; arbeitsunfaehigkeit: Krankmeldung. Params: since, [until, appointment]; rueckmeldung_vermittlungsvorschlag: Ergebnis eines Vermittlungsvorschlags melden. Params: position, employer, result, [proposal_date, job_reference, applied_on, channel]; bildungsgutschein: Antrag auf Bildungsgutschein. Params: course, provider, justification, [period, certification, attachments]; ortsabwesenheit: Zustimmung zur Ortsabwesenheit (Urlaub) beantragen. Params: from_date, to_date, [destination, reason, reachable]; freitext: Beliebiges Schreiben im Briefrahmen. Params: subject, body, [attachments]
`params`	Yes	Letter parameters (see kind). Common optional ones: recipient, reference, date, place, attachments (list)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 16, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is largely covered. The description adds the genuinely non-obvious behavioral trait: the tool produces a draft only and transmits nothing, and the 'log' parameter description reveals it can additionally record the letter as outgoing correspondence – a side effect not implied by the annotations alone.

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

Conciseness5/5

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

Two sentences, both earning their place: the first defines what is produced and from what, the second sets the boundary on what does not happen. Front-loaded with the action and free of restatement of the schema.

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?

An output schema exists, so return values need no explanation, and the annotations carry the safety profile. Given that, the description plus the richly documented kind enum and the 'log' flag cover everything an agent needs to draft the correct letter variant without sending anything.

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 description coverage is 100% and the kind enum documents per-kind required and optional parameters in detail, so the baseline is 3. The description still adds value by naming the profile-sourced fields (sender, Kundennummer, responsible office) and by framing params as 'see kind' with common optional extras, clarifying where the values come from.

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?

States a specific verb (draft) and resource (letter) plus the exact audience (Agentur für Arbeit / Jobcenter) and the data source (the profile). The closing clause 'nothing is sent from here' immediately distinguishes it from a send tool such as meineba_postfach_send, so an agent can triage it against siblings 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.

Usage Guidelines4/5

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

Gives clear context for when this applies (drafting official letters from stored profile data) and where the workflow stops (the user must check, sign and send). It does not name a sibling to use instead for actually transmitting the letter, nor does it point at log_correspondence for the logging path, so the routing guidance is contextual rather than explicit.

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

Deploy Server