Record a sale of equipment, a vehicle or stock and get a printable bill of sale with signature lines. You tell it who sold, who bought, what the item is, with the VIN, serial number or IMEI where it has one, the price in whole minor units and the date, and it writes the document: parties, item, price, an as-is clause for second-hand sales, any warranty in your own words, and signature lines for both sides. A sale starts as a draft you can revise and delete; sale_finalize freezes it into the signing copy, and from there sale_update refuses it and every render prints without the DRAFT watermark that marks a review copy. sale_render prints Markdown or a single self-contained HTML file that prints to PDF from any browser with no assets beside it. A VIN that is not 17 characters or an IMEI that is not 15 digits is stored as given but flagged in the response. A byte-identical repeat sale is refused before the free cap is consulted and names the id already stored. A finalized document needs confirm_finalized to delete, and the BOS number is never reissued, so a gap in the series is the record of a deletion. The seller defaults to the shared business profile's name, so the seller block is typed once for the whole suite.
sale_list, sale_get, sale_summary and sale_render are reads plus a file write inside the server's own documents folder, and are safe to auto-approve. Keep sale_finalize behind a click, because it freezes the document, and keep sale_render with an explicit out_path behind one, because an occupied path is refused unless overwrite is passed. Nothing here writes into another server's store.
| You say | Tool |
|---|---|
| Record a sale: Kowalski Transport buys my 2019 Ford Transit, VIN WF0XXXTTGXKC12345, EUR 18,500, as-is, dated 2026-03-10. | sale_create |
| Print the draft so they can read it before signing. | sale_render |
| They signed. Finalize it and give me the signing copy as HTML. | sale_finalize then sale_render |
Every amount is an integer number of minor units, a price is never a float, and dates are checked as real calendar dates. The smoke suite drives the whole lifecycle over real stdio: create, get, update, render with the DRAFT watermark, finalize, render the signing copy, the refusal of edits after finalize, the summary, the delete, and then the free caps on drafts and finalized documents and the same calls passing in Pro.
The file is mcp.json, and the key inside it is mcpServers.
| Scope | Path |
|---|---|
| Cline CLI | ~/.cline/mcp.json |
| The editor extension | opened from the Cline panel, not by path; the documentation deliberately calls it the MCP settings JSON used by the extension |
If you also run Claude Desktop, the shortest path there is one click: bill-of-sale.mcpb
from the latest release opens as an extension, with no JSON and no terminal.
Cline reads its own config, so here it is:
The config block:
{
"mcpServers": {
"bill-of-sale": {
"command": "node",
"args": ["/absolute/path/to/mcp-servers/servers/bill-of-sale/dist/index.js"],
"disabled": false,
"autoApprove": []
}
}
}
The node command above wants a built file. From a clone, once:
git clone https://github.com/theluckystrike/mcp-servers.git
cd mcp-servers && npm install
npm run build -w packages/mcp-license -w servers/bill-of-sale
That writes servers/bill-of-sale/dist/index.js, and its absolute path is the one argument
the config needs.
The npm packages are not published yet, so the form below returns a 404 today. It is here because it is what the entry becomes the day the publish lands, with nothing else changed:
{
"mcpServers": {
"bill-of-sale": {
"command": "npx",
"args": ["-y", "@theluckystrike/mcp-bill-of-sale"]
}
}
}
No full-app restart. The MCP settings actions include restarting an unresponsive server if its tools do not appear.
Nothing is published to npm yet, so the working install paths are the ones above: the .mcpb bundle from the latest release, a clone and build, or the hosted URL.
There is no hosted endpoint for this one yet. MCP Bill of Sale runs locally over stdio with the config above, which is also the only form in which it reads and writes files on your own disk. Thirty of the servers in this collection are served at https://mcp.zovo.one/mcp/<name> over MCP streamable HTTP; https://mcp.zovo.one/mcp/connect lists them and prints a ready URL for each.
Cline is the one client here with an unsafe transport default. `type` selects it, and omitting `type` falls back to the legacy sse transport, so a streamable HTTP endpoint needs it written in or you will debug a server that is fine. Local entries carry "disabled" and an "autoApprove" array.
Free: Ten open drafts and five finalized documents, with rendering to Markdown and HTML, listing, reading, the summary and deleting all free and unlimited on every tier. The document itself is never metered: whether you hold a signed record of the sale is the question this server exists to answer, and a free tier that withholds the document is a demo. Pro is $19 once, verified offline.
The CLI reads ~/.cline/mcp.json. For the extension, do not hunt for a path: MCP Servers icon, Configure tab, Configure MCP Servers. cline mcp opens a wizard, and cline config mcp --json is the non-interactive form.
Set the transport explicitly. Omitting type falls back to the legacy sse transport, so streamable HTTP needs "type": "streamableHttp" written in. It is the one default here that sends you debugging a server that works.
Approve the read-only ones and leave the writing ones behind a click: each entry carries an autoApprove array and a disabled flag.
MCP Bill of Sale in detail · The same server in Windsurf and Claude.ai and Claude Desktop connectors · Every server in Cline · Guides · Cline docs · Buy Pro