Quote and order 3D prints (PETG/ABS) from STL/3MF files, printed and shipped in Norway.
Scored across 5 tools
Each tool targets a distinct action: create_order (order), create_upload_link (file transfer), get_print_quote (pricing a new model), get_print_service_info (static reference), and get_quote_status (lookup by ID). The descriptions explicitly distinguish quote vs status and quote vs order, so an agent can pick correctly.
All five tools follow a clean snake_case verb_noun pattern (create_order, create_upload_link, get_print_quote, get_print_service_info, get_quote_status). Verbs are consistently either create_ or get_ with no mixing of conventions.
Five tools cleanly cover the quote-to-order lifecycle without overlap or redundancy. Each earns its place: quoting, ordering, upload, status, and static service info.
The core flow (upload → quote → order → status) is fully supported, plus a reference info tool. Minor gaps remain, such as no cancel/modify order or list-orders capability, but these are workarounds rather than dead ends.
Place an order for a quote on the user's behalf and get a payment link. Only call this after the user has given you their details and explicitly confirmed that they accept the terms (https://formnord.no/print/vilkar) and have the right to use the model. Returns payment_url, which the user opens to pay with Vipps or card (the order is not paid until they do). Calling it again for the same quote returns the same order. Delivery address must be in Norway. If kode is price_pending, slicing is still confirming the price: wait a minute (or poll get_quote_status) and call again.
| Name | Required | Description | Default |
|---|---|---|---|
| customer | Yes | ||
| quote_id | Yes | tilbud_id from get_print_quote. | |
| accepted_terms | Yes | true only if the user explicitly accepted https://formnord.no/print/vilkar. | |
| confirmed_rights | Yes | true only if the user confirmed they have the right to use and print the model. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| kode | No | Machine-readable error code when ok is false. |
| grunn | No | Human-readable reason (Norwegian) when ok is false. |
| order_id | No | |
| total_nok | No | |
| payment_url | No | The user opens this to pay with Vipps or card. |
| already_ordered | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover idempotency/open-world/destructive, and the description still adds substantial context: the order is not paid until the user opens the link, re-calling for the same quote returns the same order, the delivery address must be in Norway, and the price_pending/kode wait-and-retry behavior. No contradiction with idempotentHint=true or readOnlyHint=false.
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 purpose, then preconditions, then return behavior, then the price_pending edge case. Dense and largely waste-free, though the parenthetical asides make it a touch run-on.
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, yet the description still tells the agent what to do with payment_url (user opens it) and how to interpret the price_pending state. For a nested-object order tool with a payment flow, nothing an agent needs 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 75% and the boolean parameters are already documented in the schema, but the description reinforces their operational meaning (terms acceptance tied to the vilkar URL, rights confirmation, details already collected). It adds framing rather than new field syntax, so slightly short of a 5.
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?
Specific verb+resource: 'Place an order for a quote on the user's behalf and get a payment link.' An agent instantly knows this converts a quote into a paid order, distinct from the read-only siblings get_print_quote/get_quote_status.
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 preconditions ('Only call this after the user has given you their details and explicitly confirmed that they accept the terms... and have the right to use the model'), plus a named alternative for the pending case ('or poll get_quote_status'). When-to-use, when-not, and the fallback are all stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a one-time upload page for the user's model file, for when the user has the file (attached in chat or on their device) and you cannot pass its contents to get_print_quote. Give the user upload_url; when they say it is uploaded, call get_print_quote with upload_id. Accepts STL, 3MF or zip up to 500 MB (large models are simplified automatically for pricing). The link is valid for 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| kode | No | Machine-readable error code when ok is false. |
| grunn | No | Human-readable reason (Norwegian) when ok is false. |
| upload_id | No | |
| expires_at | No | |
| upload_url | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=false, destructive=false, non-idempotent), and the description goes further with real behavioral constraints: single-use link, 24-hour expiry, 500 MB cap, accepted formats (STL, 3MF, zip), and automatic simplification of large models for pricing. It stops short of stating failure/expiry behavior or what happens if a link is regenerated, so a 4 rather than 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?
Dense but waste-free: purpose first, then the workflow routing, then the file/expiry constraints. Every sentence carries an actionable fact; nothing restates the title or schema.
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 zero-parameter, non-destructive creation tool with an output schema present, the description supplies everything an agent needs to decide to call it and what to do afterwards (surface upload_url, await confirmation, then call get_print_quote with upload_id). Return-value detail is correctly 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?
The tool takes zero parameters and the description correctly implies as much, describing the trigger conditions (file present, contents unpassable) rather than any arguments. With no parameters the schema-coverage question is moot, so the baseline 4 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?
States a specific verb+resource ('Create a one-time upload page for the user's model file') and immediately scopes it in contrast to a named sibling: it is for cases where the file exists on the user's side and 'you cannot pass its contents to get_print_quote'. An agent can distinguish it from get_print_quote without opening either 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 ('when the user has the file attached in chat or on their device'), explicit routing to the alternative (get_print_quote) for the other case, and a clear hand-off instruction: give the user upload_url, then call get_print_quote with upload_id once they confirm upload. No inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an instant price for printing a 3D model (STL, 3MF, or a zip containing them, max 300 mm on the longest side) and shipping it within Norway. Provide exactly one of file_url, file_base64, stl_text, upload_id (from create_upload_link) or file_id. Returns tilbud_id (the quote_id), total price in NOK with breakdown, estimated weight and print time, and bestill_url: a page where the user can order themselves. To order on the user's behalf, use create_order. The quote is valid for 14 days.
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | PETG: Svart, Hvit, Grå, Blå, Grønn, Rød. ABS: Svart, Hvit. Default Svart. | |
| colors | No | Multicolour 3MF (Bambu Studio/OrcaSlicer) only: one of our colour names per colour slot in the file, in slot order. Omit to get the nearest available colours (shown in fargeplasser). | |
| infill | No | 15 = light (lightning infill, 3 walls; maps, figures, decor), 20 = standard (most parts), 40 = strong (load-bearing), 100 = solid. | |
| file_id | No | fil_id returned by POST https://formnord.no/api/print/fil (multipart upload), for clients that can send HTTP themselves. | |
| file_url | No | Direct https link to an .stl, .3mf or .zip file up to 500 MB (not a web page about the model; Thingiverse/Printables pages block automated downloads, so use create_upload_link for those). | |
| filename | No | File name, e.g. "holder.stl". | |
| material | No | PETG is the default and suits most parts. ABS for heat resistance. | PETG |
| quantity | No | ||
| stl_text | No | ASCII STL content, for small models you generated. | |
| upload_id | No | upload_id from create_upload_link, after the user has uploaded the file. | |
| zip_entry | No | If the file is a zip with several models: which one to quote (name from the list in the previous error). | |
| file_base64 | No | The model file encoded as base64 (up to 30 MB; use create_upload_link for larger files). |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| kode | No | Machine-readable error code when ok is false. |
| pris | No | Price breakdown in NOK; pris.totalt is the total including shipping. |
| valg | No | Present with kode zip_entry_required. |
| grunn | No | Human-readable reason (Norwegian) when ok is false. |
| tilbud_id | No | quote_id for create_order and get_quote_status. |
| gyldig_til | No | |
| upload_url | No | Present with kode upload_pending. |
| bestill_url | No | |
| prisgrunnlag | No | |
| slicing_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag openWorldHint=true, idempotentHint=false, destructiveHint=false, so the safety profile is partly covered. The description adds real value beyond that: the 14-day quote validity, that it does not place an order, and the 300 mm size constraint. It does not discuss rate limits or failure modes, so it stops short of 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?
Five tight sentences, front-loaded with purpose then constraints then return values, with zero filler. Slightly dense, but every sentence 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?
A no-required-parameter, 12-param tool with a 92% covered schema and an output schema present; the description supplies the missing cross-parameter rule, format constraints, and sibling routing. Nothing an agent needs to invoke it correctly is absent.
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 92%, so the baseline is 3, but the description adds the cross-parameter rule ('provide exactly one of file_url, file_base64, stl_text, upload_id or file_id') and the 300 mm limit, which the schema does not state. That is meaningful semantics beyond the structured fields.
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 ('Get an instant price for printing a 3D model') with scope (Norway shipping, supported formats, size limit). An agent can immediately distinguish it from create_order and get_quote_status.
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 routes to create_order for ordering on the user's behalf, to create_upload_link for pages that block downloads, and states the one-of input constraint. When-to-use and alternatives are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns FormNord 3D printing service details: materials (PETG, ABS) and colours, infill options (15 light / 20 standard / 40 strong / 100 solid %), print settings, maximum size, pricing model, shipping options and delivery time. Delivery to Norway only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral constraint not present in the structured data: delivery to Norway only, plus the concrete enumerations of infill percentages and materials. It does not, however, mention output format or caching/static-ness, which would round this out.
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?
A single dense sentence is front-loaded with the tool's identity before the enumeration, and the geographic restriction is placed last as a qualifier. Every listed item earns its place by telling the agent what data is retrievable, though the run-on enumeration is slightly heavy for one sentence.
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 document return values, yet it helpfully previews the returned content for selection purposes. Nothing critical is missing for a zero-parameter read-only lookup; only explicit sibling routing would improve 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?
The tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly avoids inventing 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?
States a specific verb and resource (returns FormNord printing service details) and enumerates the concrete domains covered: materials, infill levels, settings, max size, pricing model, shipping and delivery time. An agent can immediately distinguish this informational lookup from the transactional siblings create_order, create_upload_link and get_print_quote.
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 informational nature of the tool is implied, but there is no explicit when-to-use guidance or routing against the sibling tools. It never says, for example, to call this before get_print_quote to learn the available materials or infill choices, so the agent must infer the sequencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up an earlier quote by quote_id: price, whether it has expired, whether it has been ordered, and the order status (awaiting payment, queued, shipped).
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | Yes | tilbud_id from get_print_quote. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| kode | No | Machine-readable error code when ok is false. |
| grunn | No | Human-readable reason (Norwegian) when ok is false. |
| utlopt | No | |
| bestilt | No | |
| tilbud_id | No | |
| totalt_kr | No | |
| ordrestatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the read-only, closed-domain profile is covered. The description adds the enumeration of status states (awaiting payment, queued, shipped), but that is return-shape information duplicated by the output schema, and it discloses no permission, freshness, or lookup-failure behavior.
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?
A single compact sentence with the identifier front-loaded and the return facts listed compactly. Slightly dense, but nothing is wasted or buried.
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 one-parameter read tool with annotations and an output schema, the description covers what it does and what it yields. Only the usage relationship to sibling tools is left implicit, which is a small gap.
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 documents quote_id as the tilbud_id from get_print_quote. The description restates 'by quote_id' without adding format, validity, or lookup-scope detail, 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?
States a specific verb (look up) and resource (an earlier quote) and enumerates the returned facts: price, expiry, ordered status, and order state. It is distinguishable from get_print_quote and create_order by implication, but never names a sibling explicitly.
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?
'Look up an earlier quote' and the mention of expired/ordered state imply this is the post-quote status check, and the schema ties quote_id to get_print_quote's tilbud_id. However, no when-to-use condition, prerequisites, or named alternative is stated in the description itself.
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.
get_print_quote2 fields changedInput schema / properties / file_base64 / descriptionPrevious value: -"The model file encoded as base64."New value: +"The model file encoded as base64 (up to 30 MB; use create_upload_link for larger files)."Input schema / properties / file_url / descriptionPrevious value: -"Direct https link to an .stl or .3mf file (not a web page about the model)."New value: +"Direct https link to an .stl, .3mf or .zip file up to 500 MB (not a web page about the model; Thingiverse/Printables pages block automated downloads, so use create_upload_link for those)."create_ordercreate_upload_linkget_print_quoteget_print_service_infoget_quote_statusQuote, check and order 3D prints of STL, 3MF, STEP or OBJ files. Made in the USA, shipped in the US.
SF 3D printing: PLA/PETG, ASA, PPA-CF, TPU 85A & TPU 95A HF. Quote, approve, and track.
Melbourne 3D printing: instant quotes for STL/3MF/STEP (PLA, PETG, TPU), products, order status
Price your own 3D files or Printables/Thingiverse models and get a UK checkout link.
Add one secure layer between your agents and this server.
