Skip to main content
Glama

Preview a letter

quote_and_preview_letter

Preview a text-only physical letter draft. Requires a real U.S. recipient mailing address and text that fits the text-only letter limit. Its answer says what sending it takes and when the mail usually arrives. A letter too long for one page runs on to a second or third page, printed on both sides and paid with Pay & Send; three pages is the longest. Only when the person asks for USPS Certified Mail (it costs more), pass mailService "certified"; "certified_return_receipt" adds an electronic return receipt. Certified mail is paid with Pay & Send, never a letter pack or a gift letter, and a new preview of a certified letter must pass mailService again. The person sends it on the page request_send links to: call request_send and give the person its link.

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": {
      "recipient": "<recipient>",
      "bodyText": "<bodyText>",
      "signOff": "<signOff>"
    },
    "name": "quote_and_preview_letter"
  }
}

Input Schema

NameRequiredDescriptionDefault
senderNo
signOffYes
arriveByNoOptional. The date the mail should arrive by, YYYY-MM-DD, such as a birthday or an event. Letter IRL holds the mail and sends it to the printer in time; USPS does not guarantee First-Class dates. Omit it to mail as soon as possible.
bodyTextYes
headlineNoOptional, for the celebration stationery only: a short line printed large above the letter, such as "Happy Birthday, Sam!". It must fit on one line, and takes three of the page's lines; leave it out for confetti alone.
monogramNoOptional, for the monogram stationery only: the initials to print, one to three letters, such as "JMS". Leave it out to use the initials of the return address's name.
recipientYes
signatureNoOptional. Whether the letter prints the person's saved signature under the sign-off's first line (set_signature saves one). Left out, the person's last choice: on once a signature is saved. True with none saved is refused. Pass false to leave it off.
sendAsGiftNoSet true only when the user asks to send this as their gift letter: it is free and adds a printed page with a card for the recipient. Leave it out otherwise; a gift letter is then used only if the balance cannot pay.
stationeryNoOptional. The letter's stationery: classic, a plain page; monogram, initials in a ring; botanical, a line-drawn sprig; celebration, confetti with an optional headline; typewriter, the letter typed in a monospace face, which fits fewer words on the page; or handwritten, the letter in a handwriting face on faint ruled lines, which has no Greek, Hebrew or Vietnamese. Each but classic prints the date at the top right. Left out, the letter is in the account's last choice, or classic if it has none. Leave it out unless the user asks for a style or for a plain page (classic), or names an occasion a style suits.
mailServiceNoOptional. How the letter travels: standard (the default), certified (USPS Certified Mail, which gives a tracking number), or certified_return_receipt (Certified Mail with an electronic return receipt). Certified mail costs more and is paid with Pay & Send: no letter pack and no gift letter pays for it. Leave it out for an ordinary letter.

Output Schema

NameRequiredDescriptionDefault
pagesNoPresent only for a letter of more than one page: the pages it prints on, both sides of the paper. No letter pack or gift letter pays for it; it is paid with Pay & Send.
draftIdYes
giftCardNo
scheduleNo
signatureNoWhile signatures are offered: whether the letter prints the person's saved signature, and why
canSendNowYes
layoutTypeYes
stationeryNoWhile stationery is offered: the stationery the page was drawn in, with the date line, initials and headline it prints, and why: asked for, the account's last choice, or classic by default
mailServiceNoPresent only when the letter goes as certified mail: certified, or certified_return_receipt (with an electronic return receipt). Paid with Pay & Send.
wordsVersionNoWhile a letter's words can be changed in place: the version of the letter's words, which set_letter_words takes to say which words it replaces
arrivalWindowNoThe arrival dates that can be chosen now: what can be scheduled, not when this mail arrives
deliveryClassNo
contentVersionNoThe version of this mail as it is now: send it with the send, so what is mailed is what the person saw
draftExpiresAtYes
addressWarningsNo
lettersRequiredYes
sendEligibilityYes
deliveryEstimateNo
reasonCannotSendNo
deliveryDisclaimerNo
giftLettersAvailableNo
estimatedDeliveryDaysNo
savedReturnAddressNoteNo
usedSavedReturnAddressNo
senderAddressValidationNo
recipientAddressValidationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior3/5

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

With annotations supplied, the bar is lower, and the description does add real behavior: page limits (three pages max, printed both sides), payment method constraints for certified mail, and the quirk that a new preview of a certified letter must re-pass mailService. However, it never states plainly that the preview itself charges nothing or sends nothing, which matters given readOnlyHint=false, and it is silent on whether the preview persists account preferences.

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?

Every sentence carries useful policy content, but they are packed into a single dense paragraph with abrupt topic shifts (page count, then certified mail, then return receipt, then the send handoff). The closing sentence about the request_send page is awkwardly worded and harder to parse than it needs to be.

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?

For an 11-parameter preview tool with an output schema and annotations, the description covers the decision points an agent needs: page limits, mail service rules, gift letter and stationery defaults, and the handoff to request_send. Minor omissions remain around sender/signOff (schema-documented) and whether the preview has side effects.

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

Parameters3/5

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

Schema coverage sits at 64% with rich inline descriptions for arriveBy, headline, monogram, signature, sendAsGift, stationery and mailService, so the schema carries most of the load. The description adds genuine meaning only for bodyText (the text-only length limit and page overflow) and for the conditional mailService rules. Nothing is added for sender, recipient, signOff, or headline beyond what the schema already says.

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 opens with a specific verb and resource: 'Preview a text-only physical letter draft.' The 'text-only' qualifier implicitly distinguishes it from the with_image and with_header_image siblings, but it never names those siblings, so the agent must infer the routing. Purpose is clear; sibling differentiation is only implied.

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?

Explicit when-to-use conditions are given for the key decisions: certified mail only 'when the person asks for USPS Certified Mail,' gift letter only when the user requests it, stationery left at the account default unless a style is asked for. It also routes the agent away from this tool for the final send by naming request_send and its link.

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.

Resources