{
  "markdown": "# mcp-recurring\n\n<!-- mirror-seo:start -->\n\n**MCP server for recurring invoices and subscription billing: handles scheduled invoice documents.** Scheduled invoices, generated into your invoice book with PDFs.\n\nWorks with Claude Desktop, Claude Code, Cursor and any Model Context Protocol client. Runs on your own machine, or hosted with no install.\n\n## Install\n\n**Hosted, nothing to install.** Get a token from <https://mcp.zovo.one/mcp/connect> (the connect page) or <https://mcp.zovo.one/mcp/token> (the same token as JSON); a free anonymous one is issued on the spot and a Pro key works the same way. Then point an MCP client at `https://mcp.zovo.one/mcp/recurring` over streamable-http and send the token as `Authorization: Bearer <token>`.\n\nIf your client cannot set headers, put the token in the path instead: `https://mcp.zovo.one/mcp/recurring/t/<token>`. Both forms work. The bare URL with no token answers 401 on `tools/call`, so the token is not optional.\n\n**Claude Desktop, one click.** Download `recurring.mcpb` from the [latest release](https://github.com/theluckystrike/mcp-servers/releases/latest) and double-click it.\n\n**From source.** The mirror is self-contained: every `@theluckystrike/*` dependency is vendored, so a fresh clone builds with no extra setup.\n\n```sh\ngit clone https://github.com/theluckystrike/mcp-recurring.git\ncd mcp-recurring\nnpm install && npm run build\n```\n\nThen point your client at the built entry point:\n\n```json\n{\n  \"mcpServers\": {\n    \"recurring\": {\n      \"command\": \"node\",\n      \"args\": [\"/absolute/path/to/mcp-recurring/dist/index.js\"]\n    }\n  }\n}\n```\n\n> `@theluckystrike/mcp-recurring` is **not published on npm yet**, so an `npx -y @theluckystrike/mcp-recurring` command will fail. The three paths above are the working ones and each is exercised by CI.\n\n![recurring demo](https://raw.githubusercontent.com/theluckystrike/mcp-servers/main/assets/demo-recurring.gif)\n\nRead-only mirror of [mcp-servers/servers/recurring](https://github.com/theluckystrike/mcp-servers/tree/main/servers/recurring). See [MIRROR.md](MIRROR.md).\n\n<!-- mirror-seo:end -->\n\nSay \"bill Acme 12 hours at 90 EUR on the 1st of every month\" once, and stop remembering it. This MCP server stores recurring invoice schedules -- client, line items, cadence, start and end dates -- and then, when you ask, creates the invoices that have actually fallen due as real records in the [invoice server](../invoice), with its number series, its clients and its A4 PDF. Generation is idempotent: one invoice per schedule per period, keyed by the occurrence date, so running the billing run twice on the same day creates nothing the second time. It also answers \"what falls due in the next 30 days\" and \"what will I invoice per month for the next year\". Everything is stored in plain JSON files on your own machine; nothing is uploaded anywhere.\n\n\n**Define a repeating invoice once, generate the due PDFs from chat -- no billing SaaS required.**\n\n## 60-second install\n\nnpm publish for `@theluckystrike/mcp-recurring` is pending. Until then, the `.mcpb` one-click bundle or a clone+build\nis the working path -- both are verified below.\n\n**One-click (.mcpb):** download `recurring.mcpb` from the latest release and double-click it in Claude Desktop:\nhttps://github.com/theluckystrike/mcp-servers/releases/latest\n\n**Claude Desktop** (`claude_desktop_config.json`):\n\n```json\n{\n  \"mcpServers\": {\n    \"recurring\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"@theluckystrike/mcp-recurring\"]\n    }\n  }\n}\n```\n\n**Claude Code:**\n\n```sh\nclaude mcp add recurring -- npx -y @theluckystrike/mcp-recurring\n```\n\n**Cursor** (`.cursor/mcp.json`):\n\n```json\n{\n  \"mcpServers\": {\n    \"recurring\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"@theluckystrike/mcp-recurring\"]\n    }\n  }\n}\n```\n\nThe `npx` form above starts working the moment the package is published. Until then, use the .mcpb bundle above, or\nbuild from source with exactly these three commands:\n\n```sh\ngit clone https://github.com/theluckystrike/mcp-servers.git && cd mcp-servers\nnpm install\nnpm run build -w packages/mcp-license -w servers/invoice -w servers/recurring\n```\n\nThen point your client's `command` at `node` with one arg: the absolute path to `servers/recurring/dist/index.js`.\n\nTo run in Pro mode set `MCP_LICENSE_KEY` in the same config block, or call `license_activate` once with your key.\n\n## Pairs with\n\n- **[mcp-invoice](../invoice)** -- required in practice, not by code. This server writes into the invoice\n  server's data directory and shares its number counter, its client list and its business profile, so every\n  generated invoice appears in `invoice_list`, counts in `overdue_report` and can be re-rendered with\n  `invoice_pdf`. Set your issuer details once with `business_set` **there**; this server has no `business_set`\n  of its own on purpose, so there is only one profile to keep right.\n- **[mcp-time-tracker](../time-tracker)** -- for the hours that are not on a retainer. Track them, invoice\n  them ad hoc, and leave the fixed monthly part to a schedule here.\n- **[mcp-expense-tracker](../expense-tracker)** -- rebillable costs that change every month belong on an ad\n  hoc invoice; a schedule is for the amount that does not change.\n\n## Tools\n\n| Tool | What it does |\n| --- | --- |\n| `schedule_create` | Define a repeating invoice: client, items, cadence, start date, optional end date, due days, notes |\n| `schedule_list` | Every schedule with cadence, amount per period, next due date and status |\n| `schedule_get` | Full record for one schedule, plus how many invoices it has generated |\n| `schedule_update` | Change client, items, currency, cadence, dates, due days or notes. Periods already invoiced are never re-issued |\n| `schedule_pause` | Stop generating without deleting; history is kept |\n| `schedule_resume` | Make it active again. Periods that fell due while paused are still due |\n| `schedule_delete` | Remove the schedule. Invoices it made stay in the invoice server and its history is kept as an audit trail. A re-created schedule gets a new id, so `invoice_generate_due` warns when it re-covers a period the old one already billed |\n| `schedule_skip` | Skip ONE occurrence for good, without pausing the schedule -- the answer to \"do not bill this client for October\". `undo: true` puts the period back |\n| `schedule_upcoming` | What falls due in the next N days, with amounts and totals per currency, plus any period that already fell due and was never invoiced. Free covers 30 days |\n| `invoice_generate_due` | Create the invoices that are due as of a date and render their PDFs. Idempotent, keyed by period; reports created and skipped. At most 60 invoices per call, oldest period first, and it says how many are still due. `dry_run` shows the run first. Free and unlimited |\n| `schedule_history` | Pro: the audit log for one schedule -- every period, invoice number, dates, amount, paid status and PDF path |\n| `forecast` | Expected revenue per calendar month per currency, with paused schedules listed separately rather than dropped. Free covers 3 months |\n| `license_status` | Show free or Pro mode |\n| `license_activate` | Activate a Pro key (verified offline) |\n\nResource: `recurring://upcoming` returns the next 30 days of occurrences as JSON.\nPrompt: `monthly_billing_run` -- dry run, generate, list what is coming, then report who needs a payment reminder.\n\n## What you can say\n\n| You say | Tool |\n| --- | --- |\n| \"Bill Acme 12 hours at 90 EUR every month from the 1st.\" | `schedule_create` |\n| \"What recurring invoices do I have?\" | `schedule_list` |\n| \"What is due in the next 30 days?\" | `schedule_upcoming` |\n| \"Run this month's billing.\" | `monthly_billing_run` / `invoice_generate_due` |\n| \"Show me what would be created before you create it.\" | `invoice_generate_due {dry_run: true}` |\n| \"Pause the Beta Corp retainer, they are on hold.\" | `schedule_pause` |\n| \"Do not bill Acme for October.\" | `schedule_skip` |\n| \"Put the Acme retainer up to 100 EUR an hour from now on.\" | `schedule_update` |\n| \"How much will I invoice per month next year?\" | `forecast` |\n| \"Show me every invoice this retainer has produced.\" | `schedule_history` |\n\n## Worked example\n\n```\nYou: Bill Acme 12 hours at 90 EUR a month, starting 1 June, 14 day terms.\n\n  schedule_create {\n    client: \"Acme Retainer\", currency: \"EUR\", every: \"monthly\",\n    start_date: \"2026-06-01\", due_days: 14,\n    items: [{ description: \"Retainer hours\", quantity: 12, unit_price: 90 }]\n  }\n  -> schedule 9f2c1a04, next dates 2026-06-01, 2026-07-01, 2026-08-01, 2026-09-01\n\nYou (on 3 September): Run the billing.\n\n  invoice_generate_due {}\n  -> as_of 2026-09-03: created 4 invoices, skipped 0 already invoiced.\n     INV-2026-0001  Acme Retainer  period 2026-06-01  EUR 1080.00  due 2026-06-15  .../pdf/INV-2026-0001.pdf\n     INV-2026-0002  Acme Retainer  period 2026-07-01  EUR 1080.00  due 2026-07-15  .../pdf/INV-2026-0002.pdf\n     INV-2026-0003  Acme Retainer  period 2026-08-01  EUR 1080.00  due 2026-08-15  .../pdf/INV-2026-0003.pdf\n     INV-2026-0004  Acme Retainer  period 2026-09-01  EUR 1080.00  due 2026-09-15  .../pdf/INV-2026-0004.pdf\n     Total: EUR 4320.00\n\nYou (five minutes later, having forgotten): Run the billing.\n\n  invoice_generate_due {}\n  -> as_of 2026-09-03: created 0 invoices, skipped 4 already invoiced.\n```\n\nThe second run is the point: the period, not the calendar day, is the key, so a repeated billing run is a\nno-op rather than a duplicate invoice sitting in a client's inbox.\n\n## Free vs Pro\n\n| | Free | Pro |\n| --- | --- | --- |\n| Active schedules | 3 | Unlimited |\n| `invoice_generate_due` | Yes, unlimited | Yes, unlimited |\n| `schedule_upcoming` horizon | 30 days | Up to 10 years |\n| `forecast` | 3 months | Up to 120 months |\n| `schedule_history` audit log | No | Yes |\n| End-of-month and anchor-day rules (`anchor_day`, `end_of_month`) | No, bills on the start date's day of month | Yes |\n| Pause, resume, update, delete, dry run, multi-currency | Yes | Yes |\n\nPro is a one-time $19, or $39 for every server in the collection, lifetime.\n\n**Get Pro: https://mcp.zovo.one/buy/recurring**\n\n## Dates: what happens at a month end\n\nEvery date is a local ISO calendar date, `YYYY-MM-DD`. An occurrence is the k-th step from `start_date`, and\noccurrence 0 is `start_date` itself, so a schedule starting today is due today.\n\n- `weekly` = +7 days per step. `{days: n}` = +n days per step.\n- `monthly` = +1 month, `quarterly` = +3 months, `yearly` = +12 months.\n- **Month ends.** The month step keeps the day of month of `start_date` and clamps it to the length of the\n  target month; it never carries the clamp forward. From `2026-01-31` the series is 01-31, **02-28**, 03-31,\n  04-30, 05-31 -- February does not silently turn a month-end retainer into a 28th-of-the-month retainer.\n- **Feb 29.** The same rule makes a yearly schedule starting `2028-02-29` fall on 02-28 in common years and\n  back on **02-29** in the next leap year.\n- **`anchor_day` / `end_of_month` (Pro).** `anchor_day` replaces the day of month before clamping, so\n  `anchor_day: 31` means the last day of every month; `end_of_month: true` does the same explicitly. Both are\n  ignored for `weekly` and `{days: n}`, which have no month to anchor to. An anchored first occurrence that\n  would land before `start_date` is dropped, never billed early.\n- **`end_date` is inclusive.** An occurrence landing exactly on `end_date` is generated; the next one is not.\n- **Long-lived schedules.** Looking up what is due does not replay the schedule from `start_date`: it jumps to\n  an estimate near the date you asked about and scans forward from there, so a daily schedule created in 2010\n  still reports what is due in 2026 instead of exhausting its per-run occurrence cap walking there one day at\n  a time.\n\n## Money\n\nAmounts are held as integer minor units by the invoice engine -- the same ISO 4217 table, the same\nround-per-line-then-sum contract, so a schedule's amount and the invoice it produces can never disagree. Each\nline's gross is rounded first, tax is computed and rounded per line and grouped into one line per rate, and\nthe totals are integer sums of those already-rounded values. A schedule bills in its own `currency`, or your\nbusiness default currency if it has none; nothing here converts between currencies.\n\n## How it stores data\n\nSchedules and the generation log live in\n`${XDG_DATA_HOME:-~/.local/share}/mcp-servers/recurring/` as `schedules.json` and `history.json`. The\n**invoices** go into the invoice server's directory, `${XDG_DATA_HOME:-~/.local/share}/mcp-servers/invoice/`,\nwith their PDFs under its `pdf/` subfolder -- the same files `invoice_list`, `overdue_report` and\n`invoice_pdf` read there.\n\nEvery mutation runs under an advisory lock file. Anything that writes an invoice takes **two** locks, always\nin the same order -- `recurring/.lock` first, then `invoice/.lock` -- so two billing runs (or a billing run\nand a hand-written invoice in the other server) cannot interleave, cannot allocate the same invoice number\nand cannot deadlock. Invoice numbers are allocated inside the lock; the PDFs are rendered after it is\nreleased, so a slow render never holds up the counter. Saves go to a temporary file and are renamed into\nplace.\n\nIf `schedules.json` or `history.json` is unreadable or not valid JSON it is never treated as \"empty\": the\nfile is moved aside byte-for-byte as `<name>.json.corrupt-<timestamp>`, a `<name>.json.corrupt` marker is\nwritten, and every tool fails loudly until you restore a good copy and delete the marker. This matters more\nhere than anywhere else in the collection: a `history.json` silently read as empty would re-bill every period\nthe schedule has ever covered.\n\n## Limits and honest caveats\n\n- **Nothing runs in the background.** This is a stdio MCP server: it exists while your client runs it. No\n  daemon, no cron, no email. Invoices are created when you (or the `monthly_billing_run` prompt) call\n  `invoice_generate_due`. `auto_generate` is a marker for that prompt, not a scheduler.\n- **Nothing is sent to the client.** The server produces the invoice record and the PDF; delivering it and\n  chasing payment is still yours to do. `overdue_report` in the invoice server tells you who to chase.\n- Free tier allows 3 active schedules. Pausing one frees a slot; the paused schedule's history is kept.\n- Deleting a schedule keeps its history rows, deliberately: a re-created schedule with the same id cannot\n  double-bill a period. Invoices already generated are never touched by anything here.\n- `schedule_update` changes future periods only. A period already invoiced keeps the amount that was billed;\n  correct it in the invoice server instead.\n- No proration and no mid-period cancellation credit: a period is billed in full or not at all.\n- No currency conversion; a schedule bills in one currency.\n\n## Troubleshooting\n\n- **`npx` hangs or fails to find the package**: npm publish for this package is pending. Use the `.mcpb`\n  bundle or the clone-and-build path above until it lands.\n- **Using the clone path**: build `servers/invoice` before `servers/recurring` -- the engine is imported from\n  it. `npm run build -w packages/mcp-license -w servers/invoice -w servers/recurring` does that in order.\n- **\"No business profile yet\"**: run `business_set` in the invoice server (mcp-invoice), not here.\n  Generation is never blocked by it; the PDF just carries the placeholder issuer \"Your business\".\n- **The invoices are not in my invoice server**: both servers must see the same `XDG_DATA_HOME`. They write\n  to `.../mcp-servers/invoice/` under it; if one client sets that variable and the other does not, you have\n  two stores.\n- **A period was skipped**: `invoice_generate_due` only skips a period already present in `history.json`.\n  `schedule_history` (Pro) or the file itself shows exactly which invoice covered it.\n- **Node version**: requires Node >= 18. Check with `node -v`.\n\n## Privacy\n\nAll data stays local: schedules, the generation log, invoices and PDFs are plain files under your own home\ndirectory. The server makes no network calls at all, and license keys are verified offline.\n\nBuilt by [theluckystrike](https://github.com/theluckystrike). MIT. Support: support@zovo.one\n\n## One business profile for the whole suite\n\nYour identity is stored once, at `${XDG_DATA_HOME:-~/.local/share}/mcp-servers/profile/business.json`,\nand every server in the suite reads it: the invoice issuer, the docx letterhead, the recurring\nissuer, expense-tracker's default VAT rate, time-tracker's and timezone's home zone, and the\nresume and contract letterheads. Set it once with `business_set` (invoice or docx) - you never\nrepeat it anywhere else. An email address is only ever taken from that profile or from an explicit\nargument; when none is stored, documents show `[add: email]` and the tool says so rather than\nletting anyone improvise an address.\n",
  "bytes": 16893,
  "sha": "33a3f0b84f4e548e34ac63ce262fbb460373b7663c4a006ecf6faae43d90edd2",
  "repo_slug": "theluckystrike/mcp-recurring",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/plg_theluckystrike_mcp_recurring_ec15d46a/readme"
}