Order real 3D prints from chat: send an STL or OpenSCAD model, see one price, get it by UPS.
Scored across 5 tools
Each tool has a clearly distinct role in the print ordering workflow: validate_stl for pre-checking printability, preview_print_order for rendering and confirming an order, submit_print_job and reorder_print_job for final order placement, and check_job_status for tracking. The descriptions explicitly warn against confusing validation with approval and enforce a strict preview-before-order sequence, leaving no ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case: check_job_status, preview_print_order, reorder_print_job, submit_print_job, validate_stl. There are no deviations or mixed conventions.
Five tools are well-scoped for a 3D print ordering service, covering the essential steps: validation, preview, submission, reorder, and status check. Each tool earns its place without redundancy or missing critical operations.
The tool set covers the full order lifecycle from validation through preview, submission, reorder, and status tracking. Minor gaps exist, such as no dedicated tool to cancel an order or list past orders, but these are workaroundable via existing status and support channels.
Look up the current status of a print job (submitted, approved, printing, QC, shipped) and its UPS tracking number once shipped. Use when the user asks about an order they placed with HardCopy Labs.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The order id, like hc-1a2b3c4d, returned by submit_print_job. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful behavioral context beyond annotations by specifying that it returns status and the tracking number only once shipped, setting expectations for the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The core action and return details are front-loaded, followed by the usage context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with strong annotations and an output schema, the description is complete. It covers what the tool does, what it returns, and when to use it, so an agent has everything needed to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: job_id is fully documented with its format ('hc-1a2b3c4d') and provenance ('returned by submit_print_job'). The description adds no parameter-level information beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Look up') and resource ('current status of a print job'), enumerates the exact status values, and mentions the UPS tracking number. This makes it clearly distinct from the sibling tools (submit, reorder, validate) which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger condition: 'Use when the user asks about an order they placed with HardCopy Labs.' This tells an agent when to invoke it, though it doesn't explicitly name alternatives or exclusions. The clear context is sufficient given the small sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MANDATORY before creating any order or checkout, including reorders.
Render exact validated geometry and quote the whole order. Display EVERY returned
part image with name, dimensions, material/color, quantity, notes and total to the
buyer. The in-chat card shows images where supported; otherwise embed image_url
values or give viewer_url and ask the buyer to review there. Never substitute an
AI illustration, or describe unshown images as reviewed. Ask for explicit buyer
confirmation of this version only after presenting the preview. Changes require
a new preview and new confirmation; pass replaces_preview_id to revoke the old preview. Preview failure blocks ordering.
After confirmation call submit_print_job (or reorder_print_job) using preview_id,
preview_version, buyer_confirmed=true and shipping/contact details; do not resend
models or option overrides. Preview generation and viewing never create an order.
Separate parts are displayed individually, not as an inferred assembly.
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | Selected filament color. Default black for new models; omit to retain reorder colors. | |
| notes | No | Operator instructions to show and bind to this preview; changes require a new preview. | |
| parts | No | The WHOLE order, one entry per part. Use a model_id from earlier validation, an STL, or OpenSCAD. Each entry has its own name, material, color and quantity. Each part's quantity is capped by its own print time, not a flat count. Shipping and handling are charged once; never add independent quote totals. | |
| job_name | No | Short order name shown with the preview. | |
| material | No | PLA or PETG. Default PLA for new models; omit to retain reorder materials. | |
| quantity | No | How many identical copies. The totals cover all of them. Capped by how long the part takes to print, not a flat number -- a quick part allows many copies, a very large or slow one may allow as few as 1; submit_print_job reports the real cap if this is too many. | |
| reorder_of | No | Existing order ID to preview for reorder; omit new model inputs when using this. | |
| stl_base64 | No | The model as a base64-encoded STL file (binary or ASCII), in millimeters. | |
| openscad_source | No | OpenSCAD source in millimeters. Rendered and validated before preview; never an illustrative AI image. | |
| replaces_preview_id | No | When revising an unplaced order, pass its previous preview id. It is invalidated even if the new render fails. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, but the description says replaces_preview_id revokes the old preview and that it is invalidated even if the new render fails. This write/invalidation behavior contradicts the read-only annotation. The description adds rich workflow context, but the contradiction forces a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loads the mandatory ordering constraint and then structures the workflow, display rules, confirmation requirement, and follow-up call clearly. Every sentence is relevant to correct invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and schema coverage is 100%, the description still supplies essential workflow context: failure blocking, buyer confirmation, image display behavior, and routing to submit/reorder tools. It is complete for a complex preview step.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already documents all 10 parameters in detail. The description adds workflow semantics such as not resending models and displaying separate parts individually, but it does not add much parameter-specific meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action: render validated geometry, quote the whole order, and display every returned part image with details. It distinguishes itself from submit/reorder by being mandatory before ordering. The verb and resource are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says it is mandatory before creating any order or checkout, including reorders. It names the follow-up alternatives submit_print_job and reorder_print_job and gives the exact conditions and fields for using them. It also states that changes require a new preview and that preview failure blocks ordering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Create an order ONLY AFTER preview_print_order, image display and buyer confirmation.
First present every preview image (or the viewer fallback), dimensions, material/color,
quantity and quote. Obtain explicit buyer confirmation for that preview version.
Then send preview_id, preview_version, buyer_confirmed=true, job_name and shipping
details ONLY; omit model/options fields. Any relevant change needs a new preview.
Legacy model inputs without a preview return a preview and NEVER create an order.
Set geometry, material, color, quantities and operator notes in preview_print_order.
OpenSCAD is preferred for designs made in conversation; uploaded STL and cached
model IDs are also supported there. One preview covers the whole multi-part order.
Confirm the shipping address with the buyer. ship_to requires their full name and
US address; contact_email is used for updates. This returns a job ID and total,
plus a payment link when payment is required. The buyer pays in their own browser.
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | Filament color, e.g. black or white. | |
| notes | No | Optional notes for the operator, e.g. which face should look best. | |
| parts | No | The WHOLE order, one entry per part. Use a model_id from earlier validation, an STL, or OpenSCAD. Each entry has its own name, material, color and quantity. Each part's quantity is capped by its own print time, not a flat count. Shipping and handling are charged once; never add independent quote totals. | |
| ship_to | No | Required. Recipient's full name and US street address, including city, state and ZIP. We ship within the United States only. | |
| job_name | Yes | A short name for the item, shown on the order and the receipt, e.g. "Desk cable clip". | |
| material | No | Print material: pla or petg. | |
| 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. | |
| stl_base64 | No | The model as a base64-encoded STL file, in millimeters. Give this or openscad_source, not both. | |
| contact_email | No | The buyer's email, for the receipt and order updates. | |
| buyer_confirmed | No | True ONLY after showing every preview image/options/price and receiving explicit buyer confirmation. Not proof of human viewing. | |
| openscad_source | No | OpenSCAD source for the model, in millimeters; rendered on our server. Preferred for models designed in the conversation. Give this or stl_base64, not both. | |
| preview_version | No | The exact preview version the buyer confirmed; changes require a new preview. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare only the safety profile (not read-only, not idempotent, open-world); the description goes well beyond them by disclosing the payment flow ('returns a job ID and total, plus a payment link when payment is required... buyer pays in their own browser'), the preview-version invalidation rule, and the legacy-input failure mode. These are exactly the non-obvious behaviors an agent must know before invoking a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The critical gate (preview + confirmation) is front-loaded in the first two sentences, and every paragraph carries instruction. It is somewhat long and restates model-source and quantity-cap guidance already covered in the schema descriptions, which is mild redundancy rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter mutating order tool with an output schema, the description covers prerequisites, gating conditions, what to send vs omit, shipping constraints, and the payment handoff. Nothing an agent needs to call it correctly is missing, and return-value details are appropriately left to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 a cross-field rule the schema does not encode: submit preview_id, preview_version, buyer_confirmed=true, job_name and shipping details ONLY, omitting model/options fields. It also reinforces that ship_to needs a full name and US address and that contact_email drives updates. Useful additions, though individual field formats largely live in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Create an order') and immediately scopes it against the sibling preview_print_order, stating the order may only be created after preview, image display and buyer confirmation. An agent can distinguish this from preview_print_order, reorder_print_job and check_job_status without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('ONLY AFTER preview_print_order, image display and buyer confirmation'), what must be presented before calling, what to exclude ('omit model/options fields', 'never add independent quote totals'), and what happens on the legacy path (returns a preview, never creates an order). Alternatives and preconditions are named rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a 3D model can be printed, before ordering.
A text validation quote is NOT approval to order. Call preview_print_order next,
show its exact model images/options/price to the buyer, then obtain confirmation.
Use this when the user has an STL file (base64-encoded) and wants to know if it
is printable, or as a pre-check before submit_print_job. Returns printability
(watertight/manifold status), dimensions, which printers it fits on, and the
total for each material: what submit_print_job will charge for this file,
shipping included. If the user is designing an object in this conversation, generate the
STL, then call this to confirm it can be manufactured. Pass quantity (default 1) when
the user wants several copies, so the totals cover all of them.
For multiple parts, pass the WHOLE order in parts with each material/color/quantity.
Never add separate quotes: totals already include shipping and handling once.
To keep payloads small, validate each STL first and reuse its model_id (24 hours).
PLA and PETG are the only materials offered.
| Name | Required | Description | Default |
|---|---|---|---|
| parts | No | The WHOLE order, one entry per part. Use a model_id from earlier validation, an STL, or OpenSCAD. Each entry has its own name, material, color and quantity. Each part's quantity is capped by its own print time, not a flat count. Shipping and handling are charged once; never add independent quote totals. | |
| quantity | No | How many identical copies. The totals cover all of them. Capped by how long the part takes to print, not a flat number -- a quick part allows many copies, a very large or slow one may allow as few as 1; submit_print_job reports the real cap if this is too many. | |
| stl_base64 | No | The model as a base64-encoded STL file (binary or ASCII), in millimeters. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial non-obvious behavior: the quote is not order approval, buyer confirmation is required via preview_print_order, model_id is reusable for 24 hours, totals already include shipping/handling and must not be added separately, and only PLA/PETG are offered. This is real workflow context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The critical constraint (quote is not approval) is front-loaded, and the remaining sentences are directive rather than filler. It runs a bit long and some workflow guidance could be tightened, but nothing is redundant bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return values, yet it still names what matters (printability, dimensions, printer fit, per-material totals that match submit_print_job). Combined with the workflow routing, an agent has everything needed to call and sequence this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaning: quantity defaults to 1 and drives totals ('pass quantity when the user wants several copies, so the totals cover all of them'), and multi-part orders must be passed whole in parts. It clarifies intent and aggregation semantics rather than repeating field definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: validating an STL's printability and returning a price total per material. It clearly distinguishes itself from submit_print_job (the actual order) and preview_print_order (the confirmation step), so an agent can place it in the workflow without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('when the user has an STL file and wants to know if it is printable', 'pre-check before submit_print_job'), an explicit next-step ('Call preview_print_order next... then obtain confirmation'), and an exclusion ('A text validation quote is NOT approval to order'). Routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
preview_print_orderreorder_print_job10 fields changedInput schema / properties / buyer_confirmedAdded 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"
+}Input schema / properties / notes / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / notes / defaultPrevious value: -""New value: +nullInput schema / properties / notes / typeRemoved value: -"string"Input schema / properties / preview_idAdded value: +{
+ "default": "",
+ "description": "The id returned by preview_print_order for the images shown to the buyer.",
+ "title": "Preview Id",
+ "type": "string"
+}Input schema / properties / preview_versionAdded value: +{
+ "default": "",
+ "description": "The exact preview version the buyer confirmed; changes require a new preview.",
+ "title": "Preview Version",
+ "type": "string"
+}Input schema / properties / quantity / anyOfAdded value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / quantity / defaultPrevious value: -1New value: +nullInput schema / properties / quantity / descriptionPrevious 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."Input schema / properties / quantity / typeRemoved value: -"integer"submit_print_job18 fields changedInput schema / $defsAdded value: +{
+ "OrderPart": {
+ "additionalProperties": false,
+ "properties": {
+ "color": {
+ "default": "black",
+ "description": "Filament color for this part.",
+ "maxLength": 40,
+ "title": "Color",
+ "type": "string"
+ },
+ "material": {
+ "default": "pla",
+ "description": "PLA or PETG only.",
+ "maxLength": 20,
+ "title": "Material",
+ "type": "string"
+ },
+ "model_id": {
+ "default": "",
+ "description": "Reusable id from validate_stl; valid for 24 hours.",
+ "maxLength": 64,
+ "title": "Model Id",
+ "type": "string"
+ },
+ "name": {
+ "description": "Short part name, shown on the card and receipt.",
+ "maxLength": 120,
+ "minLength": 1,
+ "title": "Name",
+ "type": "string"
+ },
+ "openscad_source": {
+ "default": "",
+ "description": "OpenSCAD in millimeters; give exactly one model source.",
+ "maxLength": 50000,
+ "title": "Openscad Source",
+ "type": "string"
+ },
+ "quantity": {
+ "default": 1,
+ "description": "Copies of THIS part. Capped by how long this part takes to print, not a flat number -- checked once its geometry is known; a rejected order reports the real cap for this part's size.",
+ "maximum": 500,
+ "minimum": 1,
+ "title": "Quantity",
+ "type": "integer"
+ },
+ "stl_base64": {
+ "default": "",
+ "description": "STL in millimeters; give exactly one model source.",
+ "maxLength": 25000000,
+ "title": "Stl Base64",
+ "type": "string"
+ }
+ },
+ "required": [
+ "name"
+ ],
+ "title": "OrderPart",
+ "type": "object"
+ }
+}Input schema / properties / buyer_confirmedAdded 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"
+}Input schema / properties / color / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / color / defaultPrevious value: -"black"New value: +nullInput schema / properties / color / typeRemoved value: -"string"Input schema / properties / material / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / material / defaultPrevious value: -"pla"New value: +nullInput schema / properties / material / typeRemoved value: -"string"Input schema / properties / notes / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / notes / defaultPrevious value: -""New value: +nullInput schema / properties / notes / typeRemoved value: -"string"Input schema / properties / partsAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/OrderPart"
+ },
+ "maxItems": 20,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "The WHOLE order, one entry per part. Use a model_id from earlier validation, an STL, or OpenSCAD. Each entry has its own name, material, color and quantity. Each part's quantity is capped by its own print time, not a flat count. Shipping and handling are charged once; never add independent quote totals.",
+ "title": "Parts"
+}Input schema / properties / preview_idAdded value: +{
+ "default": "",
+ "description": "The id returned by preview_print_order for the images shown to the buyer.",
+ "title": "Preview Id",
+ "type": "string"
+}Input schema / properties / preview_versionAdded value: +{
+ "default": "",
+ "description": "The exact preview version the buyer confirmed; changes require a new preview.",
+ "title": "Preview Version",
+ "type": "string"
+}Input schema / properties / quantity / anyOfAdded value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / quantity / defaultPrevious value: -1New value: +nullInput schema / properties / quantity / descriptionPrevious 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."Input schema / properties / quantity / typeRemoved value: -"integer"validate_stl5 fields changedInput schema / $defsAdded value: +{
+ "OrderPart": {
+ "additionalProperties": false,
+ "properties": {
+ "color": {
+ "default": "black",
+ "description": "Filament color for this part.",
+ "maxLength": 40,
+ "title": "Color",
+ "type": "string"
+ },
+ "material": {
+ "default": "pla",
+ "description": "PLA or PETG only.",
+ "maxLength": 20,
+ "title": "Material",
+ "type": "string"
+ },
+ "model_id": {
+ "default": "",
+ "description": "Reusable id from validate_stl; valid for 24 hours.",
+ "maxLength": 64,
+ "title": "Model Id",
+ "type": "string"
+ },
+ "name": {
+ "description": "Short part name, shown on the card and receipt.",
+ "maxLength": 120,
+ "minLength": 1,
+ "title": "Name",
+ "type": "string"
+ },
+ "openscad_source": {
+ "default": "",
+ "description": "OpenSCAD in millimeters; give exactly one model source.",
+ "maxLength": 50000,
+ "title": "Openscad Source",
+ "type": "string"
+ },
+ "quantity": {
+ "default": 1,
+ "description": "Copies of THIS part. Capped by how long this part takes to print, not a flat number -- checked once its geometry is known; a rejected order reports the real cap for this part's size.",
+ "maximum": 500,
+ "minimum": 1,
+ "title": "Quantity",
+ "type": "integer"
+ },
+ "stl_base64": {
+ "default": "",
+ "description": "STL in millimeters; give exactly one model source.",
+ "maxLength": 25000000,
+ "title": "Stl Base64",
+ "type": "string"
+ }
+ },
+ "required": [
+ "name"
+ ],
+ "title": "OrderPart",
+ "type": "object"
+ }
+}Input schema / properties / partsAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "$ref": "#/$defs/OrderPart"
+ },
+ "maxItems": 20,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "The WHOLE order, one entry per part. Use a model_id from earlier validation, an STL, or OpenSCAD. Each entry has its own name, material, color and quantity. Each part's quantity is capped by its own print time, not a flat count. Shipping and handling are charged once; never add independent quote totals.",
+ "title": "Parts"
+}Input schema / properties / quantity / descriptionPrevious value: -"How many identical copies, 1 to 20. The totals cover all of them."New value: +"How many identical copies. The totals cover all of them. Capped by how long the part takes to print, not a flat number -- a quick part allows many copies, a very large or slow one may allow as few as 1; submit_print_job reports the real cap if this is too many."Input schema / properties / stl_base64 / defaultAdded value: +""Input schema / requiredRemoved value: -[
- "stl_base64"
-]check_job_status1 field changedInput schema / properties / job_id / descriptionAdded value: +"The order id, like hc-1a2b3c4d, returned by submit_print_job."reorder_print_jobsubmit_print_job9 fields changedInput schema / properties / color / descriptionAdded value: +"Filament color, e.g. black or white."Input schema / properties / contact_email / descriptionAdded value: +"The buyer's email, for the receipt and order updates."Input schema / properties / job_name / descriptionAdded value: +"A short name for the item, shown on the order and the receipt, e.g. \"Desk cable clip\"."Input schema / properties / material / descriptionAdded value: +"Print material: pla or petg."Input schema / properties / notes / descriptionAdded value: +"Optional notes for the operator, e.g. which face should look best."Input schema / properties / openscad_source / descriptionAdded value: +"OpenSCAD source for the model, in millimeters; rendered on our server. Preferred for models designed in the conversation. Give this or stl_base64, not both."Input schema / properties / quantityAdded value: +{
+ "default": 1,
+ "description": "How many identical copies, 1 to 20. The totals cover all of them.",
+ "title": "Quantity",
+ "type": "integer"
+}Input schema / properties / ship_to / descriptionAdded value: +"Required. Recipient's full name and US street address, including city, state and ZIP. We ship within the United States only."Input schema / properties / stl_base64 / descriptionAdded value: +"The model as a base64-encoded STL file, in millimeters. Give this or openscad_source, not both."validate_stl2 fields changedInput schema / properties / quantityAdded value: +{
+ "default": 1,
+ "description": "How many identical copies, 1 to 20. The totals cover all of them.",
+ "title": "Quantity",
+ "type": "integer"
+}Input schema / properties / stl_base64 / descriptionAdded value: +"The model as a base64-encoded STL file (binary or ASCII), in millimeters."check_job_statussubmit_print_jobvalidate_stlDesign 3D-printable parts by chatting: create, edit, render and publish parametric forges.
Quote, check and order 3D prints of STL, 3MF, STEP or OBJ files. Made in the USA, shipped in the US.
Turn designs into shipped parts: quote 3D printing, CNC, and decals, then check out.
Parametric 3D CAD for AI agents: build print-ready parts, check them, export STL, 3MF or STEP.
Add one secure layer between your agents and this server.