Finance Toolkit
500+ transparent financial methods calculated from raw statements, not third-party endpoints.
作者提供的说明(英文原文)
Milestone billing from accepted deliverables: due dates, sign-off dates, invoice-ready items.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
MCP_LICENSE_KEY标为机密的值是你账户的钥匙。千万不要分享给别人,也不要粘贴到聊天里。
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
链接指向作者自己的文件;我们不托管也不重新打包它。打开文件后,Claude Desktop 会进行安装。
在终端中运行这条命令
运行前请先填写空着的值。
浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
这个服务器在你的电脑上运行,而 ChatGPT 只能连接互联网上的服务器。请选择其他应用。
你的选择通过 Cookie 保存在这台设备上,无需账户。
这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
它在你的电脑上运行;安装后,工具列表会显示在你的 AI 应用中。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月8日
注册名称已通过 GitHub 账户 theluckystrike 验证,该账户拥有此仓库
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
它在你的电脑上运行,没有互联网端点
在你的电脑上运行,改用本地设置
它在你的电脑上运行;我们只能读取互联网端点的工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
你需要填写:MCP_LICENSE_KEY
它在你的电脑上运行。你的 AI 应用会在需要时启动它,数据不会经过作者的服务器(除非它自己调用在线服务)。
GitHub 仓库最后更新于–,最新版本(0.22.7)于24天前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。你的电脑上还需要有 MCPB。
同一分类中有:Finance Toolkit, SolidInvoice, Korea Tax Calculator
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
500+ transparent financial methods calculated from raw statements, not third-party endpoints.
Create and send invoices and quotes, manage clients, and track payments in SolidInvoice.
Korean tax calculation and tax-audit judgment MCP: 96 tools with statutory citations.
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
In the [official MCP Registry](https://registry.modelcontextprotocol.io/v0.1/servers/io.github.theluckystrike%2Fdelivery-schedule/versions/latest) (io.github.theluckystrike/delivery-schedule). Dated deliverables against a quote, a work order or a change order. Each one carries what is being handed over, the day it is due, its value in minor units, and a status that moves planned to in progress to delivered to accepted, every step with the day it actually happened. late_report then answers the only question anybody asks about a schedule: what has slipped, as at a date you name. Once the client has signed something off, the accepted milestones come back as invoice_create-ready items in MAJOR units and quote_create-ready items in MINOR units, in one call, with the scale printed against each.
Late is not a status here, it is a reading. A stored "late" flag is a fact about the afternoon somebody last ran the report, and it keeps being reported long after the work lands. So nothing derived is stored: a deliverable holds its due date, its value and its dated history, and the current status, the delivered date, the acceptance note, the lateness and every total are worked out on the call, against the date you passed.
One-click (.mcpb): download delivery-schedule.mcpb from the latest release and double-click it in Claude Desktop: https://github.com/theluckystrike/mcp-servers/releases/latest
Hosted, no install: point a URL-based client at https://mcp.zovo.one/mcp/delivery-schedule. GET https://mcp.zovo.one/mcp/connect mints a token and prints a ready URL.
npm publish for @theluckystrike/mcp-delivery-schedule is pending, so the npx line below returns 404 today.
~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": { "delivery-schedule": { "command": "npx", "args": ["-y", "@theluckystrike/mcp-delivery-schedule"] } } }
claude mcp add delivery-schedule -- npx -y @theluckystrike/mcp-delivery-schedule
~/.cursor/mcp.json (global) or .cursor/mcp.json (project), same entry as Claude Desktop.
| Tool | What it does |
|---|---|
delivery_schedule_create | Open a schedule against a quote, work order or change order: the reference, its own date, the client, a title |
deliverable_add | Add one dated deliverable: what it is, the day it is due, and its value in minor units when it is separately priced |
deliverable_status | Record a dated move: in progress, delivered, and accepted with the client's acceptance note |
deliverable_delete | Delete a deliverable added by mistake, while it is still planned and has nothing recorded against it |
delivery_schedule_get | One schedule in full as at a date, with every deliverable's status, dates, value and lateness |
delivery_schedule_list | Schedules by client, reference and whether the job is finished, with the counts as at a date |
delivery_schedule_delete | Delete an empty schedule opened by mistake. Free on every tier |
late_report | What is late as at a date you name, worst first, with the value at risk per currency |
delivery_schedule_document | The schedule as a plain-text document for the client, with a sign-off block |
milestone_payload | The accepted milestones as invoice_create items (MAJOR units) and quote_create items (MINOR units) |
license_status / license_activate | Free or Pro, and where to upgrade |
| Free | Pro | |
|---|---|---|
| Open schedules (a job with anything not yet accepted) | 3 | unlimited |
| Deliverables per schedule | 200 | 200 |
| Open, add, move, get, list, delete | yes | yes |
| What is late, as at any date | yes | yes |
| Delivery schedule document | no | yes |
| Milestone invoice payload, both scales | no | yes |
The cap counts OPEN schedules, the jobs that still owe something, not the jobs you have ever run. Accepting the last deliverable completes a schedule and frees its slot without deleting the record, and delivery_schedule_delete clears an empty one; both are free on every tier, because a way back that only a Pro key can reach is not a way back.
Get Pro: https://mcp.zovo.one/buy/delivery-schedule (one-time $19, lifetime), or all servers for $39: https://mcp.zovo.one/buy/bundle
planned to in_progress or straight to delivered; delivered to accepted. Accepted is final, and nothing moves back: work the client sent back is a new deliverable with its own due date, so the record keeps both the miss and the fix. Accepting something that was never delivered is refused by name, because acceptance is the client's answer to a handover and a deliverable accepted on a day nothing was handed over has no delivered date to bill from. Every move carries the day it actually happened, and a move dated before the reference document's own date, or before the previous move, is refused so the history reads as a timeline.
A deliverable is late once as_of is PAST its due date and it has not been delivered by then. One due on as_of itself is due_today, not late, which is the same rule the statement server ages an invoice by. A deliverable that was delivered is delivered_late or delivered_on_time by comparing its delivered date with its due date, which is a fact that no longer moves. Every comparison is between two YYYY-MM-DD strings and every day count is the difference of two UTC midnights, so the answer is the same on a laptop in Warsaw and a server in Auckland.
Two readings of the same store, four days apart, differ on purpose:
late_report as_of 2026-04-22 D02 is LATE by 2 days, nothing has been delivered late
late_report as_of 2026-05-05 D02 was DELIVERED LATE by 4 days, D03 is now LATE by 4 days
A deliverable with no value_minor is not worth zero. It is one whose price was never stated here, usually because the job is a lump sum, and adding it in as zero would understate every total with nothing on the page to say so. It is counted apart wherever a total is printed, and milestone_payload lists it under excluded.accepted_but_unpriced rather than billing it. Nothing here invents a price.
This server keeps no arithmetic of its own. computeTotals, currencyDecimals, formatMoney and daysBetween are imported from @theluckystrike/mcp-invoice/lib, the corrupt-store quarantine from @theluckystrike/mcp-timezone/lib, the timezone-aware "today" from @theluckystrike/mcp-quotes/lib. The VAT rate, the currency and the business name come from the shared business profile that business_set in the invoice server writes. Nothing is written outside this server's own directory, and no sibling store is opened.
The same deliverable is late, on time and not yet due depending only on the date you ask about, so storing the answer is storing the day somebody asked. D02 in the worked example is due 2026-04-20 and was delivered 2026-04-24. Read at 2026-04-22 it is late by two days with no delivered date at all, even though the store already holds one dated 04-24. Read at 2026-05-01 it is delivered late by four days. Read at 2026-04-19 it is not yet due. One store, three answers, all correct. The unit suite asserts all three from one unchanged sandbox, and a separate suite replays every call under four timezones fourteen hours apart and asserts the responses are byte-identical, so the day somebody reads the report on a laptop that travelled cannot move a client's deadline.
All data stays on your machine, in ${XDG_DATA_HOME:-~/.local/share}/mcp-servers/delivery-schedule/. Nothing is sent anywhere. There is no account and no API key. License keys are verified offline. This server reads one file it does not own, the shared business profile, and writes into no store but its own.
Built by theluckystrike. https://github.com/theluckystrike
Any MCP client (Claude, Cursor, Windsurf, VS Code) can read this repository's documentation directly via GitMCP - no install: