Skip to main content
Glama
mostodont01

prusa-workbench-mcp

by mostodont01
README.md
# prusa-workbench-mcp

Ask Claude to model something (Onshape) and slice it. Claude drives the PrusaSlicer **command line** through an
MCP server — one run per bed, each bed with its own settings — writes the G-code to a job folder, and a small local
viewer app shows the result so you can check it and send it to the printer (Prusa Connect / PrusaLink).

Built for an Original Prusa MINI, but nothing ties it to one printer.

**Status:** steps 1–3 of [PLAN.md](PLAN.md) done: CLI slicing, viewer, MCP server. Sending to the printer is next.

## Setup

Linux, Python 3.11+, PrusaSlicer as a Flatpak (`com.prusa3d.PrusaSlicer`) with your printer set up in it.

```sh
python3 -m venv .venv && .venv/bin/pip install -e .
claude mcp add -s user prusa-workbench -- "$PWD/.venv/bin/prusa-workbench-mcp"
```

## MCP server

Then just ask Claude, e.g. *"slice the fit test on two beds, the pins at 0.15 mm with 4 perimeters"*.
It never starts a print: the result opens in the viewer and you send it from there.

| Tool | What it does |
|---|---|
| `new_job` / `open_job` / `list_jobs` / `get_job` | jobs live in `~/print-jobs/<date>-<name>/` (`job.json` + models), so work can be resumed |
| `list_profiles` / `find_setting` | print profiles + filaments; search PrusaSlicer setting names with their current values |
| `add_model` | STL / 3MF / OBJ / STEP (STEP through PrusaSlicer), with copies |
| `add_from_onshape` | parts straight from an Onshape part studio (API keys from `~/onshape-mcp/.env`) |
| `transform` | rotate, scale, lay flat (largest stable face), move |
| `arrange` / `move_to_bed` / `copy_objects` / `remove_objects` | packing per bed; what doesn't fit goes to a new bed |
| `set_bed` / `remove_bed` | per bed: print profile, filament, any PrusaSlicer setting, supports |
| `set_object_settings` | per object: supports (off / auto / build plate only), angle, infill, perimeters, brim… |
| `preview` | picture of a bed (top + iso, labeled) so Claude can check the layout before slicing |
| `slice` | all beds in parallel, each with its own settings → G-code with thumbnails → viewer |
| `open_viewer` | start / open the viewer |

Each bed is sliced from `bed-N.3mf` (placed objects + per-object settings) and `bed-N.ini` (bed overrides on top
of the profiles); both stay in the job folder next to `bed-N.gcode` and `bed-N.json`.

## Viewer

```sh
python3 -m prusa_workbench.viewer --open        # http://127.0.0.1:8765, reads ~/print-jobs
```

Stdlib only (three.js loads from a CDN, so the browser needs internet). The MCP server starts it by itself.
Options: `--jobs DIR`, `--port N`, `--job NAME`.

- Shows the newest job and follows new ones as they appear; pick an older job in the **Job** menu.
- One tab per bed (`*.gcode` in the job folder). Re-sliced beds reload automatically.
- Toolpaths in PrusaSlicer's colors; click legend items to hide features, tick **Travel** to see travel moves.
- Keys: `↑/↓` layer, `←/→` move within the layer (`Shift` = ×10), `S` single layer, `1/2/3` iso/top/front, `Z` zoom to print.
- Side panel: thumbnail, print time, filament, profiles, settings used (● = changed from the profile), objects with
  their own settings, warnings.

A job folder is just `~/print-jobs/<job>/bed-N.gcode` (+ optional `bed-N.json` summary). G-code dropped in by hand works too.

## Smoke test without Claude

```sh
.venv/bin/python scripts/cli_test.py     # the robocars fit test on 2 beds with different settings
```

## License

[MIT](LICENSE)

TDQS

B3.4/5.0

Scored across 19 tools

Disambiguation4/5

Most tools have clearly distinct purposes across jobs, beds, objects, settings, slicing, and viewing. Mild overlap exists between open_job/get_job and slice/open_viewer, but descriptions make the boundaries reasonably clear.

Naming Consistency4/5

Names are overwhelmingly snake_case and action-oriented, fitting a verb_noun pattern. A few single-word verbs (transform, arrange, preview, slice) and new_job are minor deviations but still readable.

Tool Count4/5

19 tools is at the upper end, but each maps to a real operation in a fairly complex 3D-print job workflow. The set is broad yet not obviously padded.

Completeness4/5

The surface covers the core lifecycle: jobs, beds, objects, profiles/settings, model import, transforms, preview, and slicing. Minor gaps exist around job deletion/renaming/closing and explicit export operations, but core workflows are covered.

Maintenance

ActivityMaintained
ResponsivenessNo issues