mcp-checklist
Build reusable checklists and run them as dated, signed records with pass/fail/not-applicable answers and reports.
Create, list, show, and delete reusable checklists with categories and descriptions.
Add or remove steps, group them by section, and mark steps required or optional.
Start dated runs that copy the checklist steps so later edits do not change existing runs.
Mark steps pass, fail, na, or pending, with who, when, and notes.
View and filter runs, including open runs, status, reference, and failures.
Sign off runs with a name and date, optionally forcing past exceptions.
Reopen complete runs or abandon runs that did not happen.
Generate plain-text run reports; Pro can also write reports to a file.
Delete unsigned runs, while signed-off runs are protected.
Check and activate a Pro license offline.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@mcp-checklist Create a checklist for weekly server maintenance tasks"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
mcp-checklist
MCP server for reusable checklists and dated runs of them: pass, fail, not applicable, and a sign-off. Checklists you build once and run many times, and the dated record of each run that somebody signs.
Works with Claude Desktop, Claude Code, Cursor and any Model Context Protocol client. Runs on your own machine, or hosted with no install.
Product page: https://mcp.zovo.one/s/checklist - what it does, the tools it exposes, and a live token endpoint.
Install
Hosted, nothing to install. Get a token from https://mcp.zovo.one/mcp/connect (the connect page) or https://mcp.zovo.one/mcp/token (the same token as JSON); a free anonymous one is issued on the spot and a Pro key works the same way. Then point an MCP client at https://mcp.zovo.one/mcp/checklist over streamable-http and send the token as Authorization: Bearer <token>.
If your client cannot set headers, put the token in the path instead: https://mcp.zovo.one/mcp/checklist/t/<token>. Both forms work. The bare URL with no token answers 401 on tools/call, so the token is not optional.
Claude Desktop, one click. Download checklist.mcpb from the latest release and double-click it.
From source. The mirror is self-contained: every @theluckystrike/* dependency is vendored, so a fresh clone builds with no extra setup.
git clone https://github.com/theluckystrike/mcp-checklist.git
cd mcp-checklist
npm install && npm run buildThen point your client at the built entry point:
{
"mcpServers": {
"checklist": {
"command": "node",
"args": ["/absolute/path/to/mcp-checklist/dist/index.js"]
}
}
}
@theluckystrike/mcp-checklistis not published on npm yet, so annpx -y @theluckystrike/mcp-checklistcommand will fail. The three paths above are the working ones and each is exercised by CI.

Read-only mirror of mcp-servers/servers/checklist. See MIRROR.md.
In the official MCP Registry (io.github.theluckystrike/checklist).
Checklists you build once and run many times, and the dated record of each run that
somebody signs. A checklist is a named list of steps, optionally grouped into sections, each
one required or optional. A run is one pass of that checklist against a job: every step is
marked pass, fail or not applicable, with who marked it and on what day, and a note that
says what was found. run_sign_off then puts a name and a date on it and freezes it.
Related MCP server: loopgrid-mcp
The one rule that decides everything else
If somebody edits the checklist afterwards, adds a step or deletes one, every run already in progress keeps the list it started with, and the version it was copied from is recorded on the run.
That is not a caching convenience. A checklist somebody ticked and signed has to be the list they actually saw. A run that read its steps live from the checklist would mean a signed handover certificate for eleven checks when the person signing it saw ten, with no field in the record showing that it had happened. It also means deleting a checklist leaves its runs readable and complete, which is what you want the year afterwards when somebody asks what was checked.
Two smaller rules follow from it:
Nothing derived is stored. The pass, fail and outstanding counts, the percentage, and whether a run can be signed off are worked out on every call from the run's own steps. A stored "complete" flag is a fact about the afternoon somebody last looked, and
completehere is a reading: it appears when the last step is answered and goes away again when one is put back to pending.Not applicable is not a pass.
nacounts as ANSWERED and never as passed. A step that was looked at and dismissed is a different fact from a step that passed, and merging the two is how a checklist reports full marks for a job where half the steps did not apply.
What blocks a signature
A required step that is unanswered, a required step that failed, an unanswered optional
step, or a run with no steps. force: true signs anyway, and the exceptions stay on the
record and print on the report under "Signed with exceptions". They are not lost, and they
are not silent.
Install
One-click (.mcpb): download checklist.mcpb from the latest release and double-click it
in Claude Desktop: https://github.com/theluckystrike/mcp-servers/releases/latest
npm publish for @theluckystrike/mcp-checklist is pending, so the npx line below returns
404 today. Build from source in the meantime; see llms-install.md.
Claude Desktop
~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or
%APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"checklist": {
"command": "npx",
"args": ["-y", "@theluckystrike/mcp-checklist"]
}
}
}Claude Code
claude mcp add checklist -- npx -y @theluckystrike/mcp-checklistCursor
~/.cursor/mcp.json (global) or .cursor/mcp.json (project), same entry as Claude Desktop.
Tools
Tool | What it does |
| Create a reusable checklist: a name, a category, a description |
| Add a step: the text, a section heading, and whether it is required |
| Remove a step and bump the version. Runs already under way keep it |
| One checklist, grouped by section, with a blank printable copy on request |
| Every checklist with its version, step count and how many runs came from it |
| Delete a checklist. Its runs stay readable, because each carries its own copy |
| Start a dated run against a job. The steps are copied into it at this point |
| Mark one step pass, fail or na, with who and when and what was found |
| The run: every step with its answer, the counts, the failures, and what blocks sign-off |
| Runs newest first, filtered by checklist, status, reference, or only those with failures |
| Sign off with a name and a date, which freezes the run |
| Reopen a complete run, or abandon one when the job did not happen |
| The run as text on every tier. Pro also writes it to |
| Delete a run. A signed-off one is refused |
| Which tier this install is on and where the key came from |
| Store a Pro key for this server |
There is also a resource, checklist://contract, carrying the snapshot rule, the item
states, the run status machine, what blocks a sign-off and where this server writes; and a
prompt, run_the_checklist, that walks the whole job in order.
Free vs Pro
Free | Pro | |
Checklists you keep | 3 | unlimited |
Runs of them | unlimited | unlimited |
Steps per checklist | up to 500 | up to 500 |
| yes | yes |
The run report as text | yes | yes |
Writing the report to a file with | no | yes |
The meter is on how many DIFFERENT checklists you keep, not on how many jobs you check. A trade with one pre-delivery check, one handover sheet and one snag list runs its whole year inside the free tier. Runs are never capped, because capping the running of a checklist would cap the only thing a checklist is for. Deleting a checklist frees a slot.
Get Pro: https://mcp.zovo.one/buy/checklist (one-time), or all servers for one price at https://mcp.zovo.one/buy/bundle
Privacy
All data stays local, in ${XDG_DATA_HOME:-~/.local/share}/mcp-servers/checklist/. There is
no network call anywhere in this server, no API key, and no account. The only file it reads
that it does not own is the shared business profile, for the name and address at the top of a
printed report, and it never writes to it.
Built by theluckystrike. Support: support@zovo.one
Use these docs as an MCP server
Any MCP client (Claude, Cursor, Windsurf, VS Code) can read this repository's documentation directly via GitMCP - no install:
Docs MCP URL: https://gitmcp.io/theluckystrike/mcp-checklist
Available Tools
16 toolschecklist_createCreate a checklistA
Create a reusable checklist and return its CL-NNNN id: a name, a category and an optional description. Add the steps with checklist_item_add. Free tier: 3 checklists, and unlimited runs of them.
Inputs: name (required), category, description.
checklist_deleteDelete a checklistA
Delete a checklist and its steps for good. Runs already started from it are untouched and stay readable: a run carries its own copy of the steps, so deleting the checklist does not erase what anybody signed.
Inputs: confirm (required), checklist (required).
checklist_item_addAdd a step to a checklistA
Add one step to a checklist and return its I01-style id: the text, an optional section heading, and whether it is required. A required step that is unanswered or failed blocks sign-off; an optional one does not.
Inputs: text (required), checklist (required), note, section, +2 more.
checklist_item_removeRemove a step from a checklistA
Remove one step from a checklist by its I01-style id and bump the checklist version. Runs already under way keep the step they started with, so nothing anybody already ticked is rewritten.
Inputs: item (required), checklist (required).
checklist_listList checklistsA
Every checklist with its category, version, step count and how many runs came from it. Filter by category or by a word in the name. Returns at most 500 rows, newest change first.
Inputs: category, contains.
checklist_showShow one checklistA
One checklist with its steps in order, grouped by section, plus how many are required and how many runs have been started from it. Pass as_text for a blank printable copy with a box against each step.
Inputs: checklist (required), as_text.
license_activateActivate licenseA
Activate a Pro key (MCPL1.xxx.yyy) from checkout: verified offline against a built-in public key, saved to your config file. A wrong, malformed or expired key is refused, unsaved. license_status reads it back.
Inputs: key (required).
license_statusLicense statusA
Report this server's licence state: product, tier free or pro, licence id, expiry, the key source and the upgrade URL. No arguments, no network. Explains a free-tier refusal; license_activate installs a key.
Inputs: no named parameters.
run_checkAnswer a step in a runA
Mark one step pass, fail or na, with who did it and when. na means the step did not apply; it counts as answered and never as passed. A step can be answered again while the run is open, and the last answer stands.
Inputs: run (required), item (required), state (required), at, +2 more.
run_deleteDelete a runA
Delete a run for good, with every answer on it. A signed-off run is refused: it is the record of what somebody put their name to. Abandon a run you no longer want instead of deleting a signed one.
Inputs: run (required), confirm (required).
run_listList runsA
Runs newest first, with their checklist, progress and sign-off state. Filter by checklist, by status, by reference or to open runs only. Returns at most 500 rows.
Inputs: status, checklist, open_only, reference, +1 more.
run_reportProduce the run reportA
The run as plain text on every tier: every step with its mark, who answered it, the notes, the counts and a signature block or the recorded signature. Pro also writes it to out_path as a .txt file.
Inputs: run (required), out_path, overwrite.
run_showShow one runA
The whole run: every step with its answer, who answered it and when, grouped by section, plus the pass, fail and outstanding counts, the failures in full, and whether it can be signed off and why not.
Inputs: run (required).
run_sign_offSign off a runA
Sign off a completed run with a name and a date, which freezes it. Refused while a required step is unanswered or failed, unless force is true, and either way the exceptions stay on the record and print on the report.
Inputs: by (required), run (required), date, note, +1 more.
run_startStart a run of a checklistA
Start a dated run of a checklist and return its RUN-YYYY-NNNN id. The steps are COPIED into the run, so editing the checklist afterwards never changes a run already under way. Runs are free and never capped.
Inputs: title (required), checklist (required), date, note, +1 more.
run_statusReopen or abandon a runA
Move a run back to open so a step can be answered again, or abandon it when the job did not happen. A signed-off run is refused: a signature is the point at which a run stops moving.
Inputs: run (required), status (required), date, note.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 16 tools
Checklist management tools (create, item_add/remove/show/list/delete) and run tools (start/check/show/list/sign_off/status/report/delete) are clearly separated by prefix. Minor potential confusion between run_show and run_report, but their descriptions clarify different purposes (run_show is a detailed view, run_report a printable export).
All tools follow a clear verb_form pattern: license_status/activate, checklist_create/item_add/remove/show/list/delete, run_start/check/show/list/sign_off/status/report/delete. Naming is consistent, predictable, and uses actions that align with the resource lifecycle.
16 tools is well-scoped for a checklist management server covering both template lifecycle and run lifecycle. Each tool has a distinct role, with no redundancy; the count is appropriate for the domain complexity.
The server provides complete coverage: create, read, update (via item_add/remove), delete for checklists; start, check, show, list, sign-off, status change, report, delete for runs. Edge cases like abandoning runs and handling signed-off runs are addressed, leaving no obvious gaps in the workflow.
Maintenance
Related MCP Connectors
Reusable checklists with dated runs: pass, fail or N/A per step, then a frozen sign-off.
Purchase requisitions as reusable step lists: dated runs, pass or fail per step, and sign-off.
Save checklists to a MyCheck account and check the status of the USCIS cases you track.
CheckFlow’s own MCP server. Ask your AI assistant to start checklists, complete tasks, fill in fields, build templates from written procedures and update Data Sets in CheckFlow. Sign in with your CheckFlow account, or use an API key.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables spec-driven development acceptance gate with structured receipts, audit logs, and reviewer-ready evidence.-
- AlicenseAqualityBmaintenanceEnables MCP-compatible hosts to record, retrieve, and verify LoopGrid decision evidence through tools for decisions, reviews, actions, outcomes, and verification.617 PyPIApache 2.0
- AlicenseNot gradedqualityBmaintenanceEnables deliverable conformance and evidence-chain checks by turning requirements into executable specs, validating numbers against a provenance ledger, and auditing PDF/OOXML metadata and archive manifests.29 npm1MIT
- AlicenseAqualityBmaintenanceEnables HR and managers to create role-based task templates, turn them into dated checklists per new hire, track task owners and due dates, and sign off with a preserved record.959 npmMIT