--- title: Making physical mail callable from AI agents description: AI agents can safely help with physical mail when the product separates preparation from commitment. The safest default is to let the agent create a draft, generate a PDF preview, validate the address, show the price, and hand the final payment decision back to a human. Direct machine payment through MPP or x402 should be reserved for runtimes with explicit owner approval, spend limits, and idempotent retry handling. seotitle: Physical Mail for AI Agents | MCP, x402, and Human Review seo-description: How AI agents can prepare real postal mail safely with MCP drafts, PDF previews, hosted checkout, and machine-payment guardrails. group: resources indexable: true nav: false schema: article og-image: /og/developers.png og-image-alt: PostalForm developer documentation for AI-agent mail workflows. eyebrow: Agentic mail published: 2026-05-31 updated: 2026-05-31 path: /making-physical-mail-callable-from-ai-agents --- # Making physical mail callable from AI agents AI agents can safely help with physical mail when the product separates preparation from commitment. The safest default is to let the agent create a draft, generate a PDF preview, validate the address, show the price, and hand the final payment decision back to a human. Direct machine payment through MPP or x402 should be reserved for runtimes with explicit owner approval, spend limits, and idempotent retry handling. ## Quick answer: how should agents send physical mail? | Agent action | Product state | Real-world side effect? | Recommended default | | ------------------------------ | ------------------- | ----------------------------------------------- | ---------------------------------------------------------- | | Draft a letter or attach a PDF | Unpaid draft | No printing or mailing | Safe for chat clients after document-sharing approval | | Generate a PDF preview | Reviewable document | No printing or mailing | Show to the owner before payment | | Create hosted checkout | Payment page ready | No printing or mailing until checkout completes | Best default for user-facing assistants | | Complete checkout with a human | Paid order | Yes, after payment and provider processing | Use when the user reviews address, PDF, price, and options | | Pay with MPP or x402 | Paid machine order | Yes, after payment challenge is answered | Use only with explicit owner approval and a spend limit | ## Why physical mail is different from ordinary tool calls Many software tools can be undone or edited after the fact. Physical mail is different. Once a mailpiece is paid, printed, enveloped, posted, and handed to a carrier or mailing provider, the workflow has crossed into a real-world operations layer. That changes the agent design: 1. The agent needs a non-destructive preparation phase. 2. The user needs to inspect the actual output, not just the agent's summary. 3. Payment should be a separate approval boundary. 4. Status lookup matters after the order is created. 5. Public machine-readable docs need to say which tools create drafts and which tools can create paid orders. This is why PostalForm treats hosted checkout as the safest default for chat-style agents. The agent can do the useful setup work, but the user still reviews the PDF, addresses, mailing options, and price before payment. ## The safe architecture: draft, preview, approve, send The core pattern is a four-step state machine. 1. **Draft** - The agent prepares the letter, PDF, form payload, or bulk campaign data and creates an unpaid draft. 2. **Preview** - The system renders a print-ready PDF or other reviewable output when available. 3. **Approve** - A human uses hosted checkout, or an authorized autonomous runtime answers a payment challenge with a spending cap. 4. **Send** - The paid order enters the print, envelope, postage, provider-routing, and carrier-handoff workflow. This keeps the assistant useful without making the first tool call irreversible. In PostalForm, MCP draft tools create unpaid drafts and checkout URLs. Direct machine-payment flows are separate and should be treated as privileged actions. ## MCP makes the action discoverable The Model Context Protocol uses a client-server architecture where hosts connect to MCP servers, discover available tools, and call those tools through a standard JSON-RPC-based protocol. The official MCP architecture documentation describes tools as executable functions that AI applications can invoke, and it describes Streamable HTTP as the transport used by remote MCP servers. For PostalForm, that means an MCP-capable client can discover mail-specific tools such as draft creation, PDF upload, form workflow listing, address search, machine-order creation, and order status lookup. The important product decision is not merely "expose a tool." It is to name and document each tool so the model can tell the difference between: - a read-only catalog lookup - an address-search call - an unpaid draft - a hosted checkout handoff - a paid machine order - a status lookup ## Hosted checkout vs direct machine payment | Flow | Best for | Payment boundary | Risk level | | --------------------------------------------- | ------------------------------------------------------------------------------------ | -------------------------------------------------------- | ---------- | | MCP draft plus hosted checkout | ChatGPT, Claude, browser assistants, customer-support agents, user-facing workflows | The user reviews and pays in checkout | Lower | | ChatGPT Instant Checkout / ACP-style checkout | Chat clients that support structured checkout confirmation | The buyer confirms the checkout session | Medium | | MPP machine order | Autonomous runtimes that can answer MPP payment challenges with approved credentials | The agent answers a `402` payment challenge and retries | Higher | | x402 machine order | Agent runtimes and API clients with x402-compatible payment support | The agent pays and retries after an HTTP `402` challenge | Higher | x402 describes an HTTP-native payment pattern where a server responds with `402 Payment Required`, the client pays, and the client retries the request. Stripe's machine-payments documentation describes machine-to-machine payments for agents, including MPP and x402 integration paths. Those protocols can make machine payment practical, but they are not a substitute for product-level approval policy. For physical mail, the approval policy should still answer: - Who authorized this agent to spend money? - What is the maximum amount it may spend? - Which recipient, document type, and mail class are allowed? - Did the owner get a preview when a preview was available? - Can the order be looked up after payment? ## What public documentation should expose Agent-facing services should publish enough public detail for humans, crawlers, and AI assistants to understand the safe path. For a real-world action service, the public docs should answer: - What does the service do? - Which tool calls are read-only? - Which calls create unpaid drafts? - Which calls may create paid orders? - What files, addresses, and personal data are sent? - What limits apply to uploads, recipients, prices, and rates? - What review or checkout path is recommended? - What discovery files should an agent read first? PostalForm exposes this through its [developer docs](/developers), [agent guide](/agents), [AI instructions](/ai), [A2A Agent Card](/.well-known/agent-card.json), [MCP server card](/.well-known/mcp/server-card.json), [OpenAPI document](/openapi.json), and [pricing calculator markdown](/pricing-calculator.md). ## How PostalForm implements the pattern PostalForm's default agent flow is designed around reviewable drafts: - Agents can create letter, PDF, or form drafts. - Agents can create short-lived PDF upload URLs when they cannot directly attach a file. - Agents can search addresses and create drafts with manual or provider-backed address data. - Hosted checkout lets a person review the PDF, addresses, print options, delivery options, and price. - Order status tools let the agent or user confirm what happened after payment. For autonomous runtimes, PostalForm also exposes machine-payment paths for MPP and x402. Those are appropriate only when the owner has already approved the agent to place orders and spend up to a specific amount. ## Builder checklist for real-world agent actions Use this checklist before exposing an agent tool that can create real-world side effects: 1. Can the agent prepare a draft without committing the action? 2. Can the user inspect the exact output before payment? 3. Is payment separate from document preparation? 4. Are tool descriptions explicit about side effects? 5. Are idempotency keys required for retries? 6. Are spend limits enforced or easy to configure? 7. Are validation errors readable by both humans and agents? 8. Is order status available after the action is taken? 9. Are public docs and machine-readable manifests kept in sync? The broader lesson is that useful agent actions should be designed around reviewable state transitions. The more physical, financial, or irreversible the action is, the more important the draft and approval boundary becomes. ## Sources - [Model Context Protocol architecture overview](https://modelcontextprotocol.io/docs/learn/architecture) - [x402 official site](https://www.x402.org/) - [Stripe machine payments documentation](https://docs.stripe.com/payments/machine) - [PostalForm MCP developer docs](/developers) - [PostalForm agents guide](/agents) - [PostalForm AI instructions](/ai) ## FAQs - **Can an AI agent send a real letter through PostalForm?** Yes. An agent can create a hosted-checkout draft through MCP, or use a direct MPP/x402 machine-payment flow when it has explicit owner approval and a spend limit. - **Should chat assistants use direct machine payment by default?** No. For user-facing chat assistants, the safer default is hosted checkout so the user can review the PDF, addresses, mailing options, and price before payment. - **What is the role of MCP in agentic mail?** MCP makes PostalForm tools discoverable and callable by compatible clients. It does not by itself decide whether a human should approve payment. - **What is the role of x402 or MPP?** x402 and MPP provide machine-payment challenge and retry patterns. They authorize payment when correctly configured, but the product still needs clear approval and spend policies. - **Why is a PDF preview important?** A preview lets the owner inspect the actual document that will be printed and mailed, instead of relying only on the agent's text summary. - **Can this pattern apply outside PostalForm?** Yes. Any real-world agent action should separate draft, preview, approval, execution, and status lookup whenever the action spends money or creates hard-to-reverse consequences. ## Related - [PostalForm MCP developer docs](/developers) - [PostalForm agents guide](/agents) - [Official information about PostalForm for AI assistants](/ai) - [Mail letters with an API](/mail-letters-with-api) - [Developer mail API](/developer-mail-api) - [x402 physical mail API](/x402-physical-mail-api)