Letter IRL

Preview a postcard

quote_and_preview_postcard

Create a preview of a physical postcard draft with a front image and back message. Use this when the user wants to make, create, design, or preview a postcard through Letter IRL. Requires a real U.S. recipient mailing address. Its answer says what sending it takes and when the mail usually arrives. If the user refers to an image already generated, shown, or attached earlier in this conversation, call this tool first to reuse that image. Otherwise prefer a direct file attachment for the image, pass imageUrl when a generated or hosted image is already available, and use upload_image only if no attachment or usable imageUrl made it through after a direct preview attempt. If sender is omitted, the saved return address is used automatically. 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>",
      "message": "<message>"
    },
    "name": "quote_and_preview_postcard"
  }
}

Input Schema

Name	Required	Description
`size`	No	The postcard's size: 6x9 (the default), 6x4 for a 4 x 6 in postcard, or 6x11 for an 11 x 6 in one. A 4x6 holds 11 lines on its back, about 350 characters of prose; an 11x6 16 lines, about 900. Letter packs and gift letters pay only for a 6x9: a 4x6 or 11x6 is paid with Pay & Send.
`image`	No
`place`	No	For the greetings layout only, and needed there: the place it greets from, such as "Asheville", printed in capitals.
`images`	No	For a collage front: two to four photos attached in the conversation, in the order they should appear. The arrangement follows the count: two side by side; three, one large with two beside it; four, two by two. Give images or imageUrls, never together with image or imageUrl. Leave it out for a single photo.
`layout`	No	The front's layout: full_bleed (the default), the photo across the whole front; border, the photo in a white border with a caption under it; or greetings, "Greetings from" a place over the photo.
`sender`	No
`caption`	No	For the border layout only: one handwritten line under the photo, such as "Cape Cod, August 2026". Leave it out for none.
`message`	Yes	Must fit the back of the postcard, which is measured in lines: 16 on a 6x9, about 500 characters of prose. size gives the other sizes' room.
`arriveBy`	No	Optional. 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.
`imageUrl`	No
`imageUrls`	No	For a collage front: two to four links to photos, in the order they should appear, each a public image link or an imageUrl from confirm_uploaded_image. The arrangement follows the count: two side by side; three, one large with two beside it; four, two by two. Give imageUrls or images, never together with image or imageUrl. Leave it out for a single photo.
`recipient`	Yes
`sendAsGift`	No	Set 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.

Output Schema

Name	Required	Description
`size`	No	While the 4x6 and 11x6 are offered: the postcard's size
`place`	No	The place the greeting names
`layout`	No	While postcard layouts are offered: the front's layout
`caption`	No	The border's caption, when it has one
`draftId`	Yes
`message`	No
`giftCard`	No
`schedule`	No
`canSendNow`	Yes
`senderCity`	No
`senderName`	No
`senderState`	No
`arrivalWindow`	No	The arrival dates that can be chosen now: what can be scheduled, not when this mail arrives
`collagePhotos`	No	How many photos the front draws, when it is a collage
`deliveryClass`	No
`recipientCity`	No
`recipientName`	No
`contentVersion`	No	The version of this mail as it is now: send it with the send, so what is mailed is what the person saw
`draftExpiresAt`	Yes
`recipientState`	No
`addressWarnings`	No
`lettersRequired`	Yes
`sendEligibility`	Yes
`deliveryEstimate`	No
`reasonCannotSend`	No
`senderPostalCode`	No
`deliveryDisclaimer`	No
`senderAddressLine1`	No
`senderAddressLine2`	No
`recipientPostalCode`	No
`giftLettersAvailable`	No
`estimatedDeliveryDays`	No
`recipientAddressLine1`	No
`recipientAddressLine2`	No
`savedReturnAddressNote`	No
`usedSavedReturnAddress`	No
`senderAddressValidation`	No
`recipientAddressValidation`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Beyond the annotations (which only say non-readonly, non-destructive, open-world, non-idempotent), the description discloses that a real U.S. recipient address is required, that the saved return address fills in a missing sender, that the answer reports cost and typical delivery timing, and that sending happens later via request_send. It does not spell out side effects of creating the draft or whether drafts expire, which the annotations leave open.

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?

Front-loaded with the purpose, then prerequisites, then the image fallback chain, then the sender default and the final send-step handoff. It is dense and the fallback sentence runs long, and noting what the answer reports is partly redundant with the output schema, but almost every sentence carries actionable information.

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 13-parameter, nested-object tool this describes everything an agent needs before calling: preconditions, image sourcing decision path, sender default, and the exact follow-up action (request_send plus its link). Return values are covered by the existing output schema, so the description need not restate them.

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 69% and the schema already documents size, layout, caption, message, arriveBy, images, and sendAsGift thoroughly. The description adds meaning the schema does not: how to choose between image/imageUrl/images (with the mutual-exclusion rule implied by examples), the image-reuse rule, and the sender default. The recipient object's required shape and the identifier semantics for file_id/download_url are still only in the schema.

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 gives a precise verb and resource: 'Create a preview of a physical postcard draft with a front image and back message.' The follow-up adds scope ('make, create, design, or preview a postcard through Letter IRL') and clarifies that this tool does not itself send the card, which separates it from send_postcard without naming it.

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 ('user wants to make, create, design, or preview a postcard') plus an ordered fallback chain for the image: reuse an earlier generated image, else direct attachment, else imageUrl, else upload_image only after a failed direct attempt. That is a rarity: named alternatives with conditions selecting each.

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

All Letter IRL tools Inspect

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

Need Help?