Home · Setup · Claude.ai and Claude Desktop connectors
Purchase requisitions you build once and run per order, with a signed record of each run. You hold a requisition as a named, versioned list of steps, optionally grouped into sections, each required or optional, and run it against an order as many times as you like. A run copies its requisition's steps when it starts and records the version, so editing the requisition afterwards never changes a run already under way. run_check marks steps pass, fail or na with who and when (na counts as answered, never as passed; a required step failed blocks sign-off), run_report gives the whole run with failures in full, and run_sign_off puts a name and a date on it and freezes it. RUN-YYYY-NNNN ids are sequential and never reissued.
The requisitions and their runs live in the hosted store behind the token, so the three free requisitions and their REQ-YYYY-NNNN numbers follow the key rather than the machine. There is no network call inside the server on any route, so the snapshot rule is identical here and on a laptop, and run_report's .txt output comes back in the answer itself, because a hosted call has nowhere local to write it.
| You say | Tool |
|---|---|
| Make a pre-delivery vehicle check requisition: tyres, lights, load secured. | purchase-requisition_create then purchase-requisition_item_add |
| Start a run of it for van BX21 KLM against PO-0031. | run_start |
| The weight step failed at 3620 against a plated 3500. Can it be signed off? | run_check then run_sign_off |
The unit suite is 15 tests, 15 passing, 0 failing (node --test, node v22), covering the snapshot rule, the na-is-not-pass rule and the sign-off freeze; adversarial, concurrency, paths and contract suites sit alongside it.
https://mcp.zovo.one/mcp/connect mints an anonymous token and prints a URL per server, including this one, shaped like https://mcp.zovo.one/mcp/purchase-requisition/t/<token>. That URL works with no headers: the token is in the path, not in an Authorization field this form does not have.
Idle anonymous tokens are swept after 30 days. Since this route has no filesystem, a file MCP Purchase Requisition generates comes back as a download link that expires after one hour. A Pro key can replace the token in the same URL and removes the free-tier limits.
On an individual Pro or Max plan you add the connector yourself from Customize, Connectors. On Team and Enterprise it is the other way round: only an Owner or Primary Owner can add a custom connector, at Organization settings, Connectors, and members then connect to what the Owner added rather than pasting their own URL.
Free: Three requisitions, and unlimited runs of them on every tier, because capping the running of a requisition would cap the only thing a requisition is for. Deleting a requisition frees its slot and every run stays readable. Pro is $19 once, verified offline, and binds to the token after checkout.
No. Add custom connector offers an Advanced settings section with an OAuth Client ID and Client Secret, but the connect-by-URL route does not use it. Leave both blank: the token in the URL path is what authenticates.
That is documented, not a bug: on Team and Enterprise, only an Owner or Primary Owner can add a custom connector, at Organization settings, Connectors, Add, Custom, Web. After that, members connect to the URL the Owner added from Customize, Connectors.
Yes. The token segment of the URL from /mcp/connect can be replaced with a Pro key, which removes the free-tier limits on MCP Purchase Requisition for that connector.
The connector runs server-side with no filesystem of its own, so any file MCP Purchase Requisition produces is handed back as a download link that expires after one hour, rather than a path on disk.
MCP Purchase Requisition in detail · How connect-by-URL works · Every server for Claude.ai and Claude Desktop connectors · All clients · Claude.ai and Claude Desktop connectors docs · Buy Pro