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. 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. 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. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only carry readOnlyHint=false, openWorldHint=false, destructiveHint=false, so the description bears the full burden. It discloses side effects (draft stored, preview PDF generated), output behavior (page count, 24h preview link, cost estimate, warnings), the content/blocks exclusivity rule, and the irreversible nature of a printed letter. This is substantial behavioral context beyond 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.

Conciseness4/5

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

The description is front-loaded with purpose and outputs, then moves into the mutually exclusive body format, an example, error-recovery guidance, and next steps. It is long and repeats every point in German and English, which costs conciseness, but for a 15-parameter tool with nested blocks and no output schema the level of detail is appropriate.

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?

For a complex tool with no output schema and minimal annotations, the description covers what the agent needs: return values, warnings, the draft lifecycle, the free-until-send rule, how to handle defects, and the follow-up tools by letterId. Paired with the schema's parameter descriptions, nothing essential is missing.

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%, so the schema does much of the work. The description adds real value by clarifying the mutually exclusive content vs blocks relationship, providing a concrete compact blocks example, and pointing to the full blocks reference resource. It does not need to re-explain every parameter given the schema's own descriptions.

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?

The first sentence states the specific action ('Legt einen Briefentwurf an' / 'Creates a letter draft') and the resource, and immediately distinguishes the tool from send/preview siblings by saying it stores a draft and returns a preview link and cost estimate. The description also names next-step tools (letter_preview, order_send, letter_schedule), reinforcing what this tool is not.

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?

The description gives clear context: create the draft, inspect the returned pages, fix defects by re-creating while it is still a draft, and only then send via order_send or schedule via letter_schedule. It names the alternatives as next steps but does not explicitly state 'use X instead of Y' or exclusions, hence 4 rather than 5.

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.

TDQS

B3.2/5.0
Disambiguation2/5

The surface contains multiple clusters whose boundaries are unclear: letterhead_list/letter_design_list/brand_kit_get/profile_get all expose similar letterhead/brand data, and letter_preview/template_preview/letter_design_preview are easy to confuse. The many *_app variants (approval_decide_app, template_decide_app, status/page-url helpers) further duplicate core actions. Rich descriptions help, but with 72 tools an agent will frequently pick the wrong member of a cluster.

Naming Consistency3/5

Most tools follow a readable snake_case resource_action pattern (address_upsert, approval_list, letter_schedule, wallet_balance). However, there are notable exceptions like analytics_summary, mcp_health, pricing_tiers, shipping_quote and order_einlieferungsbeleg, plus German/English mixing and semantically competing prefixes (letterhead_ vs letter_design_ vs brand_kit_). The style is not chaotic, but it is not uniformly consistent.

Tool Count1/5

With 72 tools this is an extreme mismatch for an MCP surface. The count is inflated by app-card-only helpers, separate preview variants and overlapping design/letterhead/brand tools that could be consolidated. Even a complex domain like postal letters does not justify this many top-level entry points.

Completeness4/5

The core domain is very well covered: addresses, letters, documents, templates, approvals, sender profiles, wallet, scheduling, archive exports and analytics all have lifecycle operations. The main gaps are minor workarounds rather than dead ends: no delete for addresses or documents, no attachment listing/deletion, and letter corrections are handled by creating a new draft.