Procurement MCP

The Procurement MCP is the connector the operator test runs on. An agent calls named tools (open_repair_job, recommend_basket, track_procurement) instead of writing HTTP; the wire contract underneath is identical to the sandbox API.

Every tool has an unambiguous name, typed inputs with seeded examples, and errors mapped to { code, message, retryable } where the message names the next step.

Connect it

https://partifact-procurement-mcp.thanhvuttv.workers.dev/mcp/partifact-public-demo/<your-slot>

partifact-public-demo is the public demo token. It only gates the hosted endpoint against random traffic (a gate, not authentication, see Credentials and tokens). It is also accepted as an Authorization: Bearer partifact-public-demo header.
<your-slot> is any name you choose ([a-z0-9_-]). It selects your own private sandbox, seeded fresh with the same 2019 Toyota Corolla repair job (external reference CCC-2026-04817). Two people on two slots never touch each other’s data. To start over, just change the name: a new slot is a guaranteed-clean world on first use, and idle slots self-reset after about an hour.
Paste the full URL into your client and connect. Then, in a fresh chat, hand the agent the workflow (below).

Drive the seeded job

In a fresh chat with the connector enabled:

“Using only the Procurement MCP tools, take the repair job for the 2019 Toyota Corolla (external reference CCC-2026-04817) through to a reconciled invoice. Tell me what you did and why at each step.”

A capable agent completes this unaided, orienting itself from get_started, guide://lifecycle, and scenario://current, and ending at a reconciled invoice (about $1,099 NZD if it orders the two Christchurch Toyota parts). That run has been done and measured: an agent drove the full lifecycle to a reconciled invoice, including self-correcting from an induced error. See the operator test results.

What it exposes

13 tools

The lifecycle is legible from the tool descriptions alone. Call get_started first: it returns the full tool order.

Tool	Backs onto	Scope
`get_started`	(guided entry point)	n/a
`get_run_metrics`	(per-session run telemetry)	n/a
`prepare_vehicle`	`tier1.prepare`	repairer
`find_repairer_site`	`businesses.list`	repairer
`list_work_providers`	`repairer.work-providers.list`	repairer
`open_repair_job`	`repairer.jobs.insert`	repairer
`get_job`	`repairer.jobs.get`	repairer
`identify_parts`	`repairer.jobs.parts.insert` (append-merge)	repairer
`recommend_basket`	`repairer.jobs.baskets.latest.get`	repairer
`track_procurement`	`repairer.procurements.get`	repairer
`confirm_procurement`	`supplier.procurements.confirm`	supplier
`place_procurement` extension	`repairer.procurements.insert`	repairer
`reconcile_invoice` extension	`repairer.procurements.invoices.list`	repairer

confirm_procurement is the only supplier-scope tool; everything else is repairer-scope. The server holds two credentialled clients over one backend, so one agent can drive both sides of an inherently two-party protocol.

8 resources

Read-only grounding the agent can pull at any time:

guide://lifecycle · scenario://current · reference://suppliers · reference://ghca-categories · reference://work-providers · job://current · job://{job_id} (template) · events://recent (the webhook outbox)

Errors name the next step

The API returns terse, type-tagged coded errors (correct for SDK consumers). This server maps each into { code, message, retryable } where the message names the next action, so an agent self-corrects from the message alone (for example, “fetch a basket before placing,” or “that offer isn’t in the basket”). Two rules the server teaches the agent:

retryable: true is reserved for transport faults (the call never reached the server). A contract error always needs a different action, never a blind retry.
After any state-changing call, re-fetch (get_job / track_procurement); don’t assume the new state.