falzmarke

brief_rendern

Renders Markdown business letters or certificates to PDF and measures the result against target dimensions, returning a layout report so spacing or fold-mark errors are caught before printing.

Instructions

Setzt einen Brief und misst ihn nach — oder eine Urkunde.

Trägt das Frontmatter typ: urkunde, entsteht ein Schriftstück ohne Anschriftfeld: Titel, auf Wunsch zwei Parteien, Unterschriftslinien. Dafür gelten eigene Felder (titel, parteien, unterschriften, ort_datum, seiten_max) und eigene Maße — Setzungen des Werkzeugs, keine der DIN 5008. Das Ergebnis nennt unter typ, nach welcher Liste gemessen wurde.

brief Markdown mit Frontmatter — der Text selbst, nicht ein Pfad. Ein KI-Client hat den Brief im Kontext, nicht auf einer Platte. profil Name eines Profils auf dem Server oder ein ganzes Profil-Objekt. Fehlt beides, gilt das im Frontmatter genannte. form "A" oder "B"; ohne Angabe entscheidet Frontmatter oder Profil. Eine Urkunde hat keine Form — dort nicht angeben. als "pfad" (Vorgabe) oder "base64". ziel Wohin das PDF soll. Ohne Angabe in ein Temporärverzeichnis, das stehen bleibt — der zurückgegebene Pfad muss gültig sein.

Der Messbericht ist immer dabei.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "brief": "<brief>"
    },
    "name": "brief_rendern"
  }
}

Input Schema

Name	Required	Default
`als`	No	pfad
`form`	No
`ziel`	No
`brief`	Yes
`profil`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.11.2Nov 6, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations at all, the description carries the full burden and does substantial work: it discloses that output can be a path or base64, that the default temp directory persists so the returned path stays valid, and that the measurement report is always included. It does not cover what happens if `ziel` already exists (overwrite?), nor failure behavior on layout violations — the remaining gap keeps it at 4.

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?

Purpose is front-loaded in the first line, mode rules follow, then a compact parameter glossary. Some phrasing is expansive (the aside about a client not having a disk) and the two-mode logic is spread across the opening and the `form` entry, but nothing is genuinely waste.

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 no annotations and no output schema, the description still covers inputs, the two document modes, output location semantics, and the always-present measurement report. Missing only edge behavior — overwrite of an existing target, and what happens when the rendered letter fails the measurement rules.

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

Parameters5/5

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

Schema coverage is 0%, so the description must explain all five params, and it does: `brief` is explicitly the Markdown text itself and not a path (with the reason: the client holds it in context), `profil` accepts a name or a full object with a frontmatter fallback, `form` accepts A/B with a fallback chain, `als` gives the two output modes, and `ziel` defines the default. This is meaning fully beyond the bare schema types.

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?

"Setzt einen Brief und misst ihn nach — oder eine Urkunde" names a specific verb pair (set/measure) and resource, and immediately splits the tool into two modes keyed off `typ: urkunde` in the frontmatter. An agent can tell exactly what the tool produces 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?

It states the condition that selects the Urkunde mode (frontmatter `typ: urkunde`) and explicitly tells the agent not to pass `form` in that mode, which is real when/when-not guidance. It gives no routing relative to siblings such as `brief_pruefen` or `profile_auflisten`, so the alternative-selection layer is missing.

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

Deploy Server