mcp-checklist
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| checklist_createA | 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. |
| checklist_item_addA | 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. |
| checklist_item_removeA | 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. |
| checklist_showA | 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. |
| checklist_listA | 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. |
| checklist_deleteA | 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. |
| run_startA | 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. |
| run_checkA | 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. |
| run_showA | 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. |
| run_listA | 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. |
| run_sign_offA | 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. |
| run_statusA | 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. |
| 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. |
| run_deleteA | 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. |
| license_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. |
| license_activateA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| run_the_checklist | Pick or build the checklist, start a dated run against a job, answer every step with who and when, and sign it off with the exceptions on the record. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| contract | Why a run copies its checklist, the four item states and what na means, the run status machine, what blocks a sign-off, the free-tier limits and the one directory this server writes. |
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.