When not to choose FrankKi (checked 2026-08-13)

We build FrankKi. This page exists to send you somewhere else when somewhere else is the better answer.

That is not modesty. It is the only honest way to write about a category that, on 2026-08-13, has at least eight MCP servers capable of putting a real letter in the post — six of them listed in the official MCP Registry, plus PostalForm and LetterAPI running their own, plus Sendoso's enterprise beta. We claim no exclusivity anywhere on this page. Several of these products do things FrankKi does not do at all, and at least one of them wraps a company that FrankKi itself buys fulfilment from.

Read the routing table. If a row matches your need, follow the link and stop reading. If none of them match, the section after the table describes the narrow thing FrankKi is actually built for.

A cell reading not measured means no page we fetched on 2026-08-13 stated it. It does not mean the feature is absent. Vendor pages change without notice: if a figure here disagrees with a vendor's own site today, the vendor's site wins.

The routing table

1. Your agent needs to receive and read incoming mail

Use mailbox.bot instead. Fetched 2026-08-13.

FrankKi has no inbound product of any kind: no receiving address, no scanning, no OCR, no package tracking. mailbox.bot is the only server in this comparison that documents inbound as a first-class capability. Its page describes turning "scans, photos, PDFs, and notes" into agent-readable context with OCR and field extraction, plus package event monitoring. Its own managed receiving addresses are in a limited-access reservation phase, planned at "$15/mo for approved accounts" after identity verification and facility approval; the vendor page did not state an issuing date on 2026-08-13.

Registry entry: bot.mailbox/mailbox 1.0.1. Salt Lake City, UT.

2. US sender, US recipient, price is deciding

Use mailbox.bot or Mailsnail instead. Both fetched 2026-08-13.

mailbox.bot publishes a "$1.00 flat price" for a single-page USPS First-Class letter, with per-page printing at "$0.30/page B&W" or "$0.70/page" colour. Mailsnail publishes $1.50 for a first-class letter, $9.75 for a certified letter, $1.00 for a 4×6 postcard. (The certified price was $9.00 on 2026-08-13; re-fetched 2026-08-18.)

FrankKi's checked-in anchors for a German standard letter are from EUR 1.49 per piece with a partner account (under 20 letters a month every letter is EUR 2.49, and the rung you reach applies to every letter that month, including the first) and EUR 3.39 in black and white without one. We do not compete on US domestic per-piece price and are not trying to. (FrankKi prices are server-authoritative in any case — shipping_quote returns the destination price before any send, and an agent should never hardcode one.)

3. US volume, and you want the per-piece floor low

Use MailStream instead. Fetched 2026-08-13.

MailStream publishes "$99 a month and every piece ships at wholesale. No volume tiers, no negotiation" — letters "from $0.80 / piece" and postcards "from $0.58 / piece" on the plan, or pay-as-you-go from "$0.97 / piece" for letters and "$0.82 / piece" for postcards.

FrankKi's partner ladder starts discounting at 20 German standard letters a month, not at 1,000: under 20 letters a month every letter is EUR 2.49, from 20 letters a month every letter that month is EUR 2.19, from 100 it is EUR 1.99, from 500 EUR 1.79, and from 1,000 letters the floor of EUR 1.49. The rung you reach applies to every letter that month, including the first. Even at that floor we are dearer per piece than the cheap end of the US market: MailStream from $0.80 on its plan, mailbox.bot at $1.00 flat, Mailsnail at $1.50. Not every US rival on this page undercuts us (LetterAPI publishes $3.25 per letter into the USA), but if a low US per-piece price is what you are optimising for, we are not it.

Registry entry: app.mailstream/mailstream 1.0.0. On its developer page, MailStream states of the MCP ecosystem "Zero are for physical mail, except this one" (fetched 2026-08-13); the official registry listed at least five other physical-mail servers that day, one of them published 2026-05-27, before MailStream's own 2026-07-20. We record the claim and let the registry speak.

4. You want no account at all — the agent should pay and go

Use PostalForm instead, or Mailsnail if your client can mint a Stripe Shared Payment Token. Both fetched 2026-08-13, Mailsnail re-fetched 2026-08-18.

Mailsnail changed here between 2026-08-13 and 2026-08-18, and the change runs against us, so it is stated first: its managed server now expects an account. The llms.txt re-fetched 2026-08-18 reads "Add the remote server, sign in from your client, and mail draws against a prepaid balance", and "Mail draws against a prepaid balance rather than charging a card per piece". Sign-in is OAuth with "Email and password today".

