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.
In agent mode change_order_invoice_payload is a pure derivation that posts nothing: it returns the invoice_create arguments in MAJOR units and the quote_create arguments in MINOR units together and says posted false. Two things an agent must not simplify here. The scale, because the same delta is exactly 100x apart in the two payloads and both fields accept the other one's number without complaint, so take the payload named for the tool you are about to call and change no number in it. And the item count, because a changed line comes back as a reversal and a revised line rather than one net item, and collapsing them to one figure hands the customer a number they cannot check.
| 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 .vscode/mcp.json, and the key inside it is servers.
| Scope | Path |
|---|---|
| This workspace | <workspace>/.vscode/mcp.json |
| Every workspace | the user profile mcp.json, opened by the MCP: Open User Configuration command |
// .vscode/mcp.json (the key is "servers")
{
"servers": {
"change-order": {
"command": "npx",
"args": ["-y", "@theluckystrike/mcp-change-order"]
}
}
}Or from a terminal:
code --add-mcp '{"name":"change-order","command":"npx","args":["-y","@theluckystrike/mcp-change-order"]}'VS Code asks you to confirm you trust the server and its capabilities before it starts. Nothing runs until you answer.
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.
{
"servers": {
"change-order": {
"url": "https://mcp.zovo.one/mcp/https://mcp.zovo.one/mcp/change-order",
"headers": { "Authorization": "Bearer <token>" }
}
}
}The top-level key is "servers", not "mcpServers". A config pasted from a Claude Desktop or Cursor README parses cleanly, contributes no servers, and gives you no error to read, which makes it the most expensive one-word mistake here. Alongside it an "inputs" array holds secrets. The newer Agent Host reads a workspace .mcp.json instead.
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.
The key is servers, not mcpServers. A config copied from a Claude Desktop README parses cleanly and contributes nothing. Rename it. On the newer Agent Host, use a workspace .mcp.json instead.
No. code --add-mcp takes the server object on the command line, and MCP: Add Server in the palette asks whether the target is Workspace or Global.
In Chat, behind the tools picker, once the server has started. Adding or changing one raises a prompt asking you to confirm you trust it; if the picker is empty, that prompt is usually still waiting.
MCP Change Order in detail · The same server in Cursor and Windsurf · Every server in VS Code · Guides · VS Code docs · Buy Pro