Skip to main content
Glama
KD5RYN

b123d-print-mcp

by KD5RYN
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

export

Export printable 3D parts to organized folders as STEP, STL, 3MF, or PNG, plus print sheets, BOMs, images, and browser 3D views, ready for slicing or download.

Instructions

Export printable parts to parts//out/, sorted: print/ (3MF, STL, print sheet: for the slicer), cad/ (STEP, GLB), images/, docs/ (BOM, view HTML), README.md. Default: every part, all variants. The files must reach the user: on a remote server download_part brings them home. parts: comma-separated part names from build() to build and export only those; variant: one variant. Uses the pieces cached by an earlier build and leaves files already up to date as they are (templates too); fresh=True builds and writes everything again. formats: comma-separated from step (other CAD: Onshape, Fusion, FreeCAD), stl and 3mf (slicers; 3MF keeps units), png (6-view preview + section views), glb (binary glTF, for web and 3D apps), print (the print sheet, [_]print.md: size, filament and time estimates, supports, tip-over, walls and infill, fits and hole compensation, PRINT_NOTES, for the slicer, including declared hardware), hardware (versioned whole-assembly BOM JSON, []hardware.json), bom and bom_csv (the shopping list of that hardware as a Markdown table, []_bom.md, and as CSV, _bom.csv; hardware_list returns it in the result), or 'all'. Omit to use the user's formats setting (default: step, stl, 3mf and png). Ask the user which they want if unclear. view: a 3D view the user can turn in a browser, per variant: 'print' (default: the printable parts on the bed), 'assembly' (assembly(d) with its stand-ins) or 'none'. Over HTTP it is a signed link (no token, expires like the downloads); locally a self-contained HTML file in out/docs/ (works offline). Offer it to the user after an export. Over HTTP (a remote server) each file comes with a download link (no token needed, expires) and a b123d-print://files/ resource link; download_part gets the whole part (script, out/, ref/) in one zip. embed=True also puts files up to 2 MB into the result itself, for clients that can neither fetch URLs nor read resources. Before export, ALWAYS: check passes, design_metrics(name, style=...), suggest_orientation(name) (the "Before printing" block of build_part and check lists what is missing). With the review setting "warn" (default) export says what was skipped, here and on the print sheet; with "required" it refuses until the steps are done. skip_review: only when the user said to export without them, their reason (recorded on the print sheet). Remote server (HTTP/SSH): the files stay on the server, as a temporary working copy deleted when unused; bring the part home with download_part (one zip in the parts// layout). Never use ssh, scp or a shell on the server: there is none.

Input Schema

NameRequiredDescriptionDefault
nameYes
viewNoprint
embedNo
freshNo
partsNo
formatsNo
variantNo
skip_reviewNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.15
    • addedInput schema / properties / skip_review
      Added value: +{
+  "default": "",
+  "title": "Skip Review",
+  "type": "string"
+}
  2. First observedv0.3.12

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the behavioral burden and does so thoroughly: it discloses caching, fresh rebuild behavior, review warn/required semantics, skip_review recording, remote temporary working copies, signed expiring links, and embed limits. It also warns never to use ssh, scp, or a shell on the server.

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?

The description is front-loaded with the export destination and default behavior, and most details are useful. It is still long and dense, with many parenthetical clauses packed into run-on sentences.

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?

For a complex 8-parameter export tool with no output schema and no annotations, the description is highly complete: it explains outputs, default behavior, remote-server behavior, download links, review prerequisites, and safety constraints.

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 description coverage is 0%, so the description must compensate. It richly defines almost every parameter (parts, variant, formats, view, embed, fresh, skip_review), though the required name parameter is only implied through parts/<name>/ rather than explicitly defined.

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: export printable parts to a defined output directory layout. It distinguishes the operation from sibling download_part by explaining that export writes files, while download_part brings them home on a remote server.

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?

Explicitly says when to use it, what must happen before export (check passes, design_metrics, suggest_orientation), and how review settings affect behavior. It also names download_part as the remote retrieval alternative and instructs the agent to ask the user about unclear formats.

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

Deploy Server

Other Tools