The no-account route still exists, under the heading "Anonymous HTTP API (no account)": POST /v1/letters without payment returns 402 with a payment_request, settled with a Stripe Shared Payment Token. Mailsnail''s own caveat is the important part — "Requires a client that can mint a Stripe Shared Payment Token. Most coding agents cannot do this today — use the managed server above instead." Refunds are automatic if the mailing fails.

So on 2026-08-18 the honest version is: PostalForm is the no-account option for an agent flow, and Mailsnail is the no-account option only if your client can mint an SPT.

PostalForm's agents guide names an x402 HTTP 402 handshake, an MPP endpoint using WWW-Authenticate: Payment, and "Stripe Shared Payment Tokens (spt_...)". Its remote MCP server at https://postalform.com/mcp required no API key for agent flows on 2026-08-13.

FrankKi requires a signup and a prepaid wallet funded through hosted Stripe Checkout. We ship no machine-payment rail: no x402, no MPP, no Shared Payment Tokens. If your architecture is "the agent pays, nobody has an account", FrankKi is the wrong shape.

5. Postcards

Use MailStream or Mailsnail instead. Both fetched 2026-08-13.

FrankKi sends letters. It does not send postcards. Mailsnail publishes $1.00 for a 4×6 postcard and offers 6×9 and 6×11 sizes (prices for those were not stated on the page we fetched). MailStream publishes postcards from $0.82 pay-as-you-go, $0.58 on the plan.

6. Bulk campaigns, mailing lists, marketing analytics

Use MailStream or PostalForm instead. Both fetched 2026-08-13.

MailStream's developer page documents 27 tools covering campaign management with analytics alongside sending. PostalForm's agents guide documents bulk campaign launch.

FrankKi has no campaign object, no list management, no A/B testing, no open-equivalent analytics. It sends individual letters, and its batching tool exists to send many distinct letters, not one letter to many people.

7. Enterprise gifting and B2B direct mail inside a revenue workflow

Use Sendoso instead. Announcement re-verified 2026-08-13.

Sendoso announced an MCP beta on 2026-06-24 with founding integration partners Demandbase, UserGems, Gong, Outreach, Clay and Warmly, positioned as a signal → send → follow-up loop for marketing, sales and customer-success agents. It is request-based; access is approved on a rolling basis. Endpoint, tool surface, pricing and coverage: not measured, because the product surface is not reachable without beta approval.

This is a different buyer from every other row here. FrankKi does not do gifting.

8. The cheapest published European standard letter

Use SendLetter instead. Fetched 2026-08-13.

SendLetter's published prices are per single-page letter, VAT included: standard €2.36–€4.48, priority €3.57–€4.78, registered €12.04–€47.92, "€0.24 each extra page". For Germany specifically: standard €2.36, priority €3.57, registered €12.04.

FrankKi's checked-in anchors for a German standard letter are EUR 3.39 black and white and EUR 3.49 colour without a partner account, and from EUR 1.49 per piece with one (under 20 letters a month every letter is EUR 2.49, and the rung you reach applies to every letter that month, including the first). FrankKi's prices include VAT, on the same basis as SendLetter's. Against SendLetter's €2.36 into Germany it cuts both ways: for a one-off letter, and on our entry tier, SendLetter's published price is the lower one, and at partner-account volume ours drops below it, down to EUR 1.49. If you are sending a single letter and the published price is what decides, use SendLetter.

Registry entry: eu.sendletter/sendletter 1.0.0, published 2026-08-08 — one day after FrankKi. It is the closest European rival and it is a serious one.

9. Registered mail across many European countries, not just DACH

Use SendLetter instead. Fetched 2026-08-13.

SendLetter names 15 countries — Netherlands, Austria, Belgium, Switzerland, Germany, Denmark, Spain, France, United Kingdom, Ireland, Italy, Luxembourg, Poland, Portugal, Sweden — plus a rest-of-world tier, and offers registered mail across that range at €12.04–€47.92 including VAT.

FrankKi's registered products are a short, named list. Germany has Einschreiben Einwurf and Einschreiben Übergabe; Switzerland has a named Pingen registered product; Austria has no registered tier at all. Outside those, FrankKi will refuse rather than substitute. If you need registered mail into Italy or Poland today, we will tell you no and SendLetter will tell you yes.

10. Canada, or a fixed published North American price

