Start with the finding, because it shapes the page. Searching npm and the official MCP registry on 2026-09-03 turned up no MCP server that keeps recurring billing schedules locally and generates invoices into a store you own. The invoice servers are one-shot document generators with no scheduling at all, and the subscription servers are clients for a vendor's billing platform. Those are the two sides of the gap, and the two honest comparisons. invovate-mcp-server renders one invoice at a time through a hosted API. @paddle/paddle-mcp is Paddle's own server, and it does real subscription billing against a real payment rail.
| Fact | Ours | invovate-mcp-server | @paddle/paddle-mcp |
|---|---|---|---|
| Tools | 11 plus license_status and license_activate | 4 | Documented by name and grouped by resource; its README claims near parity with the Paddle API and states no total |
| Transport | stdio (npx or .mcpb bundle) | stdio, as a thin client over the hosted Invovate API | stdio |
| Account or API key needed | No. No account, no key | Yes for anything that renders a file: INVOVATE_API_KEY, free signup | Yes. A Paddle merchant account and PADDLE_API_KEY |
| Recurring schedules | Yes. weekly, monthly, quarterly, yearly or every N days | None | Yes, as Paddle subscriptions |
| Where the data lives | Local JSON, invoices in the invoice server's own store | Invovate servers; hosted links expire and the invoice is deleted after 7 days | The merchant's Paddle account |
| Money actually collected | No. It produces the invoice and the PDF | No | Yes, Paddle is the payment rail |
| Licence | MIT | MIT | Apache-2.0 |
| Latest release read | publish pending; .mcpb bundle and clone-and-build | 0.1.3, published 2026-06-07 | 0.1.6, published 2026-04-15 |
| Works with no network | Yes, entirely | No | No |
Every row was read on 2026-09-03 from that package's npm registry record and the README inside it. Neither competitor was installed or executed.
Pick it when the invoice has to leave your language or your alphabet. It renders invoices in eleven
languages, including right-to-left Arabic and Japanese, Hindi and Cyrillic scripts, and it emits UBL 2.1
XML alongside the PDF, plus QR codes and shareable hosted links. We do none of that: our PDF is A4 in
the currency and wording you set. Read two things in its README before you rely on it. The UBL export
is explicitly not regulated e-invoicing, with no Peppol, Factur-X, ZUGFeRD or XRechnung compliance and
no network delivery. And its npm description says no signup, which is true only of
calculate_invoice_totals and get_invoice_capabilities: rendering a PDF or a
UBL file needs the API key. Hosted links expire and the invoice is deleted after 7 days, though a
save_path argument writes the file locally.
Pick it if you sell a subscription and need the money to actually arrive. This is the official Paddle
server, and nothing in our collection is in the same category: it manages products, prices, discounts
and discount groups, customers, addresses and credit balances, subscription lifecycle, transactions and
financial reports, against a live payment rail with Paddle acting as merchant of record. It also ships a
PADDLE_MCP_TOOLS=non-destructive mode that hides the write tools, which is a good idea for
an agent holding billing credentials. It is Apache-2.0 and free as a package; the account behind it is
not, and we did not verify Paddle's fee schedule, so no rate is quoted here. Two caveats from its own
README and record: Paddle Classic is not supported, only Paddle Billing, and it is still 0.x, last
published 2026-04-15.
Pick ours when the retainer is an invoice rather than a subscription: you are not charging a card, you are sending a document with payment terms, and the only thing you keep forgetting is to send it. You define the schedule once and the invoices land in the invoice server's own store, in its number series, with its A4 PDF, its client list and its overdue report. There is no account, no key and no vendor. The whole thing works with the network off, and a client under NDA never appears on anybody's server.
Two design decisions here are worth more than a feature list.
The idempotency key is the period. History rows are keyed on the schedule id plus the occurrence date, not on a timestamp and not on the day the run happened. In the worked run, the first call on 3 September created 4 invoices totalling EUR 4,320.00 and the second call five minutes later created 0 and skipped 4. Because the key is the period, a repeated billing run is a no-op, and deleting a schedule keeps its history so a re-created one cannot double-bill.
A run is capped at 60 invoices, and the cap was measured into existence. Before it
existed, a schedule starting 1900-01-01 offered 1,520 due periods, and one call with a mistyped
as_of year created 1,193 real invoices and 1,193 PDFs, 6.0 MB in 6.8 seconds, burning 1,193
numbers out of a series that never reuses one. The run now bills the oldest periods first, stops at 60
and says how many remain.
The month step is the third: it keeps the start date's day of month and clamps it to the target month's length without carrying the clamp forward, so a 31st retainer bills on 28 February and returns to 31 March instead of moving permanently to the 28th.
Ours, Claude Code:
claude mcp add recurring -- npx -y @theluckystrike/mcp-recurring
claude mcp add invoice -- npx -y @theluckystrike/mcp-invoiceinvovate-mcp-server:
claude mcp add invovate -e INVOVATE_API_KEY=inv_your-key -- npx -y invovate-mcp-server@paddle/paddle-mcp:
claude mcp add paddle -e PADDLE_API_KEY=your-key -e PADDLE_ENVIRONMENT=sandbox -- npx -y @paddle/paddle-mcpPer client config paths for ours are on the setup pages, the product page is MCP Recurring Invoices, and the walkthrough is in billing a retainer on a schedule.
None was found on npm or in the official MCP registry on 2026-09-03. The invoice servers we checked generate one document per call with no scheduling, and the subscription servers are clients for a vendor's billing platform. If you know of one, mail support@zovo.one and this page will say so.
Only Paddle, which is the point of it: it is a live payment rail with Paddle as merchant of record. Ours produces the invoice record and the PDF; collecting and chasing are yours, and overdue_report in the invoice server lists who is late. invovate-mcp-server renders documents and does not collect either.
Ours needs none. invovate-mcp-server needs a free Invovate account for PDF and UBL rendering; no paid tier is documented in its README, and we did not verify whether one exists. Paddle's package is free and Apache-2.0, but it needs a Paddle merchant account, whose fee schedule we did not verify and therefore do not quote.
With ours, in plain JSON under your home directory, in the invoice server's data directory with the PDFs beside them. Invovate renders on its own servers and deletes the hosted invoice after 7 days, though save_path writes a local copy. With Paddle, everything is in your Paddle account.
Every row comes from the package's npm registry record and the README inside it, read on 2026-09-03: registry.npmjs.org/invovate-mcp-server and registry.npmjs.org/@paddle/paddle-mcp. Neither was installed, so the tool lists are as documented.