Skip to main content
Glama

PaperAgent — Send Physical Mail

Create a Letter Draft

create_draft

Create a draft of a physical letter to be printed on paper and mailed through USPS, and return its draft_id, page count and total price. A letter is at most 6 printed pages, at the same price whatever its length: up to 3 pages print one-sided, 4 to 6 print on both sides. Write the body to fit, or split a longer document into two letters, because a body that renders to 7 or more pages is refused rather than trimmed. This is NOT email, fax or text message — nothing reaches the recipient electronically, and the only way this letter arrives is on paper in an envelope. The body is plain text or Markdown. The draft freezes the content and the price for 24 hours and costs nothing; no paper is printed and no postage is bought until send_letter is called. US domestic addresses only. Call preview_draft next so the user can see the letter and the total.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesWho the letter is mailed to.
tierNoDefaults to standard. Call get_pricing first and pass a tier it lists: standard is a plain First-Class letter. certified, certified_err, proof_of_mailing and registered are other products the current price card may not sell, and a tier it does not sell is refused, not substituted — so do not describe one to the user until get_pricing has listed it.
colourNoOmit this. The current price card prints every letter black & white, so passing true is refused rather than billed — call get_pricing for what it does sell. The field remains because letters priced on an older card carry it.
body_fileNoA file the user attached, as the host delivers it. Not accepted yet — create_draft refuses an attachment and asks for the letter as body_markdown text.
body_markdownYesThe text of the letter, as plain text or Markdown. It must render to 6 printed pages or fewer — roughly 2,400 words of body text.
from_address_idNoOmit this. The account's own verified return address is used by default; only pass an id the account holder gave you.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteYesThe next call to make. Read it before answering the user.
tierYesThe product this draft is priced as, as passed to create_draft or update_draft.
quoteYesA priced letter. State total.display to the user before sending, and pass total.amount_cents as confirm_total_cents.
draft_idYesPass this to preview_draft, update_draft and send_letter.
expires_atYesISO 8601 instant the draft is deleted. Nothing is charged if it expires.
page_countYesPrinted pages, as counted by the renderer. Never more than 6 — a longer body is refused.
tier_titleYesWhat the price card in force calls that product, such as Standard. Use this name when you tell the user what they are buying.
sheet_countYesSheets of paper this letter is printed on: one page per sheet, one side each, up to 3 pages; a letter of 4 to 6 pages is printed on both sides, so it is never more than 3 sheets.
included_pagesYesPrinted pages the headline price covers. This draft is priced at that total up to this many pages.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well past the annotations: the 24-hour freeze, zero cost, no print/postage until send_letter, the 7+ page hard refusal (refused, not trimmed), and refusal-not-substitution for unsupported tiers and colour. These are exactly the side-effect and failure-mode facts an agent needs for a non-destructive-but-stateful create.

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 purpose, outputs, then constraints and next step, and nearly every sentence carries operational weight. The non-electronic point is made twice ("nothing reaches the recipient electronically" plus "the only way this letter arrives is on paper"), which is mild redundancy in an otherwise dense description.

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 6-parameter nested-object tool with an output schema, it covers required inputs, sizing limits, pricing rules, unsupported fields, address scope, and the follow-up call. An output schema exists, so return-value details are correctly left to it.

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 real meaning the schema lacks: page-count pricing behaviour, the one-sided vs duplex threshold, the ~2,400 word guidance, and the fact that body_file is currently rejected. Tier and colour semantics largely duplicate schema text, capping it below 5.

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?

Names a specific verb and resource (create a physical letter draft) and states its output artifacts (draft_id, page count, total price). It also explicitly distinguishes itself from send_letter and preview_draft, so an agent can route correctly without opening a schema.

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?

Gives explicit sequencing rules: call get_pricing before choosing a tier, call preview_draft next, split over-long documents into two letters, US domestic addresses only. It also states when-not (not email/fax/text) and which fields to omit (colour, from_address_id).

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