Most quoted jobs change after the quote. A second page is asked for after the kickoff, the hosting is dropped because the client moved in-house, the audit is widened to five sites. Those changes live in an email thread and a spreadsheet column called extras, and three months later nobody can say what the contract is worth or which of the extras the client actually agreed to. The MCP Change Order server keeps each change as a record against the quote or work order it changes: the lines, the reason in the client's words, the day it was sent and the day it was answered. It stores no delta, creates no invoice, and invents nothing.
claude mcp add change-order -- npx -y @theluckystrike/mcp-change-orderCursor, in .cursor/mcp.json, and Claude Desktop with the same block under
mcpServers. Put it at the same scope as mcp-invoice: the VAT rate, the currency
and the name on the document come from the shared business profile that server writes, and the payload
this server builds is that server's argument shape.
A line that goes from 3 x EUR 450.00 to 5 x EUR 420.00 is worth +EUR 750.00. The tempting payload is one
item of quantity 1 at EUR 750.00. The customer cannot reproduce that figure from anything on the change
order they signed: there is no 750 on it. 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 from the change order, and the invoice server's own
computeTotals over both is the same +750.00, because its roundHalfUp is symmetric in
sign.
That symmetry is what lets a removal ride through invoice_create as a negative quantity at the
unit price it was booked at. It is also exactly what quote_create refuses, because a quote
quantity must be greater than zero, so the quote payload carries a ready flag and says why it is
false rather than promising a quote it cannot make. The unit suite re-runs computeTotals over the
payload as returned and asserts the four item values and the three totals, so the day someone simplifies the
payload to one net item, the build says so instead of the customer.
Once a change order is approved, change_order_invoice_payload builds the delta twice in one
call: invoice_create items with unit_price in MAJOR units, 450 for EUR 450.00, and
quote_create items with unit_price_minor in MINOR units, 45000 for the same price.
Both fields are plain numbers, both are called the unit price, and neither tool can tell it was handed the
other one's scale. The suite feeds the MINOR figure into the invoice engine as though it were MAJOR and asserts
the net is exactly 100x, 11,701,200 against the correct 117,012, re-derived from each payload's own items.
Take the payload named for the tool you are about to call, and change no number in it.
Q-2026-0003, Harbour Cafe, EUR, original value 2,000,000 minor, VAT 23% from the shared profile
L01 added Extra landing page 2 x 450.00 +900.00
L02 removed Managed hosting 12 x 39.99 -479.88
L03 changed Website audit was 3 x 450.00, now 5 x 420.00 +750.00
--------
delta net 1,170.12
VAT 23% per item: 207.00 - 110.37 - 310.50 + 483.00 = 269.13
delta gross 1,439.25
rounding_drift_minor 0
contract value while draft or sent: 20,000.00 (1,170.12 pending, not added in)
contract value once approved: 21,170.12The invoice payload for that delta carries FOUR items, 2 x 450.00, -12 x 39.99, -3 x 450.00 and 5 x 420.00, and their values are 900.00, -479.88, -1,350.00 and 2,100.00. The changed line is the last two, and they sum to the +750.00 the change order shows.
contract_value answers the question the whole thing exists for: the original, plus the deltas
the client APPROVED, equals the value today. Draft and sent change orders are shown as a pending delta beside
it and are never added in, and the value if every pending one were approved is stated as its own figure so
the two are never added by hand. Rejected and void change orders count for nothing.
The original value is stated ONCE per reference, on the first change order, and every later one inherits it. A later change order that states 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. A reference with no change order on file has no running value, and the server says so rather than starting from nothing but the change order's own delta: it does not open the quotes or work-order store to find the figure.
draft to sent; sent to approved or
rejected; draft or sent to void. Approved, rejected and
void are final. A draft cannot be approved directly, because approval is the client's answer to something they
were sent. 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. Every step carries its own date, and a step
dated before the last one is refused, because a history that runs backwards cannot be read as a timeline.
Free is five OPEN change orders, draft and sent, with 200 lines each on every tier. The cap counts the
ones the client has not answered, not 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, because a way back
that only a Pro key can reach is not a way back. contract_value is free on every tier. A
byte-identical change order is refused BEFORE the cap is consulted, so a double-typed change names the id
already stored rather than being met with an upgrade prompt.
Pro is $19 once, lifetime: unlimited open change orders, the change order document with the approval block for the client to sign, and the invoice payload for the approved delta in both scales. All servers together are $39.
Because one net item shows the customer nothing they can check. 3 x 450.00 becoming 5 x 420.00 is +750.00, and an item of quantity 1 at 750.00 reproduces from nothing on the change order the client signed. A reversal of -3 x 450.00 and the revised 5 x 420.00 both reproduce on a calculator and sum to the same +750.00, because the invoice server's roundHalfUp is symmetric in sign. The unit suite re-runs computeTotals over the payload as returned and asserts all four item values, so a payload simplified to one net item fails the build.
The original plus the deltas already APPROVED, and nothing else. The sent change order's delta is shown as pending beside that figure and never added in, and the value if every pending change order were approved is stated separately so nobody adds the two by hand. Rejected and void change orders count for nothing.
The original value is stated once per reference and inherited by every later change order. This server does not open the quotes or work-order store to find it, so the first change order has to state it, and a later one that states 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. Omit it on later change orders and the figure on file is inherited.
No. The client is looking at that change order, and a line added under them makes their approval an approval of something else. Void it and raise a new one with every line. Approved, rejected and void are final for the same reason: a change order the client has answered is a fact about what they answered.
invoice_create accepts a negative quantity, so a removal rides through as -12 x 39.99 at the price it was booked at and the invoice engine's rounding is symmetric in sign. quote_create refuses a quantity that is not greater than zero. So the quote payload is built for its scale and carries ready false with the reason, and the job is re-quoted whole in the quotes server or the delta is invoiced.
Because the two tools take two scales. invoice_create's unit_price is in MAJOR units, 450 for EUR 450.00; quote_create's unit_price_minor is in MINOR units, 45000 for the same price. Both are plain numbers and neither tool can tell it was handed the other one's scale. The suite feeds the 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.
No. change_order_invoice_payload returns invoice_create's arguments and says posted false. You run invoice_create in the invoice server. A tool that did both would bill a customer as a side effect of asking what a change is worth.
Open ones, draft and sent. Approving, rejecting or voiding a change order frees its slot, and change_order_delete on a draft with no lines is free on every tier. contract_value, change_order_get and change_order_list are free and unlimited. A byte-identical change order is refused before the cap is consulted, so a double-typed change burns neither a slot nor a CO number.
No. There is no network call anywhere in this server except the checkout host named in the licensing copy, and the contract suite asserts that. It reads exactly one file it does not own, read-only and best-effort: the shared business profile, for the currency, the default VAT rate and the name on the document. There is no account and no API key, and license keys are verified offline.
All MCP servers and prices · All guides · Buy the bundle $39