Job cards, work orders, delivery schedules, goods receipts and maintenance logs, every one a free remote MCP server you connect by URL: no install, no account. 46 servers in the full suite.
| Server | What it does | Pro |
|---|---|---|
| MCP Job Card | Opens a job card for the client, the site, what the job is, the currency and the scheduled date, returning a JC-YYYY-NNNN id. Labor entries log the hours each worker puts in at their rate and material entries the items that went into the job, each line valued and rounded half-up to the cent once at the moment it is logged and stored on the entry, so the running totals are plain sums of stored line values and can never drift from the lines. Hours are carried as integer hundredths and quantities as integer thousandths, so 2.5 hours at 4,999 cents an hour is 12,498 cents, never 12,497.499999. The status machine moves exactly one step at a time, open to in_progress to done to invoiced to archived, stamping date and note into the card's history, and a skipped or backwards step is refused. job_card_print renders the card with a signature line for client sign-off, as Markdown or self-contained HTML. A card holding labor or materials cannot be deleted, because that card is the record of work done; it is archived instead, and the JC number is never reissued. job_card_summary answers a day or a week: cards touched, hours per worker, labor and materials value per currency, with currencies never added together. | $19 |
| MCP Work Order | Raises a work order against a client the invoice server already knows -- the same client record, not a second spelling of the name -- with a site address, the date it was asked for, what the job is and how urgent. Lines are logged as the job goes: labour as hours at an hourly rate, parts as a quantity at a unit cost in minor units with an optional markup percent. THE MARKUP GOES ON THE UNIT COST, NEVER ON THE LINE TOTAL, because the invoice server rounds a unit price into minor units first and computes the line from that stored value, so the marked-up unit is the only basis an invoice can reproduce: seven parts at 1299 with 15 percent is 1494 a unit and 10,458 on the line, where marking up the line total is 10,457, and the unit suite asserts that gap is exactly 1 so a change of basis fails the build rather than quietly re-pricing every job on the board. The status moves one step at a time, draft to scheduled to in_progress to done to invoiced, each step stamped with its date and a note; a skipped step is refused naming the step that IS next, because every step carries its own date and a job that went straight to invoiced was never marked done, so no completion report was produced and nothing records the day the work finished. Backwards is refused too: a job that has to go back is a new work order. No total is stored -- value, hours, materials and VAT are derived from the lines on every call, because a stored total is the copy that gets believed after somebody edits a line. Hours are counted on the LINE date, not on the order date, so a February call worked in March logs its hours in March. work_order_invoice_payload builds the invoice_create items and then runs the invoice server's own computeTotals over those items, so there is no second implementation to disagree, it posts nothing and marks nothing, and an order already invoiced refuses a second payload by name. An unknown client name with no address is refused, because a bare name that matches no client record is a misspelling far more often than a new customer. A labour rate is never improvised: there is no default rate in the shared profile today, so rate_minor is refused by name rather than invented onto a report the customer signs. | $19 |
| MCP Server for Delivery Schedules — Late Deliverables from Claude | Hold dated deliverables against a quote or work order and see what is late, from Claude. Free MCP server, no install. | $19 |
| MCP Server for Packing Lists — Packing Slips from Claude | Create packing slips and packing lists from Claude with a free MCP server: cartons, contents, weights, chargeable weight and shortfalls. No install. | $19 |
| MCP Server for Goods Receipt Notes (GRN) — Receive Against POs from Claude | Raise goods receipt notes (GRN) against open purchase orders from Claude with a free MCP server. Per-line units received or damaged, three-way match ready. No install. | $19 |
| MCP Server for Maintenance Log — Equipment and Vehicle Service from Claude | Keep an equipment and vehicle maintenance log from Claude with a free MCP server: service events, costs and next-due tracking. No install. | $19 |
| MCP Checklist | Holds a checklist as a named list of steps, optionally grouped into sections, each one required or optional, and runs it against a job as many times as you like. A run marks every step pass, fail or not applicable, with who marked it, on what day, and a note saying what was found, and run_sign_off puts a name and a date on it and freezes it. A RUN COPIES ITS CHECKLIST WHEN IT STARTS, and that one rule decides the whole server: the steps are copied into the run, text and all, with the checklist's version number recorded beside them, so editing the checklist afterwards never changes a run already under way and deleting the checklist leaves every run readable and complete. Without it, editing a checklist rewrites history: a handover certificate signed for ten checks silently becomes a certificate for eleven, and no field anywhere in the record shows that it happened, so no reader could ever detect it. The contract suite asserts it on the raw runs.json bytes and not only through the API. NOT APPLICABLE IS NOT A PASS: na counts as ANSWERED and never as passed, because a step that was looked at and dismissed is a different fact from a step that passed, and merging the two is how a checklist reports full marks for a job where half the steps did not apply. The arithmetic that catches it is that pass plus fail plus na plus pending equals the item count AND answered plus pending equals it too, which only both hold if na sits on the answered side. Nothing derived is stored: the counts, the failures, the outstanding list and whether a run can be signed off are computed on every call, and complete is a READING rather than a claim, appearing when the last step is answered and going away again when one is set back to pending, with each change written to the run's history. Setting a step back to pending clears who answered it and when, because a name against an unanswered step is a false record and it is the kind that survives into a signed document. A required step unanswered or failed blocks the signature and an optional one failing does not, which is the only reason required exists; force signs anyway and the exceptions stay on the record and print on the report under a heading that names them, so a signature taken over an exception is visible rather than lost. Sign-off refuses a closed run on the status machine and an open one on the reasons, because an open run cannot go straight to signed_off is true and useless when what the caller needs is which steps are outstanding. A signed-off run cannot be edited or deleted, because it is the record of what somebody put their name to; an abandoned one is closed but is not a signature and can be deleted. | $19 |
| MCP Change Order | Raises a change order against a quote or a work order, kept the way a variation is kept on site: added, removed and changed lines, each with a quantity, a unit price in minor units, a reason and a date; a status that moves draft to sent, sent to approved or rejected, draft or sent to void, with every step dated and a step dated before the last one refused; and the running contract value as the original plus the deltas the client has APPROVED, with pending draft and sent deltas shown apart and never added in. The original contract value is stated ONCE per reference on the first change order and inherited by every later one, 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 computeTotals, so there is no second implementation to disagree. A CHANGED LINE IS TWO ITEMS, NOT ONE, 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, where 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 roundHalfUp is symmetric in sign. That symmetry is what lets a removal ride 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. Once approved, the delta comes back as invoice_create-ready items in MAJOR units and quote_create-ready items in MINOR units in one call, the scale printed against each, and the unit suite feeds the MINOR figure into the invoice engine as though it were MAJOR and asserts the net is exactly 100x, re-derived from each payload's own items: on the worked change order 11,701,200 against the correct 117,012. Lines are added only while a change order is a draft; a sent one that needs another line is voided and raised again, so the client's approval always refers to what they were sent. A draft cannot be approved directly, because approval is the client's answer to something they were sent. Nothing is invented: a reference with no change order on file has no running value and says so rather than starting from nothing but its own delta. It reads exactly one file it does not own, the shared business profile, read-only and best-effort, and writes into no store but its own. | $19 |
Every server has a free tier that is useful on its own — real limits, not a crippled demo. Pro keys are one-time payments, not subscriptions, when you outgrow them.
Open mcp.zovo.one/mcp/connect, pick a server, paste its URL into your client's MCP config. That is the whole setup.
Work orders and job cards from chat, and why the markup goes on the unit cost · Pricing a job from a rate card, and what to do when the scope changes