Skip to main content
Glama

Briefentwurf anlegen

letter_create_draft

Legt einen Briefentwurf an: erstellt eine Vorschau-PDF im hinterlegten Briefdesign (nur der Brieftext), speichert den Entwurf und liefert eine Seitenzahl, einen Vorschau-Link (24 Stunden gültig) und eine unverbindliche Kostenvorschau. Der Entwurf bleibt kostenfrei liegen, bis du ihn versendest. Der Brieftext ist entweder content (Fliesstext) ODER blocks (strukturiert: Tabellen, Ueberschriften, Summenzeilen), genau eines von beiden. Kompaktes blocks-Beispiel: {"blocks":[{"type":"heading","text":"Rechnung"},{"type":"table","columns":[{"key":"text","label":"Artikel","width":"grow"},{"key":"sum","label":"Summe","align":"right","format":"eur"}],"rows":[{"text":"Beratung","sum":32000}]},{"type":"totals","lines":[{"label":"Gesamt","amountCents":32000,"emphasis":true}]}]} Volle Referenz inkl. styleDefs und Limits: MCP-Ressource frankki://blocks-guide. Die ersten Seiten kommen als Bild zurück: sieh sie dir an, bevor du versendest, und prüfe Betreff, Anschrift im Adressfenster, Absender, Datum und Umbrüche. Die eingebettete Karte ist die Vorschau für den Menschen. Nach ihrer Anzeige reicht im Chat eine kurze Bestätigung; PDF-Link und Brieftext gehören in reine Textansichten. Gemeldete Auffälligkeiten stehen in warnings. Findest du einen Fehler, korrigiere ihn und lege den Entwurf neu an, solange er noch Entwurf ist: gedruckt geht der Brief endgültig raus. Nächster Schritt mit der zurückgegebenen letterId: letter_preview zeigt den Entwurf als Bild zum Nachbessern, order_send versendet ihn, letter_schedule versendet ihn zu einem späteren Zeitpunkt. EN: Creates a letter draft: produces a preview PDF in the stored letter design (letter body only), stores the draft and returns a page count, a preview link (valid for 24 hours) and a non-binding cost estimate. The draft stays free of charge until you send it. The body is either content (plain text) OR blocks (structured: tables, headings, totals lines), exactly one of the two. Compact blocks example: {"blocks":[{"type":"heading","text":"Rechnung"},{"type":"table","columns":[{"key":"text","label":"Artikel","width":"grow"},{"key":"sum","label":"Summe","align":"right","format":"eur"}],"rows":[{"text":"Beratung","sum":32000}]},{"type":"totals","lines":[{"label":"Gesamt","amountCents":32000,"emphasis":true}]}]} Full reference incl. styleDefs and limits: MCP resource frankki://blocks-guide. The first pages come back as images: look at them before sending and check the subject, the address inside the address window, sender, date and line breaks. The embedded card is the human preview. Once it appears, a short chat confirmation is enough; PDF links and letter text belong in text-only views. Reported findings are in warnings. If you find a defect, fix it and create the draft again while it is still a draft: once printed, the letter is out for good. Next step with the returned letterId: letter_preview shows the draft as an image to refine it, order_send sends the draft, letter_schedule sends it at a later time.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
blocksNoStrukturierter Briefinhalt als typisierte Bloecke (Alternative zu content, nie beides). Limits: 200 Bloecke, 100 Zeilen/Tabelle, 20 Spalten, 2000 Zeichen/Zelle, 10 Bilder, 262144 Bytes. EN: structured letter content as typed blocks (alternative to content, never both). Jeder Block braucht type; erlaubte Typen: paragraph, heading, keyValue, checkboxRow, fillLine, table, totals, columns, box, image, spacer, pageBreak. Die vollstaendige Feldreferenz liegt in der MCP-Ressource frankki://blocks-guide. EN: every block needs type; read frankki://blocks-guide for the complete field reference.
contentNoBrieftext als Fliesstext. Entweder content ODER blocks, nie beides. EN: letter body as plain text. Either content OR blocks, never both.
subjectYes
designIdNoEin gespeichertes Briefdesign fuer diesen Brief verwenden. Es wird bereits in der Vorschau-PDF gerendert und am Entwurf gespeichert, sodass ein spaeterer Versand ueber die letterId es uebernimmt (ausser der Versand nennt selbst ein Design). Ohne Angabe gilt das Standard-Design des Absenderprofils, in der Vorschau wie beim Versand. EN: Use a saved letter design for this letter. It is already rendered into the preview PDF and stored on the draft so a later send by letterId inherits it (unless the send names its own design). If omitted, the sender profile default design applies, in the preview as well as on send.
languageNoStandard de. EN: Defaults to de.
reasoningNo
referenceNoWerte fuer diesen Brief (Vorgangsnummer, Ihr Zeichen, Kundennummer, QR-Parameter ...). Sie fuellen den Infoblock und den Barcode. EN: Per-letter values (Vorgangsnummer, your reference, customer number, QR parameters ...). They fill the info block and the barcode.
styleDefsNoBenannte Stile fuer das ganze Dokument (max. 24). Bloecke referenzieren sie ueber style. EN: named document styles (max 24); blocks reference them via style. Vollstaendige Stilfelder: frankki://blocks-guide. EN: complete style fields: frankki://blocks-guide.
presetNameNo
signatureIdNoEine bestimmte gespeicherte Unterschrift verwenden statt der zuerst hinterlegten. EN: Use a specific stored signature instead of the first one on file.
clientLetterIdNoIdempotenzschluessel. Ein erneuter Aufruf mit demselben Wert UND derselben Nutzlast liefert denselben Entwurf, statt einen zweiten anzulegen. Fuer einen anderen Brief brauchst du einen neuen Schluessel: derselbe Schluessel mit anderem Inhalt wird mit IDEMPOTENCY_CONFLICT abgelehnt, damit du keinen Brief fuer angelegt haeltst, den es nicht gibt. EN: Idempotency key. A repeat call with the same value AND the same payload returns the same draft instead of creating a second one. A different letter needs a new key: the same key with different content is refused with IDEMPOTENCY_CONFLICT, so you never believe a letter exists that does not.
senderAddressIdNo
senderProfileIdNoAbsenderprofil, mit dem spaeter versendet wird. Fuer die Vorschau zaehlt daraus nur das Standard-Briefdesign. EN: Sender profile the letter will later be sent with. For the preview only its default letter design is used.
includeSignatureNoHinterlegte Unterschrift unter den Brieftext setzen. Standard aus, wie beim Versand. EN: Place the stored signature under the letter text. Off by default, same as on send.
recipientAddressInlineNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say readOnly=false, destructive=false, openWorld=false; the description goes well beyond them, disclosing that the draft is free until sent, that the preview link lives 24 hours, that printing makes the letter irrevocable, that findings surface in warnings, and how idempotency behaves (IDEMPOTENCY_CONFLICT). No contradiction with the annotations.

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

Conciseness3/5

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

Purpose is front-loaded and every section has a job, but the entire text is duplicated in German and English, roughly doubling the length with no added information, and the long blocks JSON example plus workflow commentary push it well past what an agent needs in a tool description rather than a resource.

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 15 parameters, nested block objects and no output schema, the description carries the full load of describing return values (page count, preview link, cost estimate, warnings, rendered images, embedded human-preview card) and the downstream workflow. Nothing material is left for the agent to infer.

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 67% and the schema already documents several params well, but the description still adds real value: the content-vs-blocks exclusivity rule, a worked blocks example, and a pointer to frankki://blocks-guide for styleDefs and limits. It does not attempt to explain the remaining bare params (reasoning, presetName, senderAddressId), which keeps it just short of 5.

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 precise verb+resource ('Legt einen Briefentwurf an') and enumerates the concrete outputs (preview PDF, stored draft, page count, 24h link, cost estimate). It also names the siblings that continue the workflow (letter_preview, order_send, letter_schedule), so an agent can separate this from them without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Explicitly states the content-XOR-blocks rule, tells the agent to inspect the returned page images before sending, to recreate the draft while it is still a draft, and routes to the correct sibling for each next step via the returned letterId. When-to-use and when-not-to-reuse conditions are both covered.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.