Skip to main content
Glama
bitterdev

pdf-letter-mcp

by bitterdev

Preview letter layout

preview_letter

Renders a letter in memory to verify layout before printing, returning metrics and warnings that show whether the address fits the field or the letter spills onto a second page.

Instructions

Renders the letter in memory and returns layout metrics and warnings without writing a file. Use it to check whether the address fits the address field or the letter runs onto a second page.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYesLetter text. Blank lines separate paragraphs, "- " starts a bullet list, "1. " a numbered list, **bold** and *italic* are supported, "\pagebreak" forces a page break.
dateNoISO date (2026-07-24), "today" or free text. Default "today".
marksNoRemark zone above the address, max. 3 lines, e.g. ["Einschreiben"].
placeNoPlace for the "place, date" line.
copyToNo
localeNoLanguage of the fixed texts and date format. Supported: de, en, fr, es, it, nl, pt, pl, tr, da, sv, cs. Regional tags such as "en-US" are accepted. Default "de".
senderNoSender, printed as the small return address line above the recipient. Only needed when no profile is used, a profile always wins.
closingNoDefault is the closing phrase of the locale.
profileNoSender identity, taken from the profile file on this machine (see list_profiles). The profile provides address, return address line and signature image. Use this instead of typing a sender.
subjectNoSubject line, printed without a "Betreff:" label as required by DIN 5008.
metadataNo
dateStyleNoDefault "numeric" (24.07.2026).
recipientYesRecipient, positioned in the DIN 5008 address field so it shows in the envelope window.
signatureNoSignature below the closing line. The image is scaled and placed by the renderer: it is laid over the blank line above the printed name and deliberately overlaps the closing line, exactly like a signature on paper. That overlap is intended and must not be compensated for.
enclosuresNo
salutationNoDefault is the generic salutation of the locale.
subjectLinesNoFurther bold lines right below the subject. This is where a normal German letter carries references, e.g. ["Zeichen: 535 B 335D028418", "Kunden-Nummer: 335D028418"].
countryDisplayNoWhen to print the country line, default "auto" (only for foreign recipients).
returnAddressLineNoReturn address line above the recipient. Generated from the sender, pass "" to hide it.
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: in-memory rendering, no file written, returns layout metrics and warnings (fits address field, second-page detection). However, it doesn't describe return format, pagination behavior details, or what specific warnings/layout metrics are returned beyond the two examples.

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, zero waste. The first states what it does, the second states when to use it. Front-loaded and efficient.

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?

Given the large 19-param schema with 84% coverage and nested objects, the description is reasonably complete for a preview/validation tool. No output schema exists, but the description at least signals the nature of returns (layout metrics, warnings). Could add the exact set of warnings/metrics, but the tool's purpose as a dry-run check is well covered.

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 84%, so the schema documents most parameters adequately. The description adds modest value referencing 'address field' and 'second page' as the metrics it checks. It doesn't re-explain individual parameters, which is appropriate given high schema coverage. Does not compensate for the ~16% undocumented scope, but baseline 3-4 is warranted.

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 description uses a specific verb+resource ('Renders the letter in memory and returns layout metrics and warnings') and clearly distinguishes from siblings by stating it operates 'without writing a file.' It contrasts with create_letter among siblings, making its purpose unambiguous.

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?

The description explicitly states when to use it: 'Use it to check whether the address fits the address field or the letter runs onto a second page.' This gives concrete scenarios and implies it's a validation step before create_letter, though it doesn't name the alternative tool explicitly.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bitterdev/pdf-letter-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server