Skip to main content
Glama
Sign In
mcp-purchase-requisition

mcp-purchase-requisition

by zovo-one
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

mcp-purchase-requisition

MCP server for purchase requisitions you build once and approve per order, with the signed record of each approval. Purchase requisitions you build once and approve per order, with the signed record of each approval.

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/purchase-requisition - 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/purchase-requisition 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/purchase-requisition/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 purchase-requisition.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-purchase-requisition.git
cd mcp-purchase-requisition
npm install && npm run build

Then point your client at the built entry point:

{
  "mcpServers": {
    "purchase-requisition": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-purchase-requisition/dist/index.js"]
    }
  }
}

@theluckystrike/mcp-purchase-requisition is not published on npm yet, so an npx -y @theluckystrike/mcp-purchase-requisition command will fail. The three paths above are the working ones and each is exercised by CI.

purchase-requisition demo

Read-only mirror of mcp-servers/servers/purchase-requisition. See MIRROR.md.

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.

Related MCP server: mcp-checklist

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):

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

Claude Code

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

Tool

What it does

purchase-requisition_create

Create a reusable purchase-requisition: a name, a category, a description

purchase-requisition_item_add

Add a step: the text, a section heading, and whether it is required

purchase-requisition_item_remove

Remove a step and bump the version. Runs already under way keep it

purchase-requisition_show

One purchase-requisition, grouped by section, with a blank printable copy on request

purchase-requisition_list

Every purchase-requisition with its version, step count and how many runs came from it

purchase-requisition_delete

Delete a purchase-requisition. Its runs stay readable, because each carries its own copy

run_start

Start a dated run against a job. The steps are copied into it at this point

run_check

Mark one step pass, fail or na, with who and when and what was found

run_show

The run: every step with its answer, the counts, the failures, and what blocks sign-off

run_list

Runs newest first, filtered by purchase-requisition, status, reference, or only those with failures

run_sign_off

Sign off with a name and a date, which freezes the run

run_status

Reopen a complete run, or abandon one when the job did not happen

run_report

The run as text on every tier. Pro also writes it to out_path as a .txt file

run_delete

Delete a run. A signed-off one is refused

license_status

Which tier this install is on and where the key came from

license_activate

Store 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

Free

Pro

Checklists you keep

3

unlimited

Runs of them

unlimited

unlimited

Steps per purchase-requisition

up to 500

up to 500

run_show, run_list, the counts

yes

yes

The run report as text

yes

yes

Writing the report to a file with out_path

no

yes

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: 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:

Available Tools

16 tools
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.

purchase-requisition_createCreate a purchase-requisitionA

Create a reusable purchase-requisition and return its CL-NNNN id: a name, a category and an optional description. Add steps with purchase-requisition_item_add. Free tier: 3 of them, runs unlimited.

Inputs: name (required), category, description.

purchase-requisition_deleteDelete a purchase-requisitionA
Destructive

Delete a purchase-requisition and its steps for good. Runs already started keep their own copy of the steps and stay readable: deleting the purchase-requisition erases nothing anybody signed.

Inputs: confirm (required), purchaseRequisition (required).

purchase-requisition_item_addAdd a step to a purchase-requisitionA

Add one step to a purchase-requisition and return its I01-style id: text, an optional section heading, and required flag. A required step left unanswered or failed blocks sign-off; an optional one does not.

Inputs: text (required), purchaseRequisition (required), note, section, +2 more.

purchase-requisition_item_removeRemove a step from a purchase-requisitionA
Destructive

Remove one step from a purchase-requisition by its I01-style id and bump the purchase-requisition version. Runs already under way keep the step they started with, so nothing anybody already ticked is rewritten.

Inputs: item (required), purchaseRequisition (required).

purchase-requisition_listList purchase-requisitionsA

Every purchase-requisition 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.

purchase-requisition_showShow one purchase-requisitionA

One purchase-requisition 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: purchaseRequisition (required), as_text.

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
Destructive

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
Read-onlyIdempotent

Runs newest first, with their purchaseRequisition, progress and sign-off state. Filter by purchaseRequisition, by status, by reference or to open runs only. Returns at most 500 rows.

Inputs: status, open_only, reference, with_failures, +1 more.

run_reportProduce the run reportA
Read-onlyIdempotent

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
Read-onlyIdempotent

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 purchase-requisitionA

Start a dated run of a purchase-requisition and return its RUN-YYYY-NNNN id. Steps are COPIED into the run, so editing the purchase-requisition later never changes a run under way. Runs are free, never capped.

Inputs: title (required), purchaseRequisition (required), date, note, +1 more.

run_statusReopen or abandon a runA
Read-onlyIdempotent

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…

    Deploy Server
    One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

    TDQS

    A4/5.0

    Scored across 16 tools

    Disambiguation5/5

    Each tool targets a distinct resource and action: template creation, item management, run lifecycle, and license management are clearly separated. Even similar-sounding tools like run_show and run_report are differentiated by purpose (interactive view vs. printable text export).

    Naming Consistency4/5

    Names mostly follow a predictable resource_action pattern, such as purchase-requisition_create, run_start, and license_activate. The pattern is slightly weakened by noun-like actions like run_status and license_status, where status means "change status" in one case and "report status" in the other.

    Tool Count4/5

    At 16 tools, the set is slightly above the ideal 3-15 range but still well-scoped for the domain: 6 template tools, 8 run tools, and 2 license tools. Each tool covers a recognizable operation, so the count feels reasonable rather than bloated.

    Completeness4/5

    The core lifecycle is well covered: create/show/list/delete requisitions, add/remove items, start/check/show/list/sign off/delete runs, and license management. Missing update operations for requisition metadata and item details are notable gaps, though they can be worked around by recreating or removing and re-adding items.

    Maintenance

    ActivityMaintained
    ResponsivenessOutdated data

    Resources

    Related MCP Connectors

    Related MCP Servers