Use LetterAPI instead. Fetched 2026-08-13.

LetterAPI publishes $2.49 per letter to Canada, $3.25 to the USA, and $1.80 per letter at 500+ letters/month. Canada and USA only. Four tools: send_letter, get_order, list_orders, get_account. Auth is "Simple token auth. Pass your key directly in the Authorization header — no Bearer, no OAuth." Dev mode caps at "Max 3 addresses per call". No spending caps or approval workflow were documented on the page we fetched.

FrankKi can quote worldwide destinations, but it publishes no fixed Canadian price and holds no Canadian named registered product.

11. Your agent harness has a tight tool budget

Use LetterAPI (4 tools), Mailsnail (7 tools) or SendLetter (9 tools) instead. All fetched 2026-08-13.

FrankKi exposes 64 model-visible tools (72 total, 8 app-only). That is a real cost: more context consumed before your prompt starts, and more surface for a model to mis-select against. It buys the approval family, the archive, template and design management, multi-client handling and sender profiles — but if your agent only ever needs "verify address, quote, send, check status", a four- or seven-tool server will behave better in a small context window and you should use one.

12. Free US CASS address validation

Use Mailsnail instead. Fetched 2026-08-13.

Mailsnail's verify_address performs "USPS CASS validation. Free." MailStream documents address verification among its 27 tools.

FrankKi validates addresses, but it has no US CASS-equivalent path. For US deliverability scrubbing before a send, use a US-native tool.

13. You want to run the whole chain in a sandbox before you trust it

Use MailStream or SendLetter instead. Both fetched 2026-08-13.

MailStream: "Every account starts in sandbox. Flip to production when you are ready." SendLetter's sandbox account runs the whole chain without printing or charging. mailbox.bot ships sandbox testing keys. LetterAPI has a dev mode with test keys.

FrankKi's sandbox is a per-account grant and it is off by default. On 2026-08-13 a live mcp_health call on our own production account returned capabilities.sandbox: false and the sandbox step as unavailable. The documented substitute is dryRun: true, which validates and previews without printing or charging — but that is a weaker default than three of our rivals ship, and we are not going to dress it up.

14. High-volume US direct mail with an established vendor

Use Lob or PostGrid, through a third-party aggregator. Checked 2026-08-13.

Neither has shipped a first-party MCP server. On 2026-08-13 lob.com/mcp returned HTTP 404, lob.com/developers named no MCP server, and the official MCP Registry returned no entry for either vendor. Agent access to Lob runs through third-party aggregators — MCPBundles publishes a managed Lob bundle exposing 49 tools against your own Lob API key. thanks.io, separately, does advertise its own — "A clean REST API, MCP server, OpenAPI spec, and webhooks" (fetched 2026-08-13) — if a US postcard-and-letter marketing platform is what you actually want. No specific PostGrid wrapper was verified on 2026-08-13.

If your requirement is a decade of US direct-mail scale and you can accept that the agent layer is somebody else's wrapper, that is a legitimate trade and FrankKi does not beat it.

15. Faxes, or a PixelLetter account you already have

Use the third-party PixelLetter wrapper. Registry entry io.github.bitterdev/pixelletter-mcp 1.0.3, checked 2026-08-13.

PixelLetter GmbH & Co. KG sends German letters, postcards, faxes and Einschreiben. The MCP server is not first-party: the registry namespace io.github.bitterdev/… is an independent developer wrapping PixelLetter's interface, it is an npm package over stdio with no hosted endpoint, and pixelletter.de made no mention of MCP on 2026-08-13. The registry description says "test mode included". PixelLetter prices: not measured — the pricing page returned HTTP 404 on 2026-08-13.

FrankKi does not send faxes.

16. You are already a Pingen customer

Use the third-party Pingen MCP server. Checked 2026-08-13 on Glama.

This one is uncomfortable for us and we would rather say it than have you find it: Pingen is one of FrankKi's own fulfilment upstreams, and an independent developer publishes a Pingen MCP server that will "Send physical letters (A-Post, B-Post, registered, etc.) from PDF files, manage drafts, and track deliveries" through the Pingen v2 API. It is a community project (maintainer sapn95, listed as unclaimed on Glama), not Pingen's own server, and it is PDF-in rather than a drafting and formatting layer. But if you already have a Pingen account and a PDF, it is a shorter path than us.

What FrankKi is actually built for

One thing, narrowly: letters that have to survive a compliance review in German-speaking Europe.

