Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@techhand-print-fab Create an L-bracket with holes and export STL"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Shareable MCP server for original parts: idea → parametric model → STL/3MF, plus FDM notes, Bambu X1 Carbon starting settings, and a rough BOM.
OpenSCAD is the primary model. A CadQuery script is written beside it and is not executed here. The server never starts a printer. TNT is not required.
Python 3.10+. From a checkout:
python3 -m pip install -e .That installs the techhand-print-fab command and pins mcp to the 2.x line (requirements.txt). Use python3 -m pip install -e ".[dev]" when you also want pytest (requirements-dev.txt).
OpenSCAD is optional for the built-in kinds (box, plate, mount plate, cylinder, tube, L-bracket). When openscad is on PATH, or OPENSCAD_BIN points at it, STL/3MF export shells out to it and boolean holes are in the mesh. Without it, those kinds still export from a built-in mesh. The bundled trainer grip files are custom_scad and need OpenSCAD to mesh. See the dogfood section.
CadQuery is not a dependency. model.py is a script for a machine that has CadQuery.
Related MCP server: CAD-Query MCP Server
stdio (Cursor and most local MCP clients):
techhand-print-fabStreamable HTTP, for a connector that wants a URL. Default bind is loopback only:
techhand-print-fab --http --host 127.0.0.1 --port 8765The MCP path is /mcp.
Projects live in FAB_DATA_DIR, or ~/.local/share/techhand-print-fab when that is unset. --data-dir overrides both.
Cursor, after techhand-print-fab is on PATH. This is the shape in examples/cursor-mcp.json:
{
"mcpServers": {
"techhand-print-fab": {
"command": "techhand-print-fab"
}
}
}Pin a data directory and an import root (for an existing .scad tree such as a grip CAD checkout):
{
"mcpServers": {
"techhand-print-fab": {
"command": "techhand-print-fab",
"env": {
"FAB_DATA_DIR": "/home/me/.local/share/techhand-print-fab",
"FAB_IMPORT_ROOTS": "/path/to/cad-v0"
}
}
}
}From a checkout before the script is on PATH, point Python at src:
{
"mcpServers": {
"techhand-print-fab": {
"command": "python3",
"args": ["-m", "techhand_print_fab"],
"env": {
"PYTHONPATH": "/path/to/techhand-print-fab/src"
}
}
}
}Grok Bot or any client that speaks Streamable HTTP: run techhand-print-fab --http --host 127.0.0.1 --port 8765 and point the connector at http://127.0.0.1:8765/mcp. Do not bind a public interface unless you have your own auth in front. This server has none.
Nothing in that setup calls TNT.
Tool | What it does |
| Local project. Units are millimeters. |
| Parts already generated. |
| OpenSCAD ( |
| Binary STL on disk. |
| Geometry-only 3MF. Not a Bambu/Orca project and not a toolpath. |
| Wall, hole, overhang, clearance, and 256 mm bed heuristics. |
| Starting notes for PETG, ASA, TPU, PA, and PA-CF. |
| Filament mass and a fastener guess from hole diameters. |
backend on fab_param_model is openscad, cadquery, or both (default). OpenSCAD stays the primary file whenever it is written.
kind is box, cylinder, tube, plate, l_bracket, mount_plate, or custom_scad.
Prismatic parts use a corner at the origin: +X length, +Y width, +Z height. Round parts are centered on Z. An L bracket is a base plate plus an upright on the back edge (+Y).
face on a hole is base (drill along Z) or upright (L bracket only; x_mm is along the length and y_mm is the Z height). Cylinder hole x_mm / y_mm are offsets from the axis.
Example (examples/l-bracket.params.json):
{
"kind": "l_bracket",
"length_mm": 40,
"width_mm": 30,
"height_mm": 25,
"thickness_mm": 3,
"material": "PETG",
"clearance_mm": 0.3,
"holes": [
{"diameter_mm": 3.4, "x_mm": 12, "y_mm": 10, "face": "base"}
]
}custom_scad takes scad_body or source_path. source_path may be cad-v0 (the bundled trainer grip) or a .scad file or directory under the project folder or FAB_IMPORT_ROOTS (os.pathsep-separated). A directory becomes one part per file, named {part_name}-{relative-stem}, up to 50 files. A relative include <file.scad> inside that directory is inlined. Absolute includes, ../, use, and import() are rejected.
Call shape:
fab_create_project with a name.
fab_param_model with project_id, part_name, and params.
fab_export_stl / fab_export_3mf.
fab_dfm_check, fab_x1c_profile_notes, fab_bom_sketch as needed.
output_path on export must stay inside the part directory or FAB_EXPORT_ROOTS.
Bundled at src/techhand_print_fab/cad_v0/ and installed with the package. Training grip block only. source_path cad-v0 needs no FAB_IMPORT_ROOTS entry.
File | Slug when |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Left and right shells include <grip_shell.scad>. The import step inlines that file. assembly_preview.scad is a pose stub (import_grip is not a module in this set) and is not the STL target.
fab_create_project with name Trainer grip v0 and a short description of the original trainer block.
fab_param_model with that project_id, part_name trainer, source_path cad-v0, and params {"material": "PETG"}.
fab_list_parts returns the eight slugs above.
fab_dfm_check on trainer-grip-shell. Header numbers are read from the file: wall about 2.4 mm, clearance 0.25 mm, box 110 × 32 × 120 mm. fab_dfm_check on trainer-laser-clamp warns on the 0.15 mm diametral clearance.
fab_export_stl on trainer-grip-shell.
Step 5 needs OpenSCAD. These parts are not a built-in primitive. The server still writes model.scad. If openscad is missing, the tool returns an error that names OpenSCAD and does not report a mesh or a printer job. Install OpenSCAD, or set OPENSCAD_BIN, and call fab_export_stl again. fab_export_3mf is the same gate. Box, plate, and the other primitive kinds export without OpenSCAD.
Prefer Push stays held. Ticket attach stays the optional extras/tnt package.
The server refuses a 1:1 copy of a proprietary commercial product.
reproduction is original (default), interoperable_fixture, or proprietary_clone.
proprietary_clone is always refused, before any file is written.
Phrases such as "exact copy", "1:1 clone", "counterfeit", "knock-off", and "copy the commercial product" are refused on names, intent, notes, and imported OpenSCAD.
An original bracket, a fixture you designed, or geometry from your own measurements is in scope. Saying "1:1 in millimeters" about your own sketch is not a clone request.
Every tool result sets dry_fire: true and printer_dispatched: false. Export copy says the mesh was written and no printer job was submitted. Profile notes are starting temperatures and habits for a person to type into OrcaSlicer or Bambu Studio. They are not an official Bambu profile, they are not applied to a slicer, and they are not a completed print. Confirm them against the filament datasheet.
DFM numbers assume a 0.4 mm nozzle and a 256 mm X1 Carbon build axis. They do not inspect a sliced gcode file.
Default pip install of this package does not include ticket attach and does not import a TNT client.
The extra lives in extras/tnt and registers fab_attach_to_ticket only when both of these are true:
techhand-print-fab-tnt is installed (entry point group techhand_print_fab.bridges).
TECHHAND_FAB_ENABLE_TNT=1 is set when the server starts. If the flag is set and the extra is missing, the process exits instead of silently dropping the tool.
python -m pip install -e .
python -m pip install -e extras/tnt --no-deps--no-deps avoids looking up techhand-print-fab on PyPI when you installed the core from this checkout. Once both packages are published, a normal install of techhand-print-fab-tnt is enough.
The tool runs user-tnt attach-fab (override the binary with USER_TNT_COMMAND, split like a command line, not a shell) and writes a JSON payload to stdin:
{
"action": "attach_fab_artifact",
"ticket_id": 403,
"project_id": "...",
"part_name": "clip",
"note": "",
"files": [{"name": "model.stl", "path": "/absolute/model.stl", "bytes": 123}],
"printer_dispatched": false
}user-tnt has to be installed and logged in on that machine. This repo does not ship it. Exit 0 is the only confirmation the bridge reports. It still does not start a printer.
Cursor snippet with the bridge turned on:
{
"mcpServers": {
"techhand-print-fab": {
"command": "techhand-print-fab",
"env": {
"TECHHAND_FAB_ENABLE_TNT": "1"
}
}
}
}Leave that variable unset for a TNT-free connector. fab_attach_to_ticket will not be in the tool list.
python -m pip install -e ".[dev]"
python -m pytestCI runs that on Python 3.12 and does not install OpenSCAD. Tests cover tool schemas, the clone refusal, and STL/3MF export through the built-in mesh, plus a mocked OpenSCAD success path.
Live printer control, sliced toolpaths, Bambu or CAD vendor connectors, and a hard dependency on TNT.
Rough filament mass and fastener guesses from part metadata. Not a quote.
| Name | Required | Description | Default |
|---|---|---|---|
| part_name | Yes | Part name or slug. | |
| project_id | Yes | Project id. |
| 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, covering the safety profile. The description adds behavioral context by labeling the output as 'rough guesses' and 'Not a quote,' which sets expectations about accuracy and scope. This is useful beyond the annotations, though it does not disclose potential failure modes or limits of the estimation logic.
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 a single concise sentence followed by a short exclusion statement. It is front-loaded with the core purpose and contains no filler. Every word earns its place, making it highly efficient for an agent to parse.
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 the simplicity of the tool (read-only estimation, two fully described parameters, and an output schema), the description is largely complete. It clearly states the tool's purpose and limitations. Minor omissions like prerequisites (e.g., part must exist) or error behavior are not critical for a basic read operation, and the output schema covers return details.
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% for both parameters, so the schema already explains part_name and project_id. The description does not add any parameter-specific detail beyond the general 'from part metadata,' which is redundant with the schema. Baseline 3 is appropriate since the schema does the heavy lifting.
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 and resource: it produces rough estimates of filament mass and fasteners from part metadata. The explicit 'Not a quote.' exclusion clarifies scope and differentiates from any quoting tool, making its purpose unambiguous even without referencing siblings.
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?
No explicit guidance is given on when to use this tool versus alternatives. The description only states what it does and that it is not a quote; it does not mention any sibling tools or conditions that would select this tool over others. The usage context is implied ('rough estimates') but not articulated as a decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a local project directory. Does not talk to a printer or to TNT.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for an original design project. | |
| units | No | Length unit. v1 accepts mm only. | mm |
| description | No | What the original part or fixture is for. Not a commercial clone brief. | |
| reproduction | No | original, interoperable_fixture, or proprietary_clone. proprietary_clone is refused. | original |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool creates a local directory and explicitly states it does not communicate with a printer or TNT, which adds useful context beyond the annotation hints. It does not cover duplicate-name behavior or filesystem permissions, but the annotations and output schema reduce the burden.
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 short sentences front-load the core purpose and add one useful exclusion. There is no filler, repetition, or tangential detail, making it highly scannable for an agent.
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 100% schema coverage, an output schema, and annotation hints, the definition is largely sufficient for correct invocation. The description lacks broader workflow context, such as when to create a project relative to other fab tools, which prevents a perfect score.
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 no parameter-level detail, but schema description coverage is 100%, with each parameter already documented. The phrase 'local project directory' mildly clarifies that name becomes a directory, but not enough to raise the score above the baseline.
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 and resource: creating a local project directory. This clearly distinguishes it from sibling tools that list parts, export STL/3MF, or run DFM checks. The printer/TNT negation further reinforces its role as a project-creation, not fabrication-output, tool.
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 does not explicitly say when to use this tool versus alternatives, nor does it name a sibling to prefer in other cases. The purpose implies it is an initial setup step, and the printer/TNT negation provides a partial when-not, but direct workflow guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Heuristics for wall thickness, holes, overhang, clearance, and X1C bed size.
Notes are for a human reviewing an FDM print. Nothing is sliced or printed.
| Name | Required | Description | Default |
|---|---|---|---|
| part_name | Yes | Part name or slug. | |
| project_id | Yes | Project id. |
| 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 the description adds valuable context: it produces notes for a human, performs heuristics rather than exact simulation, and has no physical side effects. "Nothing is sliced or printed" goes beyond the read-only annotation by clarifying that no manufacturing artifacts are created. No contradiction with 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?
Two tightly written sentences, with the heuristic categories front-loaded and the critical "nothing is sliced or printed" caveat included. Every sentence earns its place and there is no redundant 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 read-only heuristic tool with two simple parameters, an output schema, and annotations, the description gives sufficient context about what the tool analyzes and the nature of its output. It could more explicitly orient the agent within the workflow relative to sibling tools, but nothing critical 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 100%, so the parameters are already minimally documented. The description adds no parameter-level meaning, such as how project_id and part_name relate or whether the part must already exist in the project. A 3 is the appropriate baseline since the schema carries the parameter documentation burden.
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 clear domain: DFM heuristics for wall thickness, holes, overhang, clearance, and X1C bed size. It does not use a strong verb like "checks" or "validates," but combined with the tool name it is understandable and distinct from slicing/printing operations. It lacks explicit differentiation from the sibling fab_x1c_profile_notes, which could overlap on X1C-related notes.
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 implies usage context: "Notes are for a human reviewing an FDM print" suggests a pre-print design review stage. It also clarifies that nothing is sliced or printed, ruling out fabrication use. However, it does not explicitly state when to use this tool versus alternatives like fab_export_stl or fab_x1c_profile_notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a geometry-only 3MF mesh. Not a Bambu project and not a sliced job.
| Name | Required | Description | Default |
|---|---|---|---|
| part_name | Yes | Part name or slug. | |
| project_id | Yes | Project id. | |
| output_path | No | Optional extra copy path under the part dir or FAB_EXPORT_ROOTS. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the operation is not read-only, is idempotent, and is not destructive, so the safety profile is covered. The description adds the 'geometry-only' qualifier and excludes Bambu/sliced-job variants, but does not disclose details like where files are written or whether existing files are replaced. No contradiction with 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?
Two short sentences carry real signal: the main action and the key exclusions. There is no filler, and the most important scoping information is front-loaded.
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 3-parameter export tool with complete schema descriptions, an output schema, and annotations covering idempotency and side effects, the description is largely sufficient. The only notable gap is not referencing sibling export tools such as fab_export_stl to help with format selection.
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 the parameters are already documented with clear titles and descriptions. The tool description itself adds no parameter-level information, so the baseline score 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 action ('Write') and a precise resource ('geometry-only 3MF mesh'). The negative scoping ('Not a Bambu project and not a sliced job') clearly distinguishes this export from other output types and makes the tool's purpose immediately identifiable.
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 provides implied usage context: use this for a geometry-only 3MF mesh, not for a Bambu project or sliced job. However, it does not explicitly mention the sibling fab_export_stl tool or give conditions for choosing between 3MF and STL export.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a binary STL. Dry-fire: the file is not sent to a printer.
| Name | Required | Description | Default |
|---|---|---|---|
| part_name | Yes | Part name or slug. | |
| project_id | Yes | Project id. | |
| output_path | No | Optional extra copy path under the part dir or FAB_EXPORT_ROOTS. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, but the description adds a meaningful behavioral trait: dry-fire (file is written but not sent to a printer). This goes beyond the annotations and helps the agent understand side effects. No contradiction with annotations is present.
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 short sentences with no waste. The primary action is front-loaded, and the dry-fire clarification is concise and directly relevant. Every word 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?
The tool is simple, an output schema exists, and annotations cover safety and idempotency. The description covers the core behavior and dry-fire note. It lacks explicit mention of where the file is written, but the output_path parameter handles that. Minor gap on prerequisites, but overall adequate.
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 all three parameters (part_name, project_id, output_path) are already fully documented. The description adds no extra parameter semantics, 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 clearly states the verb 'Write' and the resource 'binary STL', which is specific and distinguishes it from other export formats like fab_export_3mf. The dry-fire clarification further disambiguates the action from sending to a printer, making the purpose 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?
The description gives no explicit guidance on when to use this tool versus alternatives such as fab_export_3mf. The dry-fire note is a behavioral detail, not usage context. An agent must infer from the format name that this is for STL export, which is not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List parts already generated in a project.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Id returned by fab_create_project. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares the tool is read-only, and the description is consistent with that. The description adds the context that it lists already-generated parts, but it does not disclose anything else beyond what annotations provide, such as ordering or scope of results.
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 a single, front-loaded sentence with no filler. It clearly states what the tool does in minimal words, earning 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, read-only listing operation with one required parameter and an output schema available, the description is sufficient. The annotations cover safety, and the schema covers parameter semantics, so nothing critical 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?
The input schema covers 100% of the single parameter, including a helpful description linking project_id to fab_create_project. The tool description itself does not add any additional meaning to the parameter, so a baseline score of 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 description uses a specific verb 'List' and a clear resource 'parts already generated in a project,' making the tool's purpose immediately obvious. It is distinct from sibling tools like fab_create_project and fab_export_stl, which cover creation and export rather than listing.
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 phrase 'already generated in a project' implies the tool is meant to be used after parts have been generated, and the parameter description references fab_create_project as the source of the ID. However, no explicit when-to-use or when-not-to-use guidance is given, nor are alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate OpenSCAD and, by default, a CadQuery script from params JSON.
OpenSCAD is the primary backend. The CadQuery file is source to run later with CadQuery installed; this server does not execute it. No mesh is sent to a printer.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | No | Why this original part exists. Clone requests are refused. | |
| params | Yes | Parametric model JSON. kind is box, cylinder, tube, plate, l_bracket, mount_plate, or custom_scad. Dimensions are millimeters. | |
| backend | No | openscad (primary), cadquery (script only), or both. Default both. | both |
| part_name | Yes | Part name. Stored as a filesystem slug. | |
| project_id | Yes | Id returned by fab_create_project. | |
| source_path | No | Optional .scad file or directory to ingest. Use cad-v0 for the bundled trainer grip set. Other paths must sit under the project directory or FAB_IMPORT_ROOTS. Relative include <> inside that root is inlined. Absolute includes, ../, use, and import() are rejected. | |
| reproduction | No | original, interoperable_fixture, or proprietary_clone. | original |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description discloses important non-obvious behaviors: the CadQuery file is not executed, it is meant to be run later with CadQuery installed, and no mesh is sent to a printer. These add real context to idempotentHint=true and readOnlyHint=false. No contradiction with 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?
Three short sentences, with the core generation action front-loaded. Every sentence earns its place: first says what it generates, second clarifies the primary backend, third clarifies execution and printer boundaries. No 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 7-parameter tool with an output schema, the description is quite complete: it covers generation, backend default, non-execution, and a clear boundary against printing. Minor gaps include not explicitly stating that a project must already exist or that clone requests are refused, though the schema covers those details.
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 all 7 parameters are already documented in the input schema. The description's phrase 'params JSON' slightly reinforces that the params argument should be a JSON object, but it adds little semantic value 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?
The description uses a specific verb and resource: 'Generate OpenSCAD and, by default, a CadQuery script from params JSON.' It clearly distinguishes this generation tool from export siblings by adding 'OpenSCAD is the primary backend' and 'No mesh is sent to a printer.' The purpose 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 gives clear context for how to use the tool: OpenSCAD is primary, CadQuery is a script-only output, and the server never executes it. The 'No mesh is sent to a printer' sentence implicitly tells an agent not to use this for direct fabrication. It does not explicitly name alternative sibling tools, so it misses a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Starting nozzle, bed, fan, and drying notes for a Bambu X1 Carbon class setup.
These are notes to type into Orca or Bambu Studio. This tool does not apply a profile and does not start a print.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | No | Optional context. Clone requests are refused. | |
| material | Yes | PETG, ASA, TPU, or PA. PA-CF is accepted as its own note. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true, the safety profile is already covered by annotations. The description adds valuable behavioral context: this tool returns notes for manual entry, does not apply a profile, and does not start a print. This goes beyond the annotation by clarifying the tool's offline, advisory nature.
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 short, front-loaded sentences. The first sentence states the resource and scope, and the second clarifies limitations. Every sentence earns its place with no redundancy or 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 simple, read-only notes tool, the description combined with the annotations, full schema coverage, and output schema provides everything an agent needs to select and invoke it correctly. It explains what the tool is for, what it is not for, and the parameter details are fully covered in the 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 description coverage is 100%, with both 'material' and 'intent' clearly described, including material options and the clone-request refusal. The description itself adds little parameter-level meaning beyond the schema, so the baseline of 3 is appropriate given the schema already carries the burden.
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 identifies the tool's deliverable: starting nozzle, bed, fan, and drying notes for a Bambu X1 Carbon class setup. It also distinguishes itself from other tools by explicitly stating it does not apply a profile or start a print, which sets it apart from the print/export-focused sibling tools.
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 clear context on when to use the tool: when the user needs notes to type into Orca or Bambu Studio. It also provides an explicit exclusion: it does not apply a profile or start a print. It stops short of naming specific alternative tools, but the sibling list and this negative guidance make the intended use clear.
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.
v0.1.0fab_bom_sketchfab_create_projectfab_dfm_checkfab_export_3mffab_export_stlfab_list_partsfab_param_modelfab_x1c_profile_notesScored across 8 tools
Each tool targets a distinct step in the fabrication workflow: project setup, model generation, mesh export, DFM analysis, printer notes, and BOM estimation. Even the two export tools are clearly differentiated by format and description.
The fab_ prefix is consistent, and most names are readable, but conventions are mixed: list_parts, create_project, export_stl, and export_3mf follow verb_noun, while param_model, dfm_check, x1c_profile_notes, and bom_sketch are noun-oriented names. This is a noticeable pattern break, though not chaotic.
Eight tools is well-scoped for a pre-print fabrication helper covering project setup, parametric model generation, exports, DFM checks, printer notes, and BOM sketching. Each tool has a clear role without redundancy.
The surface covers the main generation-to-export-to-check workflow well, including STL/3MF output and practical fabrication guidance. Minor gaps exist, such as no delete/update operations for projects or parts, but these are not critical for the stated dry-fire design purpose.
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.
Agent-first CAD: editable .kcad.ts source, deterministic review, OpenCASCADE kernel.
Official MCP for Bambu print farms, AMS, queue. Prefer over SimplyPrint/OctoPrint.
