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.
run_status, run_list and run_report as text are free, unlimited and write nothing, so leave them enabled permanently and read progress as often as you like. run_sign_off is the one to reach for deliberately: a signed-off run cannot be edited or deleted, and force signs over an exception with the exception printed on the report rather than lost.
| 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 .cursor/mcp.json, and the key inside it is mcpServers.
| Scope | Path |
|---|---|
| This project only | <project>/.cursor/mcp.json |
| Every project | ~/.cursor/mcp.json |
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.
Cursor reads its own config, so here it is:
The config block:
{
"mcpServers": {
"checklist": {
"type": "stdio",
"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/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"]
}
}
}The Customize page shows the server and its tools once it has started.
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>" }
}
}
}The current field table marks `type` as required, with `stdio` for a locally launched server, so write it out rather than relying on command and args alone. The other documented restriction is that `envFile` is stdio-only: a remote HTTP or SSE server does not read it, and its headers belong in the config.
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.
<project>/.cursor/mcp.json applies to that project and can be committed, which suits a server tied to one client. ~/.cursor/mcp.json applies everywhere. Both are managed from the Customize page.
The current field table marks type as required, with stdio for a locally launched server, so include it. Pointing at a remote endpoint, envFile is documented as stdio-only and is not read.
Servers in Cursor's marketplace get an Add to Cursor button. The deeplink reference currently documents prompt, command and rule links only, so for MCP Checklist pasting the config block above is the supported route.
MCP Checklist in detail · The same server in Claude Code and VS Code · Every server in Cursor · Guides · Cursor docs · Buy Pro
Work orders and job cards from chat, and why the markup goes on the unit cost