HardCopy Labs

Reorder a past print

reorder_print_job

A REORDER ALSO REQUIRES A NEW VISUAL PREVIEW AND BUYER CONFIRMATION.

First call preview_print_order with reorder_of and any desired changes, show every
image/options/price to the buyer, and obtain confirmation. Then call this with
preview_id, preview_version and buyer_confirmed=true, without option overrides.
Without a preview this returns a preview only; it never creates an order.

In preview_print_order, quantity means complete sets for multi-part reorders;
material/color overrides apply to every part. Omit overrides to preserve choices.
Prices are recalculated. The previous order's geometry is reused without requesting
a new upload. Shipping/contact details are never copied from the previous order;
confirm the new address with the buyer. Orders cancelled by HardCopy Labs or still
awaiting payment cannot be reordered. Returns a new job ID, total and payment link
when payment is required, only after the new preview is confirmed.

Input Schema

TableJSON Schema

Name	Required	Description
`color`	No	Filament color. Leave empty to keep the earlier order's color.
`notes`	No	Optional notes for the operator.
`job_id`	Yes	The id of the earlier order to copy, like hc-1a2b3c4d.
`ship_to`	Yes	Recipient's full name and US street address, including city, state and ZIP. Not copied from the earlier order. We ship within the United States only.
`material`	No	pla or petg. Leave empty to keep the earlier order's material.
`quantity`	No	How many identical copies. Capped by print time, not a flat number; the totals cover all of them.
`preview_id`	No	The id returned by preview_print_order for the images shown to the buyer.
`contact_email`	No	The buyer's email, for the receipt and order updates. Not copied from the earlier order.
`buyer_confirmed`	No	True ONLY after showing every preview image/options/price and receiving explicit buyer confirmation. Not proof of human viewing.
`preview_version`	No	The exact preview version the buyer confirmed; changes require a new preview.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedSep 30, 2026

addedInput schema / properties / buyer_confirmed

Added value: +{
+  "default": false,
+  "description": "True ONLY after showing every preview image/options/price and receiving explicit buyer confirmation. Not proof of human viewing.",
+  "title": "Buyer Confirmed",
+  "type": "boolean"
+}

addedInput schema / properties / notes / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / notes / default
```
Previous value: -""New value: +null
```
removedInput schema / properties / notes / type
```
Removed value: -"string"
```

addedInput schema / properties / preview_id

Added value: +{
+  "default": "",
+  "description": "The id returned by preview_print_order for the images shown to the buyer.",
+  "title": "Preview Id",
+  "type": "string"
+}

addedInput schema / properties / preview_version

Added value: +{
+  "default": "",
+  "description": "The exact preview version the buyer confirmed; changes require a new preview.",
+  "title": "Preview Version",
+  "type": "string"
+}

addedInput schema / properties / quantity / anyOf

Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / quantity / default
```
Previous value: -1New value: +null
```

changedInput schema / properties / quantity / description

Previous value: -"How many identical copies, 1 to 20. The totals cover all of them."New value: +"How many identical copies. Capped by print time, not a flat number; the totals cover all of them."

removedInput schema / properties / quantity / type
```
Removed value: -"integer"
```

AddedSep 26, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare the generic safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=true), so the description carries real weight and delivers it: mandatory preview gate, buyer confirmation requirement, no option overrides when confirming a preview, price recalculation, geometry reuse without re-upload, and that shipping/contact data is never copied. These are non-obvious behavioral constraints an agent could not infer from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical constraint is front-loaded in caps, and the confirm-then-call sequence follows immediately. The middle paragraph shifts to describing preview_print_order's parameter semantics, which is useful cross-tool context but slightly off-tool narrative, keeping this short of a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, yet the description still notes the new job ID, total, and payment link. Combined with the workflow, eligibility limits, and per-parameter overrides, nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds semantics the schema does not: quantity means complete sets for multi-part reorders (and the override applies to every part), omitting overrides preserves prior choices, and buyer_confirmed is the gate rather than proof of human viewing. That is genuine added meaning beyond the field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ('reorder' of a past print/job) and explicitly distinguishes itself from the sibling preview_print_order by stating the two-step relationship. An agent knows exactly which tool creates an order and which prepares one.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit ordered workflow: call preview_print_order first with reorder_of, show the buyer, confirm, then call this with preview_id/preview_version/buyer_confirmed. It also states the when-not case ('Without a preview this returns a preview only; it never creates an order') and the ineligible order states (cancelled, awaiting payment).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All HardCopy Labs tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?