Letter IRL

Change the postcard style

set_postcard_style

Idempotent

Change a previewed postcard's size or front layout without previewing it again. Give the draftId from the preview, and the size, the layout with its caption or place, or both. A size or layout left out stays as it is. A layout given replaces the front, so give its caption again to keep it. The postcard is drawn again and priced again: the 4x6 and 11x6 are paid per send with Pay & Send.

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": {
      "draftId": "<draftId>"
    },
    "name": "set_postcard_style"
  }
}

Input Schema

Name	Required	Description
`size`	No	The new size: 6x9, 6x4 for a 4 x 6 in postcard, or 6x11 for an 11 x 6 in one. Left out, the size stays. A 4x6 holds 11 lines on its back, a 6x9 or 11x6 16. A 4x6 or 11x6 is paid with Pay & Send, and a gift postcard stays a 6x9.
`place`	No	For the greetings layout only, and needed there: the place it greets from, such as "Asheville", printed in capitals.
`layout`	No	The new front: full_bleed, 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. Left out, the front stays as it is.
`caption`	No	For the border layout only: one handwritten line under the photo, such as "Cape Cod, August 2026". Leave it out for none.
`draftId`	Yes	The draftId from a postcard preview

Output Schema

Name	Required	Description
`size`	Yes	The postcard's size now: 6x9, 6x4 (a 4x6) or 6x11 (an 11x6)
`place`	No	The place the greeting names
`layout`	Yes	The postcard's front now
`caption`	No	The border's caption, when it has one
`draftId`	Yes
`message`	Yes
`canSendNow`	Yes	Whether the balance or a gift letter pays for the postcard as it is now: a new size can change how it is paid
`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
`sendEligibility`	Yes
`reasonCannotSend`	No
`contentVersionBefore`	No	The version of this mail the change was made to: for the preview card, which takes contentVersion only when this is the version it shows

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations declare the mutation, idempotency, and non-destructive profile, and the description adds concrete effects beyond that: omitted size or layout values persist, supplying a layout replaces the front and drops an existing caption unless regiven, the postcard is redrawn and repriced, and certain sizes are paid per send with Pay & Send. These are important behavioral details for correct use.

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?

The description is front-loaded with the action and key constraint, then compactly covers inputs, partial-update behavior, layout/caption interaction, and repricing. Every sentence contributes useful information with no filler.

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 mutation tool with an output schema and full schema coverage, the description covers prerequisites, optional updates, side effects, pricing, and payment implications. Nothing material is missing for correct invocation.

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 schema already carries most parameter meaning. The description adds one useful interaction not explicit in the schema: a new layout replaces the front, so an existing caption must be supplied again to keep it. Otherwise it largely restates omission behavior already documented 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 description opens with a specific verb and resource, 'Change a previewed postcard's size or front layout', and distinguishes the action from a fresh preview by saying 'without previewing it again'. This clearly separates it from sibling tools such as quote_and_preview_postcard.

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 establishes the required usage context: the postcard must already be previewed, and draftId must come from that preview. It does not explicitly name when to use quote_and_preview_postcard or send_postcard instead, so it is clear but lacks exclusions or alternatives.

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?