Get 3D printing and manufacturing quoted by a person, shipped anywhere in the US.
Scored across 6 tools
Each tool has a distinct purpose: capabilities discovery, file attachment, geometry validation, job submission, order tracking, and escalation. The main potential confusion is between check_geometry (validates a file) and check_order (tracks a job), but the descriptions clearly separate these. attach_files vs submit_job is also differentiated by the 'job with no file waits' framing.
All six tools follow a clean verb_noun snake_case pattern: attach_files, check_geometry, check_order, escalate_to_human, get_capabilities, submit_job. No style deviations or mixed conventions.
Six tools is well-scoped for a print-shop ordering workflow, covering discovery, validation, submission, tracking, and escalation without redundancy. Each tool earns its place.
The ordering lifecycle is well covered: read capabilities, attach files, validate geometry, submit, track status/quote, and escalate. Minor gaps include no cancel/withdraw tool and no way to list existing jobs, but the core human-in-the-loop workflow is intact.
Send the geometry as base64 bytes. Quotes need it — a job with no file waits for one. Accepts STL, 3MF, OBJ, STEP, IGES, PLY, DXF, SVG, images and PDF. Up to 10 files, 50MB each. We will not fetch a URL for you; send the bytes.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | ||
| token | Yes | From submit_job. | |
| orderId | Yes | From submit_job. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load and does well: it discloses accepted formats, a 10-file cap, 50MB per file, and the important constraint that URLs are not fetched (bytes must be supplied). It does not cover auth requirements or failure/partial-upload behavior, keeping it below a 5.
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?
Four short, front-loaded sentences with no filler; each carries a distinct constraint. The dashes and colloquial phrasing cost a little structural crispness but nothing is wasted.
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 no-output-schema, no-annotation tool, the description supplies formats, limits, encoding, and the key negative constraint. Missing only return/error behavior and the token/orderId provenance, which the schema partially covers via 'From submit_job.'
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 67%, and the description adds meaning beyond it: the format whitelist, per-file size cap, item-count maximum, and the base64-not-URL requirement. The 'fileName extension decides how the file is read' nuance duplicates the schema rather than extending it, but overall it compensates for the coverage gap.
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 first sentence gives a specific verb and resource ('Send the geometry as base64 bytes'), and the mention of quotes/a waiting job clearly separates it from submit_job and check_geometry. An agent can identify the operation without opening the 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?
'Quotes need it — a job with no file waits for one' states the condition under which this tool is required, which is strong routing context. It stops short of explicitly naming alternatives or when-not-to-use this tool, so it does not reach the full when/when-not/alternatives bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an STL, 3MF or OBJ and get back its real size, volume, roughly how much plastic it needs, and whether it fits on one plate. Instant, no human involved, nothing is ordered.
Use this BEFORE submit_job whenever your human has a file. It catches the things that waste everyone's day — a part that is 340mm tall and has to be split, a file exported in inches so it arrives 25x too small, a mesh with no solid volume.
It does NOT return a price and never will. Orientation, supports and finishing decide the price and a person here decides those. Do not infer a price from the grams.
| Name | Required | Description | Default |
|---|---|---|---|
| base64 | Yes | The file's bytes, base64 encoded. | |
| fileName | Yes | Including the extension — it decides how the file is read. STL, 3MF or OBJ. STEP cannot be measured. | |
| material | No | PLA, PETG, ABS, ASA, TPU, Nylon, PC. Only changes the weight estimate. Defaults to PLA. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: 'Instant, no human involved, nothing is ordered' and an explicit 'It does NOT return a price and never will... Do not infer a price from the grams.' That is strong disclosure of side-effect-free behavior and a real misuse guardrail. It stops short of describing error handling or limits for unsupported files.
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?
Front-loaded with the core action and outputs, then the usage rule, then the negative constraint. Nearly every sentence earns its place, though the no-price point is stated twice ('does NOT return a price' and 'Do not infer a price'), a mild redundancy.
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?
No output schema and no annotations, but the description compensates by enumerating what comes back (size, volume, plastic usage, plate fit) and what does not (price). Three parameters are fully schema-described. Only error/edge behavior for malformed or unsupported files is left implicit.
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%, so fileName, base64 and material are already fully documented — baseline 3. The description adds no new per-parameter semantics beyond the schema (the STEP-not-measurable and material-affects-weight notes are already in 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?
Names a specific verb+resource ('Send an STL, 3MF or OBJ and get back its real size, volume...') and enumerates the exact outputs (size, volume, grams, plate fit). It is unmistakably distinct from submit_job, which it explicitly contrasts against.
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?
States the trigger condition plainly: 'Use this BEFORE submit_job whenever your human has a file.' It also names when-not (it never returns a price, orientation/supports/finishing are decided by a person) and points at the concrete failure cases it is meant to catch (oversized part, inch/mm unit error, non-solid mesh).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where the job has got to. Once a person has priced it this returns the quote, what is outstanding, and links for your HUMAN to approve and pay. Relay those links to them — tapping them is their job, not yours. Poll this when your human asks rather than on a timer; nothing here changes faster than a person works.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| orderId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does unusually well: it discloses the return contents, states that the links are for the HUMAN to approve and pay, and instructs the agent to relay rather than tap them. The gap is that it never says what the token is for or what happens if the job is unpriced, but the role-division and polling behavior are genuinely useful beyond any structured field.
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?
Four short sentences, front-loaded with purpose and return contents, then usage guidance. The closing rationale ('nothing here changes faster than a person works') is conversational but earns its place by justifying the no-timer rule.
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 two-parameter read tool with no output schema and no annotations, the description supplies what is needed to call it correctly in context: when to poll, what returns, and who acts on the links. Only the parameter meanings remain unaddressed, which is the one substantive hole.
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 0% and the description never explains either parameter. 'The job' weakly implies orderId identifies the order, but the required 'token' is entirely unexplained in both schema and description, so an agent gets no help on what to pass or where to get it.
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 title pins the verb+resource ('Check on a job and read back the quote') and the description states what comes back: status, quote, outstanding items, and approve/pay links. It is distinguishable from submit_job and escalate_to_human, though the opening line 'Where the job has got to' is an indirect way of stating the purpose and leans on the title to be fully legible.
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 timing guidance ('Poll this when your human asks rather than on a timer') and a clear precondition ('Once a person has priced it this returns the quote'). That covers when and when-not, but names no alternative tool for cases where the job is not yet priced or the human wants a different action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hand a question to a human at the shop. Use it the moment you are asked something you cannot actually know — whether a material is food safe or dishwasher safe, whether a colour can be matched, whether a part will hold a given load, anything about tolerances, or any request to change a price or a deadline.
Guessing is the thing to avoid here. Your human will believe an answer that came through the shop's own tool, and a wrong one costs them money and costs the shop a customer. Calling this is free and always the better move: it flags the job and messages the owner directly.
Say nothing definite while you wait.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | From submit_job. | |
| orderId | Yes | From submit_job. | |
| urgency | No | 'blocking' only if you genuinely cannot continue without an answer. Overusing it makes it meaningless. | |
| question | Yes | What you could not answer. Use your human's own words where you have them — paraphrasing loses the detail a person needs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose real behavior: the call is free, it flags the job and messages the owner directly, and the agent should wait without committing to an answer. That covers side effects, cost, and the async nature of the interaction. It does not describe what comes back or how long a response takes, which is the main remaining gap.
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?
Purpose is front-loaded in the first sentence and the rest is organized as trigger examples, motivation, and a closing behavioral instruction. It is somewhat lengthy and the persuasive tone (Guessing is the thing to avoid here) costs a few words, but nothing is truly redundant.
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 four-parameter escalation tool with no annotations and no output schema, the description supplies the missing behavioral context: cost, what the tool does behind the scenes, and how long the agent should hold off. The absence of any statement about the returned result or expected latency keeps it from being fully complete.
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%, and the schema already explains token/orderId provenance, the urgency enum and its misuse warning, and the guidance to use the human's own words for question. The description adds only illustrative examples of what counts as an unanswerable question, so the 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?
The first sentence states a specific verb and resource (hand a question to a human at the shop), and the title 'Ask a person, instead of guessing' reinforces the escalation semantics. This is clearly distinct from siblings like submit_job, check_order, or get_capabilities, which handle deterministic operations rather than human routing.
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 gives an explicit and vivid trigger condition — use it the moment you are asked something you cannot actually know — followed by concrete examples (food safety, colour matching, load tolerances, price/deadline changes). It also preempts the obvious hesitation by stating calling is free and always the better move. It stops short of naming sibling tools as alternatives, but since this is an escalation path rather than a competing query tool, the guidance is essentially complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Services, materials, turnaround, limits, and exactly what you as an assistant can and cannot do here. Read this first if you have not worked with this shop before.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose that the payload covers 'limits' and 'exactly what you as an assistant can and cannot do here', which is meaningful boundary information. However it never states that this is a side-effect-free read, whether the result is stable/cacheable, or anything about cost, so a mutation-safe call must be inferred.
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 sentences, no filler, and the payload list is front-loaded before the conditional use instruction. Every clause carries information.
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 no output schema and no annotations, the description does the right thing by enumerating the contents the agent will receive (services, materials, turnaround, limits, permissions). It is complete enough to justify calling it as a primer; only the read-only/side-effect profile is left implicit.
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?
Zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly adds no fake parameter talk.
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 exactly what the tool returns: services, materials, turnaround, limits, and the assistant's own permission boundaries. That is specific and self-evident, and 'Read this first' implicitly separates it from the transactional siblings (submit_job, check_order). It stops short of naming any sibling explicitly, so it is clear but not differentiating in the way a 5 requires.
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?
'Read this first if you have not worked with this shop before' gives an explicit triggering condition for use, which is more than most definitions offer. It does not name alternatives or state when-not to call it (e.g., skip once cached), so the guidance is clear context rather than full routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Opens a request with the shop. A person reviews it and sends a quote, usually within one business day. The customer is emailed immediately telling them you did this for them. Nothing is charged and no price is agreed. Returns an order id and a token — keep both, they are how you attach files and check back.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| phone | Yes | A number they actually answer. The shop rings customers. Placeholders and 555 numbers are rejected. | |
| material | No | PLA, PETG, ABS, ASA, TPU, Nylon, resin, metal — or leave out if unsure. | |
| neededBy | No | Any deadline, in plain words. 'before 15 September' is fine. | |
| quantity | No | ||
| agentName | No | What you are — ChatGPT, Claude, Perplexity, your product name. Recorded on the job; grants you nothing. | |
| webhookUrl | No | Optional https URL we POST to when a person here has priced the job, so you do not have to poll. Signed with an x-3dpe-signature header. Must be publicly reachable. | |
| description | Yes | What they want made, in plain words. Include size, quantity, material and any deadline you know. | |
| customerName | Yes | Your human's name. | |
| customerEmail | Yes | Their real email — this is where the confirmation and the quote go. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the human review step, expected turnaround, that the customer is emailed immediately, that nothing is charged and no price is agreed, and that an order id and token are returned. It omits auth/permission requirements and rate limits, but the workflow and side-effect transparency is notably strong.
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?
Four tight sentences, front-loaded with the core action and then the workflow, billing status, and return values. No sentence is wasted.
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 submission tool with no output schema, the description supplies the key return contract (order id and token, and what to do with them) and the side-effect profile. It is nearly complete; only explicit routing relative to siblings 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 description coverage is 80%, so the schema already documents most parameters well. The description adds essentially nothing about individual input parameters, only the returned id/token, so the baseline 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 clearly states a specific verb and resource — "Opens a request with the shop" — and the title reinforces it. It does not directly name any sibling tool, so differentiation from check_order or escalate_to_human relies on the reader, but the purpose itself 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 conveys the workflow (human review, quote within a business day, no charge) which implies when this tool is appropriate, and hints at follow-up via 'attach files and check back'. However, it never states explicit when-to-use vs. alternatives or prerequisites for calling it, so guidance is implied rather than stated.
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.
attach_filescheck_geometrycheck_orderescalate_to_humanget_capabilitiessubmit_jobTurn designs into shipped parts: quote 3D printing, CNC, and decals, then check out.
Instant parametric cost estimates for custom manufacturing: CNC, molding, sheet metal, 3DP, PCB.
Quoting, pricing, production and part data for contract manufacturers (3D printing, CNC).
Quote, purchase, and track custom 3D prints from AIURION in San Francisco.
Add one secure layer between your agents and this server.
