
Onboarding Checklist Inspection Runs
io.github.theluckystrikePublished by GitHub account theluckystrikev0.22.6Updated Oct 24, 2026
Onboarding and inspection checklists you reuse: dated runs, who ticked what, and a sign-off.
Overview
A local MCP server for reusable onboarding and inspection checklists, with dated runs, per-step pass/fail records and a frozen sign-off.
- What you can do
- Create, list, show and delete reusable checklists, and add or remove steps grouped into sections and marked required or optional, with version bumps on edits. Start dated runs against a job, which copy the checklist's steps at that moment. Mark each step pass, fail or not applicable with who, when and a note. Review runs with counts, failures and what blocks sign-off, and filter runs by checklist, status, reference or failures. Sign off a run to freeze it, reopen or abandon runs, and produce a text report, optionally written to a file on Pro.
- When to use it
- Useful when you repeat the same checks across jobs and need a defensible record of what was checked, by whom and when, such as pre-delivery checks, handover sheets or snag lists. The snapshot rule keeps signed runs matching the list the signer actually saw.
- Requirements
- Runs as a local process on the user's machine, installed as a one-click .mcpb bundle in Claude Desktop or configured in an MCP client; the npm package is not yet published, so building from source is the current alternative. No account, API key or network access is needed. An optional Pro license key is supplied through the MCP_LICENSE_KEY environment variable.
Installation
In SourceWeft
- Open Onboarding Checklist Inspection Runs in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
mcp-checklist
[theluckystrike/mcp-checklist MCP server]
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.
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):
Claude Code
Cursor
~/.cursor/mcp.json (global) or .cursor/mcp.json (project), same entry as Claude Desktop.
Tools
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
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: [email protected]
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
Source: servers/checklist/README.md at commit 6535b33
Tools
0Version history
3- v0.22.6LatestOct 14, 2026
- v0.22.3Sep 23, 2026
- v0.21.0Sep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts