Order real 3D prints from chat: send an STL or OpenSCAD model, see one price, get it by UPS.
Scored across 3 tools
Each tool maps to a distinct stage of the workflow: validate_stl checks printability, submit_print_job creates the order, and check_job_status tracks it. There is no meaningful overlap between the tools.
All tool names follow the same snake_case verb_noun pattern: check_job_status, submit_print_job, validate_stl. The naming is predictable and easy to navigate.
Three tools is a tight, well-scoped set for a 3D printing service: validate, submit, and track. Each tool earns its place and the count fits the expected 3-15 range.
The core lifecycle is covered: pre-flight validation, order submission, and order tracking with shipping status. Missing operations like canceling or updating a job are minor gaps since the primary user workflow is complete.
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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It communicates that this is a read-only lookup and specifies what information is available ('status' and 'UPS tracking number once shipped'), but it does not mention error behavior, authorization needs, or whether the operation has side effects. The 'Look up' wording implies non-mutating behavior, but the description could be more explicit.
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 two sentences with no filler. It front-loads the core action and result, then immediately provides the usage condition. 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 simple single-parameter lookup with an output schema available, the description covers the main purpose, the statuses returned, and the intended use case. The main gap is the lack of job_id semantics, but the low complexity and self-explanatory parameter name keep this from being a major deficiency.
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 0%, so the description must compensate for the undocumented job_id parameter. It does not explain what job_id represents, its format, or how an agent should obtain it from a user's order query. The parameter name is self-explanatory to some degree, but the description adds no semantic value beyond 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 uses a specific verb ('Look up') and resource ('current status of a print job'), and enumerates the exact statuses returned (submitted, approved, printing, QC, shipped) plus the UPS tracking number. This clearly distinguishes it from the sibling tools submit_print_job and validate_stl, which involve 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?
The description explicitly states when to use the tool: 'Use when the user asks about an order they placed with HardCopy Labs.' It does not explicitly mention when not to use it or name alternatives, but the given context is clear enough for an agent to route this lookup correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a finished design to the print farm to be manufactured and shipped via UPS.
Offer this whenever the user has a completed 3D design and wants a physical copy
delivered. Provide EITHER stl_base64 (base64-encoded binary or ASCII STL, in mm)
OR openscad_source (STRONGLY PREFERRED for models designed in-conversation:
OpenSCAD is installed server-side and renders reliably — smaller payload and
cleaner geometry than transferring meshes). ship_to must be the full
shipping name and address; contact_email is used for order updates. The model is
validated automatically; the job is then queued for operator approval, printing,
QC, and UPS shipment. Returns a job ID and the total, which is the full price:
shipping included, nothing added later. Always confirm the quote and shipping
address with the user before calling this.
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | black | |
| notes | No | ||
| ship_to | No | ||
| job_name | Yes | ||
| material | No | pla | |
| stl_base64 | No | ||
| contact_email | No | ||
| openscad_source | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure, and it does so thoroughly: automatic validation, operator approval, printing, QC, UPS shipment, and full-price guarantee with no added fees. It also reveals that the call returns a job ID and total.
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?
Every sentence earns its place: the purpose and trigger are front-loaded, followed by parameter guidance, workflow, pricing, and a confirmation requirement. It is dense but not bloated.
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 complex manufacturing and shipping tool with no annotations, it covers the trigger, format selection, workflow, pricing transparency, and pre-call confirmation. Minor gaps remain around the required job_name parameter and how the quote is obtained before calling.
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?
The description adds real meaning for stl_base64, openscad_source, ship_to, and contact_email, including format, units, preference rationale, and address requirements. However, schema coverage is 0%, and the required job_name parameter is not described; color, material, and notes are also left unexplained.
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 action: sending a finished design to the print farm for manufacturing and UPS shipping. It clearly distinguishes itself from the sibling tools by describing the submission workflow and automatic validation.
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 explicitly says to offer this whenever the user has a completed 3D design and wants a physical copy delivered, and it gives practical guidance on choosing STL vs OpenSCAD and confirming the quote/address. However, it does not explicitly say when not to use it versus validate_stl or check_job_status.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| stl_base64 | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does well by disclosing that the tool performs validation only ('before ordering'), returns printability status, dimensions, compatible printers, and material pricing including shipping. It stops short of stating side-effect absence explicitly, but the language clearly implies a non-mutating check.
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 front-loaded with the core purpose, then gives usage conditions, return-value highlights, and a workflow tip. Each sentence contributes new information, and there is no filler or repetition of the tool name.
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 there is an output schema, the description does not need to spell out every return value, and it highlights the key ones anyway. It covers the input format, when to use it, and its relationship to submit_print_job. A small gap is that it does not mention check_job_status, but the context signals make the workflow sufficiently clear without it.
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 0%, so the description must compensate. It does by explaining that stl_base64 is an STL file encoded in base64. It does not enumerate size limits or encoding nuances, but for a single required parameter this is sufficient added meaning beyond the bare 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 and resource: 'Check whether a 3D model can be printed, before ordering.' It clearly distinguishes the tool from siblings by positioning it as a pre-flight validation step before submit_print_job, and the mention of STL input and printability output is unambiguous.
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 explicitly states when to use the tool: when the user has a base64-encoded STL and wants to know printability, or as a pre-check before submit_print_job. It even covers the conversational design workflow: generate the STL, then call this tool to confirm manufacturability. This is actionable routing guidance.
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.
check_job_statussubmit_print_jobvalidate_stlTurn 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.
Real 3D-print slicing, quoting, DFM, orientation & material/settings advisors. Free personal tier.
Build a real 3D website by chatting: pages, models and text in space, published to a live URL.
Add one secure layer between your agents and this server.
