Change orders against a quote or a work order, with the running contract value built from what the client actually approved. You raise a change order against a quote or a work order, naming the client, the change in one line and, on the first one for that reference, the original contract value in minor units. Then you add the lines: added work with a quantity and a unit price, removed work the same way, and a changed line with what it was and what it is now. You move it to sent on the day it goes out, and to approved or rejected on the day the client answers, each step dated and a step dated before the last one refused. contract_value then answers the question the whole thing exists for: the original, plus the deltas the client APPROVED, equals the value today, with the draft and sent deltas shown apart and never added in. The original value is stated once per reference and inherited by every later change order, and a different figure is refused by name, because a contract with two original values has two running values and the customer sees whichever was typed last. No delta is stored: the delta, the VAT and the running value are derived from the lines on every call with the invoice server's own arithmetic. Lines go only on a draft; a sent change order that needs another line is voided and raised again, so the client's approval always refers to what they were sent, and a draft cannot be approved directly because approval is the client's answer to something they were sent. Once approved, the delta comes back as invoice_create items in major units and quote_create items in minor units in one call, and a changed line comes back as two items, the reversal and the revised line, never one net item, so both figures reproduce on a calculator from the change order the client signed. It creates no invoice and no quote of its own: the payload says posted false, and you run invoice_create in the invoice server.
change_order_get, change_order_list and contract_value are free, unlimited and write nothing, so leave them enabled permanently and read the running value as often as you like. change_order_create is the one that spends an open slot, and change_order_delete gives it straight back while the change order is still a draft with no lines, so a mistyped one costs nothing but the retype; approving, rejecting or voiding one frees the slot too.
| You say | Tool |
|---|---|
| Raise a change order against Q-2026-0003 for Harbour Cafe, original value 2,000,000 minor units: second landing page, drop hosting, widen the audit. | change_order_create |
| Add two landing pages at 45,000 each, remove twelve months of hosting at 3,999, and the audit was three at 45,000 and is now five at 42,000. Then mark it sent on 2026-03-12. | change_order_add_line |
| They approved it on 2026-03-15. What is Q-2026-0003 worth now, and build the invoice payload for the delta. | contract_value |
A changed line is two items, not one, because one net item shows the customer nothing they can check. A line that goes from 3 x EUR 450.00 to 5 x EUR 420.00 is worth +EUR 750.00, and the tempting payload is one item of quantity 1 at EUR 750.00, which reproduces from nothing on the change order the client signed. The payload this server emits is a reversal, -3 x 450.00, and the revised line, 5 x 420.00; each reproduces on a calculator, and the invoice server's own computeTotals over both is the same +750.00, because its roundHalfUp is symmetric in sign. That same symmetry carries a removal as a negative quantity through invoice_create, and it is what quote_create refuses, so the quote payload carries a ready flag instead of a promise. The worked change order runs the whole way through: added 90,000, removed 47,988, changed +75,000, delta net 117,012, VAT 26,913 per item, delta gross 143,925, rounding drift zero, and the contract goes from 2,000,000 to 2,117,012 only on the day the client approves. The unit suite then feeds the quote payload's minor figure into the invoice engine as though it were major and asserts the net is exactly 100x, 11,701,200 against 117,012, re-derived from each payload's own items, so the day someone simplifies the payload to one net item or moves a field between the scales, the build says so instead of the customer.
The file is .cursor/mcp.json, and the key inside it is mcpServers.
| Scope | Path |
|---|---|
| This project only | <project>/.cursor/mcp.json |
| Every project | ~/.cursor/mcp.json |
{
"mcpServers": {
"change-order": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@theluckystrike/mcp-change-order"]
}
}
}The Customize page shows the server and its tools once it has started.
The npm publish of @theluckystrike/mcp-change-order is pending; until then use the .mcpb bundle or a clone and build from the latest release.
The same server runs at https://mcp.zovo.one/mcp/https://mcp.zovo.one/mcp/change-order over MCP streamable HTTP, no install. Mint a free token with curl https://mcp.zovo.one/mcp/token, or use a Pro key. It has no filesystem, so a file comes back as a one-hour download link.
{
"mcpServers": {
"change-order": {
"url": "https://mcp.zovo.one/mcp/https://mcp.zovo.one/mcp/change-order",
"headers": { "Authorization": "Bearer <token>" }
}
}
}The current field table marks `type` as required, with `stdio` for a locally launched server, so write it out rather than relying on command and args alone. The other documented restriction is that `envFile` is stdio-only: a remote HTTP or SSE server does not read it, and its headers belong in the config.
Free: Five OPEN change orders, draft and sent, and 200 lines on each of them on every tier. The cap counts the ones the client has not answered rather than the ones ever raised, so approving, rejecting or voiding one frees its slot, and change_order_delete on a draft with no lines is free on every tier as well, because a way back that only a Pro key can reach is not a way back. contract_value is free on every tier: the running value is the thing the change orders exist to answer, and withholding it would withhold the record. A byte-identical change order is refused before the cap is even consulted, so a double-typed change names the id already stored rather than being met with an upgrade prompt, and burns neither a slot nor a CO number. Pro is $19 once, verified offline.
<project>/.cursor/mcp.json applies to that project and can be committed, which suits a server tied to one client. ~/.cursor/mcp.json applies everywhere. Both are managed from the Customize page.
The current field table marks type as required, with stdio for a locally launched server, so include it. Pointing at a remote endpoint, envFile is documented as stdio-only and is not read.
Servers in Cursor's marketplace get an Add to Cursor button. The deeplink reference currently documents prompt, command and rule links only, so for MCP Change Order pasting the config block above is the supported route.
MCP Change Order in detail · The same server in Claude Code and VS Code · Every server in Cursor · Guides · Cursor docs · Buy Pro