Home · Setup · Claude Desktop
Checklists you build once and run many times, and the dated record of each run that somebody signs. You hold a checklist as a named list of steps, optionally grouped into sections, each required or optional, and run 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's steps when it starts and records the version it copied, so editing the checklist afterwards never changes a run already under way and deleting the checklist leaves every run readable and complete. Not applicable counts as answered and never as passed: 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. A required step unanswered or failed blocks the signature; force signs anyway and the exceptions stay on the record and print on the report. No count is stored: every figure is derived on the call, and a signed-off run cannot be edited or deleted, because it is the record of what somebody put their name to.
The run is usually reported from wherever the job was, and this is the client people open to record it: run_check takes the step, the state and who marked it in one sentence, and run_sign_off at the end is the same window. Nothing leaves the machine: there is no network call in the server on any tool.
| You say | Tool |
|---|---|
| Make a pre-delivery vehicle check: tyre pressures, lights, load secured, weight within the plated limit. | checklist_create then checklist_item_add |
| Start a run for van BX21 KLM against WO-2026-0044. | run_start |
| Ben found the load at 3620 kilos against a plated 3500, that one fails. Can I sign it off? | run_check then run_sign_off |
On the worked pre-delivery run the steps answer pass, pass, na, pass, fail, pending: five of six answered, three pass, one fail, one not applicable, one pending. That run is not signable on two counts, a required step failed and an optional one is unanswered, and run_sign_off says both rather than only that the run is open. The contract suite asserts the snapshot rule on the raw runs.json bytes, not only through the API.
The file is claude_desktop_config.json, and the key inside it is mcpServers.
| Scope | Path |
|---|---|
| macOS | ~/Library/Application Support/Claude/claude_desktop_config.json |
| Windows | %APPDATA%\Claude\claude_desktop_config.json |
One click, with no JSON. Download checklist.mcpb from the
latest release and open it. Claude Desktop installs it as an extension and runs
it on the Node runtime it ships with, so neither your PATH nor your node version comes into it, and there
is no file to edit. Everything below is the manual route, for when you want the entry in the config file
itself.
The config block, which needs both strings absolute:
{
"mcpServers": {
"checklist": {
"command": "node",
"args": ["/absolute/path/to/mcp-servers/servers/checklist/dist/index.js"]
}
}
}If node came from nvm, asdf or homebrew, use the absolute path that which node prints
rather than the bare word, because a stdio server started by this app inherits a limited PATH:
"command": "/Users/you/.nvm/versions/node/v22.14.0/bin/node"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/checklistThat writes servers/checklist/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": {
"checklist": {
"command": "npx",
"args": ["-y", "@theluckystrike/mcp-checklist"]
}
}
}Save, then completely quit Claude Desktop and start it again. A window reload is not enough.
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.
The same server runs at https://mcp.zovo.one/mcp/checklist 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.
{
"mcpServers": {
"checklist": {
"url": "https://mcp.zovo.one/mcp/checklist",
"headers": { "Authorization": "Bearer <token>" }
}
}
}Two documented facts decide whether the entry works: every path in claude_desktop_config.json must be absolute, and a stdio server started here inherits only a limited, platform-dependent subset of environment variables. If node came from nvm or homebrew, paste what `which node` prints instead of the bare word. The .mcpb route avoids both: Claude Desktop ships a built-in Node.js environment.
Free: Three checklists, and unlimited runs of them on every tier, because capping the running of a checklist would cap the only thing a checklist is for. Up to 500 steps on a checklist on every tier. Every read, every count, the failures, the outstanding list and the run report text are free, and deleting a checklist frees its slot. Pro is $19 once, verified offline.
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json. Windows: %APPDATA%\Claude\claude_desktop_config.json. There is no published Linux path. Settings, Developer, Edit Config opens the right copy and creates it if it does not exist.
In order: did you fully quit and restart, not just close the window? Is every path absolute? And is the command resolvable, given the limited environment a stdio server inherits here? If node came from nvm, paste what which node prints.
Yes. An .mcpb bundle, the format renamed from .dxt, opens with Claude and shows an installation dialog. One you built yourself goes in through Settings, Extensions, Advanced settings, Install Extension.
MCP Checklist in detail · The same server in Claude.ai and Claude Desktop connectors and Claude Code · Every server in Claude Desktop · Guides · Claude Desktop docs · Buy Pro
Work orders and job cards from chat, and why the markup goes on the unit cost