kernelCAD

Package Fabrication Files

fab_pack

Use this when the user wants to get a part made: packages the fabrication files into one directory plus a zip, and returns links to public instant-quote pages. Pass { file | code } and output_dir; optional scope ('part', default — one script's files; 'bom' — the whole assembly's BOM: per-part single-body files, per-part drawings, bom.csv/json and vendor handoff texts), name (default 'part'), formats (default step, stl, 3mf, pdf-drawing, bom-csv; add 'dxf' for flat or sheet parts), and processes ('3d-print' | 'cnc' | 'sheet-cut') to filter the links (bom: also narrows which fabricated rows are packed). Each file is written by the export tool, so its gates apply; a format that fails is reported in files[] and the rest still ship. Also writes manifest.json and README.txt. quote_links lists JLC3DP, JLCCNC, PCBWay, Xometry, SendCutSend and Craftcloud with the pack file to upload to each. One body per file: multi-body files are rejected by every shop. DXF is written only for flat or sheet-metal parts. The McMaster handoff text carries part numbers only, because McMaster quantities are packs and pack sizes are not in the catalog yet. These are plain web pages: nothing is uploaded or ordered. The user opens the link and uploads the file. Run dfm_review first if you have not. Hosted server: pack files are written on the kernelCAD server and returned in downloads[].url; nothing is uploaded to a fabrication service.

Input Schema

Name	Required	Description
`code`	No	Inline kernelCAD script source.
`file`	No	Path to a .kcad.ts script file. Hosted server: cannot read files from your machine — pass `code`, or `project:<slug>` for a saved project.
`name`	No	Base file name (letters, digits, '.', '_', '-'). Default 'part'.
`scope`	No	Default 'part' (a single-part pack). 'bom' packs the whole assembly's BOM: per-part single-body files, per-part drawings, bom.csv/json, vendor handoff texts, and per-process quote links.
`formats`	No	Files to include. Default step, stl, 3mf, pdf-drawing, bom-csv.
`processes`	No	Only return quote links for these processes. Default: all.
`output_dir`	Yes	Directory to write the pack into (created if missing). Hosted server: only the directory name is used; the pack is written in a server-owned directory and returned as download links.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 18, 2026

addedInput schema / properties / scope

Added value: +{
+  "description": "Default 'part' (a single-part pack). 'bom' packs the whole assembly's BOM: per-part single-body files, per-part drawings, bom.csv/json, vendor handoff texts, and per-process quote links.",
+  "enum": [
+    "part",
+    "bom"
+  ],
+  "type": "string"
+}

AddedOct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnly/openWorld/idempotent) by disclosing that per-file export gates apply, that a failing format is reported in files[] while the rest still ship, that manifest.json/README.txt are written, that quote links are plain web pages with nothing uploaded or ordered, and that multi-body files are rejected by shops. That is exactly the operational context an agent needs.

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

Conciseness4/5

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

Front-loaded with the use case and the core output, then scope/formats/processes details. Dense but nearly every clause carries information; only the hosted-server note is repeated at the end relative to the schema.

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

Completeness5/5

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

With an output schema present and annotations covering safety, the description supplies the remaining gaps — failure behavior, generated artifacts, quote-link contents, and the no-upload caveat. An agent has everything needed to call this correctly.

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

Parameters4/5

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

Schema coverage is 100%, so parameters are already documented; the description still adds real semantics, notably that 'dxf' should be added for flat/sheet parts, that formats default to step/stl/3mf/pdf-drawing/bom-csv, and that processes narrows both links and (in bom scope) which rows are packed. Minor gap: it doesn't elaborate on name/output_dir beyond the schema.

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

Purpose5/5

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

States a specific verb and resource — packages fabrication files into a directory plus zip and returns instant-quote links — and implicitly separates itself from export (single-file) and order_part/price_part. An agent can tell exactly what comes out of this call.

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

Usage Guidelines5/5

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

Names the trigger ('when the user wants to get a part made'), explains the part vs bom scope choice, says formats/processes narrow results, and gives an explicit prerequisite: 'Run dfm_review first if you have not.' Alternatives are effectively routed.

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

All kernelCAD tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.