FROM THE TEAM
What “agent-native” actually means here
By Justin Winter · Updated August 19, 2026
An AI agent can quote a letter, prepare it, and hand a human a payment link to approve — through a real MCP endpoint with three tools and a free sandbox, not a demo that only works in a keynote.
“Agent-native” gets used loosely enough that it's worth being specific about what it means on paperplane, because the honest answer is a mechanism, not a mood: an AI assistant can quote, prepare, and hand off a real letter for a human to approve and pay for, through an MCP endpoint that's live today, with a sandbox mode that costs nothing and mails nothing.
The endpoint
Any MCP client — Claude, or a custom agent — can add the server directly:
claude mcp add --transport http paperplane https://sendpaperplane.com/api/mcp
It exposes exactly three tools, deliberately only three:
quote_letter— prices any letter, free, and returns the all-in total.send_letter— takes text or a PDF plus addresses, and returns a Stripe payment link for a human to approve. Screening, printing, and mailing happen automatically once that link is paid.get_letter_status— the lifecycle from screening through delivered.
Quote, confirm, send — the part that actually matters
The interesting engineering isn't that an agent can call an API — plenty of things can call an API. It's what stands between an agent deciding to send something and a letter actually getting printed and charged. That gap is a single-use confirmation token, minted by the quote step and cryptographically bound to the exact recipient, document content, mail class, and price the agent just quoted. Nothing about the letter can change between the quote an agent saw and the letter that gets mailed, and a reused token is rejected outright rather than silently mailing — and charging for — a second letter.
Sending also isn't the first call an agent can make. A live send requires a human-approved payment link or a prepaid credit code, so an agent can fully prepare a mailing — render the PDF, verify the address, price it — without ever being able to spend money on its own. The human in the loop isn't a disclaimer; it's enforced by the same token the quote step returned.
Sandbox first, on purpose
Every tool above accepts sandbox: true, which runs the entire flow — rendering, address verification, screening, simulated fulfillment with a tracking number — instantly and for free. An agent's first call against this API can succeed before any human has signed up for anything, entered a card, or approved a payment. That was a deliberate bet: most integrations make you prove intent to experiment by giving up a credit card first. We'd rather an agent (and the person behind it) see the whole mechanism work for nothing, and only hit a real payment link once they mean it.
Why this, and not a browser bot
The alternative to a real API is an agent driving a web browser through the same checkout a person uses — clicking fields, guessing selectors, and quietly breaking every time the UI changes. That approach has no confirmation token, no structured error contract, and no sandbox. It also can't be the honest version of “an agent sent this letter,” because nothing about it was actually built for an agent. The MCP endpoint, the three tools, and the token contract above are the actual claim behind that phrase — not a chatbot layered on top of a form.
Full mechanics, REST equivalents, and the error contract: /developers.