Purchase Requisition

io.github.theluckystrikePublished by GitHub account theluckystrikev0.22.8Updated Oct 24, 2026

Reusable purchase-requisitions and dated runs of them: pass, fail, not applicable, and a sign-off.

Overview

AI-generated overview

A local MCP server for reusable purchase-requisition checklists and dated, signed runs of them, with pass, fail and not-applicable answers.

What you can do
Create, list, show and delete reusable checklists, adding or removing steps grouped into sections with required or optional flags, each change bumping the version and leaving existing runs untouched. Start a dated run against a job, which copies the checklist steps into it at that moment. Mark each step pass, fail or not applicable with who, when and what was found. Show and list runs with counts, failures and what blocks sign-off, filtered by checklist, status, reference or failures only. Sign off a run with a name and date to freeze it, reopen or abandon a run, and produce a text report. Check license tier and activate a Pro key.
When to use it
Useful when you want an assistant to keep inspection, handover or snag checklists and record each dated run with a sign-off, for example pre-delivery checks or handover sheets. The free tier covers up to three different checklists with unlimited runs.
Requirements
Runs as a local process on the user's machine, installed as a one-click .mcpb bundle in Claude Desktop or built from source; the npm package is not yet published. Desktop only. No account, API key or network access. Data is stored locally under the user's data directory. An optional Pro license key is supplied through the MCP_LICENSE_KEY environment variable.
Before you install
Signing off with force signs a run despite unanswered or failed required steps; the exceptions are recorded and printed on the report. Deleting a checklist keeps its runs readable, but deleting a run is refused once it is signed off. Pro features, including writing the report to a file, need a paid one-time license key in MCP_LICENSE_KEY. The server reads a shared business profile for the name and address on printed reports.

Installation

In SourceWeft

  1. Open Purchase Requisition in the dashboard and add it to a workspace.
  2. 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-purchase-requisition

[theluckystrike/mcp-purchase-requisition MCP server]

In the official MCP Registry (io.github.theluckystrike/purchase-requisition). Checklists you build once and run many times, and the dated record of each run that somebody signs. A purchase-requisition is a named list of steps, optionally grouped into sections, each one required or optional. A run is one pass of that purchase-requisition 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 purchase-requisition 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 purchase-requisition somebody ticked and signed has to be the list they actually saw. A run that read its steps live from the purchase-requisition 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 purchase-requisition 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 complete here 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. na counts 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 purchase-requisition 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 purchase-requisition.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-purchase-requisition 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):

json
{  "mcpServers": {    "purchase-requisition": {      "command": "npx",      "args": ["-y", "@theluckystrike/mcp-purchase-requisition"]    }  }}

Claude Code

sh
claude mcp add purchase-requisition -- npx -y @theluckystrike/mcp-purchase-requisition

Cursor

~/.cursor/mcp.json (global) or .cursor/mcp.json (project), same entry as Claude Desktop.

Tools

ToolWhat it does
purchase-requisition_createCreate a reusable purchase-requisition: a name, a category, a description
purchase-requisition_item_addAdd a step: the text, a section heading, and whether it is required
purchase-requisition_item_removeRemove a step and bump the version. Runs already under way keep it
purchase-requisition_showOne purchase-requisition, grouped by section, with a blank printable copy on request
purchase-requisition_listEvery purchase-requisition with its version, step count and how many runs came from it
purchase-requisition_deleteDelete a purchase-requisition. Its runs stay readable, because each carries its own copy
run_startStart a dated run against a job. The steps are copied into it at this point
run_checkMark one step pass, fail or na, with who and when and what was found
run_showThe run: every step with its answer, the counts, the failures, and what blocks sign-off
run_listRuns newest first, filtered by purchase-requisition, status, reference, or only those with failures
run_sign_offSign off with a name and a date, which freezes the run
run_statusReopen a complete run, or abandon one when the job did not happen
run_reportThe run as text on every tier. Pro also writes it to out_path as a .txt file
run_deleteDelete a run. A signed-off one is refused
license_statusWhich tier this install is on and where the key came from
license_activateStore a Pro key for this server

There is also a resource, purchase-requisition://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_purchase-requisition, that walks the whole job in order.

Free vs Pro

FreePro
Checklists you keep3unlimited
Runs of themunlimitedunlimited
Steps per purchase-requisitionup to 500up to 500
run_show, run_list, the countsyesyes
The run report as textyesyes
Writing the report to a file with out_pathnoyes

The meter is on how many DIFFERENT purchase-requisitions 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 purchase-requisition would cap the only thing a purchase-requisition is for. Deleting a purchase-requisition frees a slot.

Get Pro: https://mcp.zovo.one/buy/purchase-requisition (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/purchase-requisition/. 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:

Source: servers/purchase-requisition/README.md at commit 1bd9d69

Tools

0
SourceWeft has not started this package in its sandbox yet, so its tools are not known.

Version history

3
  1. v0.22.8LatestOct 14, 2026
  2. v0.22.1Oct 9, 2026
  3. v0.22.0Sep 20, 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