io.github.theluckystrikePublished by GitHub account theluckystrikev0.23.0Updated Nov 3, 2026
Receive goods against purchase orders: partial, damaged or short units, and each order's status.
McpStamp Goods Receipt's hosted MCP server (mcp.zovo.one); no sign-in required; Streamable HTTP; 11 tools.
No AI overview yet: these facts come from the registry entry and the server itself.
Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.
Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.
Read https://sourceweft.com/mcp/io.github.theluckystrike%2Fgoods-receipt/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.Add this to your client's mcpServers config.
{
"mcpServers": {
"mcpstamp-goods-receipt": {
"type": "http",
"url": "https://mcp.zovo.one/mcp/goods-receipt"
}
}
}[theluckystrike/mcp-goods-receipt MCP server]
In the official MCP Registry (io.github.theluckystrike/goods-receipt).
Purchase orders and the goods-receipt notes that receive them. A PO carries a reference, a supplier, and dated lines - sku, description, whole units ordered - plus whole-percent over/under tolerances that decide when a receipt is flagged. A GRN is raised against an open PO, one cell per line: units received, units damaged, and any shortage you already know about. Shortage is derived, not typed - ordered minus received, floored at zero - and shows up as a discrepancy the moment the numbers disagree.
Over-tolerance is checked against the cumulative total across every GRN raised on the line, not against each delivery in isolation.
Three deliveries of 40 against an order of 100 at 10% are allowed in ones and tens but the third delivery is refused, because 120 received of 100 ordered breaks the over tolerance even though no single delivery did. Partial deliveries are fine - several GRNs against the same PO is the normal case - and the cumulative rule is what stops them quietly over-receiving.
Two smaller rules follow from it:
Ids look like PO-0001 and GRN-0001; lines inside a PO are L01, L02, ….
A GRN that arrives past the over tolerance is refused; shortage is computed as ordered minus
received and shown as a discrepancy. grn_export_csv (Pro) writes the whole ledger out as CSV.
The domain is capped estate-wide (2,000 POs, 5,000 GRNs, 200 lines) on every tier - these are hard rules so a store cannot grow past what the file format can hold, not a paywall. Pro unlocks CSV export for pushing receipts into a spreadsheet or an ERP.
Get Pro: https://mcp.zovo.one/buy/goods-receipt (one-time), or all servers for one price at https://mcp.zovo.one/buy/bundle
All data stays local, in ${XDG_DATA_HOME:-~/.local/share}/mcp-servers/goods-receipt/, in
store.json (POs and GRNs) and counter.json (the PO- and GRN- series). There is no network
call anywhere in this server, no API key, and no account. The only file it reads that it does
not own is the shared business profile, and it never writes to it.
Built by theluckystrike. Support: [email protected]
Any MCP client (Claude, Cursor, Windsurf, VS Code) can read this repository's documentation directly via GitMCP - no install:
Source: servers/goods-receipt/README.md at commit 55b3f42
Add a purchase order
Create a purchase order to receive goods against. Lines carry a sku, a description and an ordered whole-unit quantity. Over/under tolerances are whole percentages allowed above/below ordered before a GRN is flagged. Ids look like PO-0001. Free tier, full CRUD.
linesrequiredsupplierrequiredreferencerequiredoverTolerancePctunderTolerancePctReceive goods against a purchase order
Create a goods-receipt note (GRN) against an open purchase order. Give one cell per PO line: the whole units received and/or damaged. received is checked against the line's ordered quantity and the PO's over tolerance; receiving past the over tolerance is refused unless declared damaged. Shortage is recorded automatically (ordered minus received, floored at zero) and shown as a discrepancy. Partial deliveries are fine: raise several GRNs against the same PO. Free tier, full CRUD.
porequirednotelinesrequiredcarrierreceivedAtAdd a line to an open GRN
Add another PO line (or more units on a line already open on this GRN) to an existing open goods-receipt note. Useful when one delivery arrives in batches. The over-tolerance gate still applies to the PO line's cumulative received count across every GRN. Free tier, full CRUD.
grnrequiredlinerequireddamagedreceivedrequireddamageNoteshortageNoteList goods-receipt notes
List goods-receipt notes, newest first, optionally filtered to one purchase order.
poincludeLinesGet one goods-receipt note
Get a single goods-receipt note by id, with its lines, damage and shortage per line.
grnrequiredList discrepancies
List lines that are not as ordered: damaged units, a declared shortage, or received below the PO line's under tolerance. Optionally filter to one PO.
poincludeResolvedClose a goods-receipt note
Close an open GRN. A closed GRN can no longer take lines, and its discrepancies are treated as resolved. Closing is free-tier and never mutates the PO.
grnrequiredGoods-receipt status report
Reconcile every purchase order against every GRN: open POs (not yet fully received), POs fully received within tolerance, POs with at least one discrepancy, and per-line open/short/damaged counts. Nothing is written.
includeOnlyDiscrepanciesExport goods receipts as CSV
Pro. Export every GRN (or just one PO's GRNs) as CSV with a header row: grn,po,po_reference,received_at,carrier,status,line,sku,received,damaged,shortage,damage_note,shortage_note. Watermark-free and not truncated.
poLicense status
Report this endpoint's licence state for your token as JSON: the product, the tier free or pro, why it is not Pro, and the checkout URL. Call it to explain a free-tier refusal. No arguments, nothing changes.
Takes no parameters.
Activate license
Turn Pro on for this connection with key, an MCPL1.<payload>.<signature> issued at checkout for this server or the bundle. Data under your token stays; a wrong or expired key changes nothing. license_status confirms it.
keyrequired100% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
po_add { "reference": "ACME-1001", "supplier": "Acme Trading", "lines": [ { "sku": "BRK-8", "description": "Bracket, steel", "ordered": 100 } ] }grn_add { "po": "PO-0001", "lines": [ { "line": "L01", "received": 60 } ] }grn_add { "po": "PO-0001", "lines": [ { "line": "L01", "received": 35, "damaged": 2 }, { "line": "L01", "received": 10 } ] } // refused: 105 > 100 + 10%grn_discrepancy {} // L01 is 5 short of 100{ "tool": "po_add", "args": { "reference": "ACME-1005", "supplier": "Acme Trading", "lines": [{ "sku": "BRK-01", "description": "Bracket, steel", "ordered": 10 }] } }{ "tool": "grn_add", "args": { "po": "PO-0001", "lines": [{ "line": "L01", "received": 9, "damaged": 1 }] } }{ "tool": "grn_discrepancy", "args": { "po": "PO-0001" } }