That means specific, checkable behaviours rather than a coverage claim:

• Named registered products, or an explicit refusal. Germany's Einschreiben Einwurf (deposited in the recipient's mailbox, no recipient signature) and Einschreiben mit Übergabe (handed over against signature) are real named catalog products. Where a destination has no supported registered product, FrankKi returns LEGAL_PROOF_UNAVAILABLE_FOR_COUNTRY and stops. It never downgrades silently, and it never infers a registered product from a price delta — a price delta can justify a tracked tier and nothing more.
• Proof of posting as a retrievable artifact. order_einlieferungsbeleg returns the archived posting record with a postmark or provider-observation timestamp and a hash-chain proof over the archived object. That is proof of posting. It is not proof of delivery, and it is not proof that the letter did what you needed it to do legally.
• A human approval surface that is on by default. Approval mode defaults to review: the agent submits, a human releases it in the iOS app or the dashboard, and the request expires after 10 minutes with nothing charged. Verified live on 2026-08-13. The tool family is approval_submit, approval_decide, approval_list.
• Spend and price safety on the send itself. order_send aborts above maxCostEuros, and aborts with PRICE_CHANGED if the priceVersion no longer matches. Prices are server-authoritative: quote with shipping_quote before every order_send, and never hardcode a price in agent behaviour.
• DACH office formalities. DIN 5008 layout, GoBD-oriented archiving, DATEV compatibility, and Mandanten separation so an agency or a practice can keep clients apart inside one account.
• OAuth 2.1, not a static key. On 2026-08-13, https://mcp.frankki.app/.well-known/oauth-authorization-server returned HTTP 200 with issuer https://mcp.frankki.app, registration_endpoint https://mcp.frankki.app/api/mcp/v1/oauth/register, code_challenge_methods_supported: ["S256"] and 21 scopes — Authorization Code with PKCE and Dynamic Client Registration, live. The US set in this comparison uses static bearer keys, PostalForm requires no auth for agent flows, and Mailsnail offers an anonymous route its own docs tell most agents not to use. Which of those is right depends entirely on whether anyone will ever audit what your agent sent.
• An EU data-residency story and a native iOS app as the place a human actually looks at what the agent wants to send.

None of the competitor registry descriptions we read on 2026-08-13 claim that combination. That is the wedge, and it is a workflow claim — not a claim that we deliver to more places, faster, or cheaper. We do not.

The short version of our weaknesses

Collected in one place so you do not have to reconstruct them from the table:

• Higher per-piece price than the cheap end of the US market on this page (MailStream, mailbox.bot, Mailsnail), even at our volume floor, and mid-range against SendLetter in Europe.
• The volume ladder needs a partner account, and only reaches its EUR 1.49 floor at 1,000 letters a month; without a partner account there is no volume price at all.
• No inbound mail, no scanning, no receiving address.
• No postcards. No faxes.
• No bulk campaign or marketing tooling.
• No machine-payment rails — no x402, no MPP, no Stripe Shared Payment Tokens.
• No US CASS-equivalent address validation.
• Mandatory signup and a prepaid wallet, where one rival needs no account at all.
• 64 model-visible tools against Mailsnail's 7 and LetterAPI's 4 — a real context and tool-selection cost.
• A sandbox that is off by default, where three rivals ship one that works out of the box.

If you read that list and none of it disqualifies us, the compliance wedge above is probably why you are here.

A note on legal effect. FrankKi helps you draft, format, and send physical letters, but it does not determine whether a particular letter is legally sufficient or legally effective. That depends on the specific matter, including the content and required declaration, the sender's authority, any required signature, the correct recipient and address, applicable form requirements, and compliance with the relevant deadline. DIN 5008 concerns the presentation and layout of a business letter; it is not a guarantee of legal sufficiency or legal effect. A postmark or posting receipt, such as an Einlieferungsbeleg, can document when the postal service accepted the item (proof of posting). A delivery record or recipient signature, where the selected service provides one, can document a delivery or handover event (proof of delivery). Neither type of postal evidence, by itself, proves that the content was legally sufficient, that all form requirements were met, that receipt was legally effective, or that the intended legal effect occurred. You are responsible for checking the content, recipient, authority, form, signature, and deadlines before sending. FrankKi provides no legal advice or individual legal assessment. For an important or legally sensitive matter, consult a qualified lawyer or an appropriate advice service.

Corrections. If we have described your product wrongly, email our support team. We correct verifiable errors and date the correction.