Skip to main content
Glama
Sign In

Print and Mail Company

by com.printandmailcompany
OverviewDiscussionsAdmin

Compose a letter

compose_letter

Use this when the user wants to write a new paper letter from text and post it, for example to cancel a contract, subscription or membership by letter, file a complaint or objection, or send a formal notice, by ordinary or registered mail. Renders an A4 letter (DIN 5008 layout: sender block with the user's own name and address, recipient, place and date, subject, body, closing, signature) that passes the print check, and creates a draft with the exact price. Nothing is sent or charged: show the user the draft and the total, ask for confirmation, then call send_letter. The sender can live in any country. For the account's first letter the sender block must carry the user's REAL full name (first and last name, no alias, nickname or pseudonym) and postal address: it is then saved as the account's sender details; without valid ones the call fails with SENDER_DETAILS_REQUIRED. Once the account has sender details, the sender block is printed as given and the saved details stay as they are (sender_details: on_file when the block matches them, kept when it differs): the user changes them in Settings → Your details. Body supports paragraphs (blank line), '- ' bullets, '1. ' lists and bold. Needs the user's account.

Input Schema

NameRequiredDescriptionDefault
bodyYesLetter text including the salutation (e.g. 'Dear Sir or Madam,'), without closing or signature. Blank line = new paragraph; '- ' bullets, '1. ' numbered lists and **bold** work. Up to 20,000 characters.
dateNoDate of the letter as an ISO date (YYYY-MM-DD), e.g. 2026-10-08. Default: today.
colorNo"bw" = black and white, "color" = colour printing (costs more per page). Default "bw".bw
placeNoPlace printed before the date, usually the user's city, e.g. Berlin. Optional.
duplexNotrue = print on both sides of the paper (fewer sheets, so a lighter letter); false = one side only. Default false.
senderYesThe user's own name and address (any country), printed in the letter's sender block (the envelope always shows our return address). Use the user's REAL full name, not an alias, nickname or pseudonym: for an account without sender details yet, this block is checked and saved as them; once the account has them, they stay as they are.
closingNoClosing phrase, e.g. 'Kind regards'. Default: the usual closing in the letter's language.
subjectYesSubject line printed above the body, e.g. Cancellation of my contract no. 12345 (up to 200 characters).
envelopeNo"DL" (220×110 mm, letter folded twice), "C5" (229×162 mm, folded once) or "C4" (324×229 mm, flat). Omit to use the smallest envelope that holds the sheets (recommended); one too small for the page count is refused.
languageNoLanguage of the letter as an ISO 639-1 code, e.g. en, de, fr, es, pt, it or nl; sets the date format and the default closing. Default "en".en
recipientYesRecipient's postal address, printed in the letter's address field and on the envelope. Ask the user for missing fields.
signatureNoName printed under the closing, e.g. Max Mustermann. Default: the sender's name.
referencesNoUp to 5 reference lines printed above the subject, e.g. ["Customer no. 12345", "Contract no. 987"]. Optional.
registeredNotrue = registered mail: tracking number and signature on delivery, for an extra fee (also what "certified" letters, Einschreiben, lettre recommandée and carta certificada mean here; not a US certified-mail product). false = ordinary mail. Default false. Often wanted for cancellations and deadlines.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / sender / description
      Previous value: -"The user's own name and address (any country), printed in the letter's sender block (the envelope always shows our return address)"New value: +"The user's own name and address (any country), printed in the letter's sender block (the envelope always shows our return address). Use the user's REAL full name, not an alias, nickname or pseudonym: for an account without sender details yet, this block is checked and saved as them; once the account has them, they stay as they are."
    • changedInput schema / properties / sender / properties / name / description
      Previous value: -"The user's full name, e.g. Max Mustermann."New value: +"The user's full name: their REAL first and last name, not an alias, nickname or pseudonym, e.g. Anna Schmidt."
    • changedInput schema / properties / sender / properties / region / description
      Previous value: -"State, province or region where the user's country has one in addresses, e.g. CA (California, US), ON (Ontario, CA) or Madrid (ES). Optional in the sender block."New value: +"State, province or region where the user's country has one in addresses, e.g. CA (California, US), ON (Ontario, CA) or Madrid (ES). Required for addresses in AE, AS, AU, BR, CA, CN, CO, CR, ES, FM, HK, HN, ID, IN, IQ, IT, JM, JP, KN, KR, KY, MH, MP, MX, NR, PF, PG, PW, RU, SO, SV, TW, US, VE, VI, VN when this block is saved as the user's sender details (an account without them yet: SENDER_DETAILS_REQUIRED, fields.region); otherwise optional."
  2. Changed31 schema fields changed
    • changedInput schema / properties / body / description
      Previous value: -"Letter text including the salutation (e.g. 'Dear Sir or Madam,'), without closing or signature"New value: +"Letter text including the salutation (e.g. 'Dear Sir or Madam,'), without closing or signature. Blank line = new paragraph; '- ' bullets, '1. ' numbered lists and **bold** work. Up to 20,000 characters."
    • changedInput schema / properties / closing / description
      Previous value: -"e.g. 'Kind regards' (default by language)"New value: +"Closing phrase, e.g. 'Kind regards'. Default: the usual closing in the letter's language."
    • addedInput schema / properties / color / description
      Added value: +"\"bw\" = black and white, \"color\" = colour printing (costs more per page). Default \"bw\"."
    • changedInput schema / properties / date / description
      Previous value: -"ISO date; defaults to today"New value: +"Date of the letter as an ISO date (YYYY-MM-DD), e.g. 2026-10-08. Default: today."
    • addedInput schema / properties / duplex / description
      Added value: +"true = print on both sides of the paper (fewer sheets, so a lighter letter); false = one side only. Default false."
    • addedInput schema / properties / envelope / description
      Added value: +"\"DL\" (220×110 mm, letter folded twice), \"C5\" (229×162 mm, folded once) or \"C4\" (324×229 mm, flat). Omit to use the smallest envelope that holds the sheets (recommended); one too small for the page count is refused."
    • changedInput schema / properties / language / description
      Previous value: -"Language of the letter, e.g. en, de, fr — sets date format and default closing"New value: +"Language of the letter as an ISO 639-1 code, e.g. en, de, fr, es, pt, it or nl; sets the date format and the default closing. Default \"en\"."
    • changedInput schema / properties / place / description
      Previous value: -"Place shown next to the date, e.g. the sender's city"New value: +"Place printed before the date, usually the user's city, e.g. Berlin. Optional."
    • addedInput schema / properties / recipient / description
      Added value: +"Recipient's postal address, printed in the letter's address field and on the envelope. Ask the user for missing fields."
    • addedInput schema / properties / recipient / properties / city / description
      Added value: +"City or town, e.g. Berlin."
    • changedInput schema / properties / recipient / properties / company / description
      Previous value: -"Company or organisation (optional)"New value: +"Recipient's company or organisation, e.g. Example GmbH. Optional."
    • changedInput schema / properties / recipient / properties / country / description
      Previous value: -"ISO 3166-1 alpha-2 country code, e.g. DE, FR, US"New value: +"Country as an ISO 3166-1 alpha-2 code, e.g. DE, FR or US."
    • changedInput schema / properties / recipient / properties / line1 / description
      Previous value: -"Street and house number, or PO box"New value: +"Street and house number, or PO box, e.g. Hauptstraße 5."
    • changedInput schema / properties / recipient / properties / line2 / description
      Previous value: -"Additional line: c/o, apartment, building"New value: +"Optional extra address line: c/o, apartment, floor or building, e.g. Apt 4B."
    • changedInput schema / properties / recipient / properties / name / description
      Previous value: -"Recipient (person) name"New value: +"Recipient's name: a person, or a department such as Customer Service when writing to a company, e.g. Erika Mustermann."
    • changedInput schema / properties / recipient / properties / postal_code / description
      Previous value: -"Postcode / ZIP (required in most countries)"New value: +"Postcode / ZIP code, e.g. 10115 or 94105. Required in countries that use postcodes."
    • changedInput schema / properties / recipient / properties / region / description
      Previous value: -"State / province where the country uses it (e.g. US state code CA)"New value: +"State, province or region. Required for recipients in AE, AS, AU, BR, CA, CN, CO, CR, ES, FM, HK, HN, ID, IN, IQ, IT, JM, JP, KN, KR, KY, MH, MP, MX, NR, PF, PG, PW, RU, SO, SV, TW, US, VE, VI, VN (without it the draft is refused: INVALID_ADDRESS, fields.region); omit where addresses have none, e.g. DE, FR or GB. The code in US, CA, AU and BR, e.g. CA (California) or ON (Ontario); elsewhere the name or its usual abbreviation, e.g. Madrid (ES) or RM (Rome, IT)."
    • changedInput schema / properties / references / description
      Previous value: -"Lines like 'Customer no. 12345'"New value: +"Up to 5 reference lines printed above the subject, e.g. [\"Customer no. 12345\", \"Contract no. 987\"]. Optional."
    • changedInput schema / properties / registered / description
      Previous value: -"Registered mail (tracking + signature on delivery), e.g. for cancellations and deadlines"New value: +"true = registered mail: tracking number and signature on delivery, for an extra fee (also what \"certified\" letters, Einschreiben, lettre recommandée and carta certificada mean here; not a US certified-mail product). false = ordinary mail. Default false. Often wanted for cancellations and deadlines."
    • addedInput schema / properties / sender / properties / city / description
      Added value: +"City or town, e.g. Berlin."
    • changedInput schema / properties / sender / properties / company / description
      Previous value: -"Company or organisation (optional)"New value: +"The user's company or organisation, e.g. Example GmbH. Optional."
    • changedInput schema / properties / sender / properties / country / description
      Previous value: -"ISO 3166-1 alpha-2 country code, e.g. DE, FR, US"New value: +"Country as an ISO 3166-1 alpha-2 code, e.g. DE, FR or US."
    • addedInput schema / properties / sender / properties / email / description
      Added value: +"The user's email address, printed in the sender block, e.g. max@example.com. Optional."
    • changedInput schema / properties / sender / properties / line1 / description
      Previous value: -"Street and house number, or PO box"New value: +"Street and house number, or PO box, e.g. Hauptstraße 5."
    • changedInput schema / properties / sender / properties / line2 / description
      Previous value: -"Additional line: c/o, apartment, building"New value: +"Optional extra address line: c/o, apartment, floor or building, e.g. Apt 4B."
    • changedInput schema / properties / sender / properties / name / description
      Previous value: -"Recipient (person) name"New value: +"The user's full name, e.g. Max Mustermann."
    • addedInput schema / properties / sender / properties / phone / description
      Added value: +"The user's phone number, printed in the sender block, e.g. +49 30 1234567. Optional."
    • changedInput schema / properties / sender / properties / postal_code / description
      Previous value: -"Postcode / ZIP (required in most countries)"New value: +"Postcode / ZIP code, e.g. 10115 or 94105. Required in countries that use postcodes."
    • changedInput schema / properties / sender / properties / region / description
      Previous value: -"State / province where the country uses it (e.g. US state code CA)"New value: +"State, province or region where the user's country has one in addresses, e.g. CA (California, US), ON (Ontario, CA) or Madrid (ES). Optional in the sender block."
    • changedInput schema / properties / signature / description
      Previous value: -"Name under the closing; defaults to the sender name"New value: +"Name printed under the closing, e.g. Max Mustermann. Default: the sender's name."
    • addedInput schema / properties / subject / description
      Added value: +"Subject line printed above the body, e.g. Cancellation of my contract no. 12345 (up to 200 characters)."
  3. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations, it discloses that nothing is sent or charged, that a draft is created with an exact price, the SENDER_DETAILS_REQUIRED failure mode, and how sender details are saved or preserved on the account. It also covers body markup, print-check behavior, and that the sender can be in any country.

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?

It is front-loaded with the when-to-use and the draft-then-send workflow before the caveats. It is dense but justified for a 14-parameter tool, though the real-name requirement and body-formatting details are partially repeated in the schema, costing some conciseness.

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 nested 14-parameter mutation with no output schema, the description covers the workflow, pricing, confirmation requirement, error modes, sender-details persistence, and formatting rules. An agent has enough to invoke it correctly without guessing.

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 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: the body formatting rules, the sender-block-as-account-details semantics, and which fields cause SENDER_DETAILS_REQUIRED. It does repeat some schema details rather than only adding new meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource (compose a new paper letter from text, render an A4 DIN 5008 letter, create a draft) and lists concrete use cases like cancellations and formal notices. It clearly separates composing from sending by naming send_letter, but never addresses the sibling create_letter, which an agent could easily confuse with this tool.

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 when to use the tool with concrete scenarios, spells out the required follow-up workflow (show draft and total, ask for confirmation, call send_letter), and explains the first-letter sender-details prerequisite. The missing piece is guidance on how this differs from the create_letter sibling.

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

All Print and Mail Company toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources