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.
In agent mode the one rule an agent must not break is the snapshot: a run copies its checklist's steps when it starts, so editing the checklist afterwards never rewrites a run already under way. Add the forgotten step to the checklist and start a NEW run; do not expect the open one to grow it.
| 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 .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 |
If you also run Claude Desktop, the shortest path there is one click: checklist.mcpb
from the latest release opens as an extension, with no JSON and no terminal.
VS Code reads its own config, so here it is:
// .vscode/mcp.json (the key is "servers")
{
"servers": {
"checklist": {
"command": "node",
"args": ["/absolute/path/to/mcp-servers/servers/checklist/dist/index.js"]
}
}
}
Or from a terminal:
code --add-mcp '{"name":"checklist","command":"node","args":["/absolute/path/to/mcp-servers/servers/checklist/dist/index.js"]}'
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/checklist
That 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:
code --add-mcp '{"name":"checklist","command":"npx","args":["-y","@theluckystrike/mcp-checklist"]}'
VS Code asks you to confirm you trust the server and its capabilities before it starts. Nothing runs until you answer.
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.
{
"servers": {
"checklist": {
"url": "https://mcp.zovo.one/mcp/checklist",
"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: 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.
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 Checklist in detail · The same server in Cursor and Windsurf · Every server in VS Code · Guides · VS Code docs · Buy Pro
Work orders and job cards from chat, and why the markup goes on the unit cost