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.
Sixteen tools against Cascade's ceiling of 100, and it pairs naturally with mcp-work-order, whose ids a run's reference carries, and with mcp-delivery-schedule, whose acceptances a handover checklist backs; budget the three at roughly 40 tools when you decide what else fits alongside them.
| 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 mcp_config.json, and the key inside it is mcpServers.
| Scope | Path |
|---|---|
| macOS, Windows and Linux | ~/.codeium/windsurf/mcp_config.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.
Windsurf reads its own config, so here it is:
The config block:
{
"mcpServers": {
"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/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 and reopen the MCP Servers list; Cascade picks it up without restarting the editor.
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>" }
}
}
}Read this first: mcp_config.json applies to the legacy Cascade agent only. The Devin Local agent, the default for new tabs, takes its servers from the Devin CLI config files, so a correct entry here can still be invisible in a fresh tab. The other hard number is a cap: Cascade reaches at most 100 tools at once, and every enabled server spends from it.
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.
~/.codeium/windsurf/mcp_config.json, under mcpServers. Reach it from the MCPs icon at the top right of the Cascade panel, or Devin Settings, Cascade, MCP Servers.
That file applies to the legacy Cascade agent only. The Devin Local agent, the default for new tabs, reads its servers from the Devin CLI config files instead. Check which agent the tab runs.
Cascade reaches at most 100 tools at any one time, and every enabled server spends from that single budget. MCP Checklist contributes 16 tools, so keep the enabled list short rather than counting servers.
MCP Checklist in detail · The same server in VS Code and Cline · Every server in Windsurf · Guides · Windsurf docs · Buy Pro
Work orders and job cards from chat, and why the markup goes on the unit cost