Thank You To FULU And Louis Rossmann

Thank you to the FULU Foundation and Louis Rossmann for standing up for consumer ownership, open source developers, repair rights, and users who should not have working hardware made worse by locked-down software. This MCP server treats the FULU OrcaSlicer-bambulab fork as a first-class Bambu project slicer target.

MCP 3D Printer Server

✨ What's New / Significant Updates (as of last session)

• Dual Local Transports: Added explicit stdio and streamable-http runtime modes with environment-based transport selection.
• FULU OrcaSlicer-bambulab Support: Added orcaslicer-bambulab / fulu_orca slicer support for Bambu project 3MF export, and made it the default Bambu slicer target when no slicer is configured.
• Bambu Reliability Pass: Fixed Bambu argument wiring bugs, added FTP-backed file operations, improved status refresh behavior, and implemented practical command paths for startJob, setTemperature, and print_3mf.
• Blender Bridge Tooling: Added blender_mcp_edit_model with optional execution mode for model-edit collaboration workflows.
• Transport Behavior Tests: Added real behavior tests for both transports (initialize, tools/list, success + failing tools/call, origin rejection).
• Docker Modernization: Updated Docker build flow to work without BuildKit-specific features and verified streamable HTTP initialization in container smoke testing.

🗺️ Roadmap / TODO

• Achieve Feature Parity: Bring functionality (status detail, file operations, direct printing where possible, preset handling) for OctoPrint, Klipper, Duet, Repetier, Prusa Connect, and Creality Cloud up to the level of robustness planned for the Bambu implementation.
• Implement Full Bambu MQTT Status: Refactor getStatus for Bambu to subscribe to MQTT reports and maintain real-time state.
• Implement Robust AMS Mapping: Replace placeholder logic; correctly parse and use AMS mapping from .3mf slicer config or user overrides for the MQTT print command.
• Implement .3mf Print Overrides: Add logic to the print_3mf tool to handle user-provided overrides (e.g., calibration flags) and potentially common slicer settings if feasible via MQTT/G-code.
• Calculate MD5 Hash: Add logic to calculate and include the MD5 hash of the .3mf file in the MQTT print command (optional but recommended by protocol).
• Refactor Bambu File Ops: Investigate replacing bambu-js FTP operations (getFiles, uploadFile) with direct MQTT methods if possible/stable, or contribute FTPS support to bambu-js.
• Add Preset Discovery Logic: Improve preset resource listing (currently lists based on potential filenames, could parse index files if they exist).
• Expand .3mf Support: Add .3mf printing support for other printer types where applicable.
• Error Handling & Reporting: Enhance MQTT error handling and reporting of print progress/completion.
• Testing: Conduct thorough runtime testing of all new Bambu features.

Click to expand Table of Contents

Table of Contents

• Description
• Features
• Installation
  • Prerequisites
  • Install from npm
  • Install from source
  • Running with Docker
    • Using Slicers with Docker
• Configuration
• Usage
• Supported Printer Management Systems
  • OctoPrint
  • Klipper (via Moonraker)
  • Duet
  • Repetier
  • Bambu Labs
    • Finding Your Bambu Printer's Serial Number and Access Token
    • Bambu Communication Notes (MQTT & FTP)
  • Prusa Connect
    • Setting up Prusa Connect
  • Creality Cloud
    • Setting up Creality Cloud
• Available Tools
  • STL Manipulation Tools
  • Printer Control Tools
  • Bambu-Specific Tools
• Available Resources
  • Printer Resources
  • Bambu Preset Resources
• Example Commands for LLM
• Bambu Lab Printer Limitations
• Limitations and Considerations
  • Memory Usage
  • STL Manipulation Limitations
  • Visualization Limitations
  • Performance Considerations
  • Testing Recommendations
• Appendix: MCP Safety Notes
• Badges
• License

Description

This is a server that allows MCP users to connect with the API endpoints of these 3D Printers:

• OctoPrint
• Klipper (Moonraker)
• Duet
• Repetier
• Bambu Labs
• Prusa Connect
• Creality/Ender

This server is a Model Context Protocol (MCP) server for connecting Claude with 3D printer management systems. It allows MCP to interact with 3D printers through the APIs of various printer management systems such as OctoPrint, Klipper (via Moonraker), Duet, Repetier, and Bambu Labs printers.

Note on Resource Usage: This MCP server includes advanced 3D model manipulation features that can be memory-intensive when working with large STL files. Please see the "Limitations and Considerations" section for important information about memory usage and performance.

Features

• Get printer status (temperatures, print progress, etc.)
• List files on the printer
• Upload G-code files to the printer
• Start, cancel, and monitor print jobs
• Set printer temperatures
• Advanced STL file manipulation:
  • Extend base for better adhesion
  • Scale models uniformly or along specific axes
  • Rotate models around any axis
  • Translate (move) models
  • Modify specific sections of STL files (top, bottom, center, or custom)
• Comprehensive STL analysis with detailed model information
• Generate multi-angle SVG visualizations of STL files
• Real-time progress reporting for long operations
• Error handling with detailed diagnostics
• Slice STL files to generate G-code
• Confirm temperature settings in G-code files
• Complete end-to-end workflow from STL modification to printing
• Print .3mf files directly on Bambu Lab printers (via MQTT command)
• Slice Bambu projects with FULU OrcaSlicer-bambulab (SLICER_TYPE=orcaslicer-bambulab) and auto-slice unsliced 3MF files before Bambu printing when a project slicer is configured
• Inspect and probe the FULU BambuNetwork runtime (check_fulu_orca_setup) and call safe-by-default FULU bridge RPC methods for diagnostics and development (fulu_bambu_network_rpc)
• Read Bambu Studio preset files (printer, filament, process) as resources

Installation

Prerequisites

• Node.js 18 or higher
• npm or yarn

Install from npm

npm install -g mcp-3d-printer-server

Install from source

git clone https://github.com/dmontgomery40/mcp-3d-printer-server.git
cd mcp-3d-printer-server
npm install
npm link  # Makes the command available globally

Running with Docker

You can also run the server using Docker and Docker Compose for a containerized environment.

1. Ensure you have Docker and Docker Compose installed.
2. Copy .env.example to .env and configure your settings.
3. Build and run the container:

   docker-compose up --build -d
   

Using Slicers with Docker

Please note that the default Docker setup cannot directly use a slicer installed on your host machine. Mounting the slicer executable directly from the host into the container is unreliable due to operating system and library differences between your host and the container.

The recommended approach is to install your preferred slicer inside the Docker image. This makes the container self-sufficient.

To do this, you will need to modify the Dockerfile. Here's a conceptual example of how you might add PrusaSlicer, OrcaSlicer, or the FULU OrcaSlicer-bambulab build (specific commands may vary depending on the slicer, its dependencies, and current Alpine packages):

# ... other Dockerfile commands ...

# Example: Install PrusaSlicer, OrcaSlicer, or FULU OrcaSlicer-bambulab (adjust command as needed)
# Check Alpine package repositories first (e.g., apk add prusaslicer or apk add orcaslicer)
# If not available, download and install manually (e.g., AppImage):
# RUN apk add --no-cache fuse # FUSE might be needed for AppImages
# RUN wget https://example.com/path/to/OrcaSlicer_Linux_Vxxxx.AppImage -O /usr/local/bin/orcaslicer && \
#     chmod +x /usr/local/bin/orcaslicer

# Set the SLICER_PATH env var accordingly in docker-compose.yml or when running
# Example for installed executable:
ENV SLICER_PATH=/usr/local/bin/orcaslicer 

# ... rest of Dockerfile ...

After modifying the Dockerfile, rebuild your image (docker-compose build). You'll also need to ensure the SLICER_PATH environment variable in your .env file or docker-compose.yml points to the correct path inside the container (e.g., /usr/local/bin/orcaslicer). For the FULU Bambu-enabled fork, set SLICER_TYPE=orcaslicer-bambulab.

Apologies for not including a specific slicer out-of-the-box, but given the wide variety of slicers (PrusaSlicer, OrcaSlicer, Cura, etc.) and configurations available, pre-installing one would unnecessarily bloat the image for many users. If a particular slicer becomes a very common request, I can certainly look into adding official support for it in a future version.

Configuration

Create a .env file in the directory where you'll run the server or set environment variables:

# Required for authentication with your printer management system
API_KEY=your_api_key_here

# Default printer connection settings
PRINTER_HOST=localhost
PRINTER_PORT=80 # Port for non-Bambu HTTP APIs
PRINTER_TYPE=octoprint  # Options: octoprint, klipper, duet, repetier, bambu, prusa, creality

# Optional: Directory for temporary files
TEMP_DIR=/path/to/temp/dir

# Bambu Labs specific configuration
BAMBU_SERIAL=your_printer_serial # REQUIRED for Bambu
BAMBU_TOKEN=your_access_token    # REQUIRED for Bambu
BAMBU_MODEL=p1s                  # REQUIRED for Bambu: p1s, p1p, x1c, x1e, a1, a1mini, h2d
BED_TYPE=textured_plate          # Bed plate: textured_plate, cool_plate, engineering_plate, hot_plate
NOZZLE_DIAMETER=0.4              # Nozzle diameter in mm (default: 0.4)

# Slicer configuration (for slice_stl tool)
# For Bambu projects, the default is orcaslicer-bambulab unless SLICER_TYPE is set.
SLICER_TYPE=orcaslicer-bambulab  # Options: prusaslicer, cura, slic3r, orcaslicer, orcaslicer-bambulab, bambustudio
SLICER_PATH=/path/to/slicer/executable
SLICER_PROFILE=/path/to/slicer/profile

# Optional aliases for FULU OrcaSlicer-bambulab when SLICER_PATH is not set
FULU_ORCA_PATH=/path/to/FULU/OrcaSlicer
ORCASLICER_BAMBULAB_PATH=/path/to/FULU/OrcaSlicer
FULU_ORCA_PLUGIN_DIR=/path/to/FULU/OrcaSlicer.app/Contents/MacOS
ORCASLICER_BAMBULAB_PLUGIN_DIR=/path/to/FULU/OrcaSlicer.app/Contents/MacOS

# Optional FULU BambuNetwork bridge runtime
# macOS default runtime dir:
# /Users/you/Library/Application Support/OrcaSlicer/macos-bridge/runtime
PJARCZAK_MAC_RUNTIME_DIR=
FULU_BAMBU_BRIDGE_COMMAND=

# Optional: Path to Bambu Studio user config dir (for loading presets)
# Example macOS: /Users/your_user/Library/Application Support/BambuStudio/user/YOUR_USER_ID
# Example Windows: C:\Users\your_user\AppData\Roaming\BambuStudio\user\YOUR_USER_ID
# Example Linux: /home/your_user/.config/BambuStudio/user/YOUR_USER_ID
BAMBU_STUDIO_CONFIG_PATH=

# MCP transport configuration
MCP_TRANSPORT=stdio             # Options: stdio, streamable-http
MCP_HTTP_HOST=127.0.0.1
MCP_HTTP_PORT=3000
MCP_HTTP_PATH=/mcp
MCP_HTTP_STATEFUL=true
MCP_HTTP_JSON_RESPONSE=true
MCP_HTTP_ALLOWED_ORIGINS=http://localhost

# Optional bridge command for blender_mcp_edit_model execute=true mode
BLENDER_MCP_BRIDGE_COMMAND=

# Accept per-call executable selectors instead of reading commands and paths
# from server environment configuration. Off by default: slicer_path,
# bridge_command, and active-probe path overrides can select which local
# executable launches. MCP_ALLOW_BRIDGE_COMMAND_ARG remains a legacy alias for
# bridge commands and bridge-derived probe paths only.
MCP_ALLOW_EXECUTABLE_ARG=false

Usage

Add this server to your MCP client's config (Claude Desktop, Claude Code, Cursor, Codex, or any MCP-compatible client). Most JSON-based clients use an mcpServers entry with the command and env vars:

{
  "mcpServers": {
    "3dprint": {
      "command": "npx",
      "args": ["-y", "mcp-3d-printer-server"],
      "env": {
        "PRINTER_HOST": "your_printer_ip",
        "PRINTER_TYPE": "bambu",
        "BAMBU_SERIAL": "your_printer_serial",
        "BAMBU_TOKEN": "your_access_token",
        "BAMBU_MODEL": "p1s",
        "SLICER_TYPE": "orcaslicer-bambulab",
        "SLICER_PATH": "/path/to/FULU/OrcaSlicer",
        "FULU_ORCA_PLUGIN_DIR": "/Applications/OrcaSlicer.app/Contents/MacOS"
      }
    }
  }
}

For non-Bambu printers, replace the Bambu-specific env vars with API_KEY and the appropriate PRINTER_TYPE (see Supported Printer Management Systems).

FULU OrcaSlicer-bambulab

Use FULU-Foundation/OrcaSlicer-bambulab as the first-class Bambu project slicer by setting:

PRINTER_TYPE=bambu
SLICER_TYPE=orcaslicer-bambulab
SLICER_PATH=/path/to/FULU/OrcaSlicer
FULU_ORCA_PLUGIN_DIR=/path/to/FULU/runtime/payload
BAMBU_MODEL=p1s

Accepted aliases include fulu_orca, fulu-orca, orca-studio, and orca_bambulab. For Bambu printers, this is the default slicer family when SLICER_TYPE is not set.

What the integration does:

• slice_stl uses the FULU/Orca project CLI shape (--slice 0 --export-3mf) to produce a sliced Bambu-compatible 3MF.
• print_3mf can auto-slice an unsliced 3MF through FULU OrcaSlicer-bambulab, then upload and start the sliced project through this server's Bambu print path.
• check_fulu_orca_setup verifies the FULU executable, platform runtime payload, setup commands, and optional BambuNetwork bridge handshake.
• fulu_bambu_network_rpc can call the FULU bridge protocol for diagnostics and development. Read-only methods are allowed by default; mutating methods require allow_mutating_method=true; FULU print methods still require bambu_model.

What stays deliberately explicit:

• This MCP server's existing Bambu print path is local MQTT plus FTPS and still needs BAMBU_SERIAL, BAMBU_TOKEN, and PRINTER_HOST.
• FULU's BambuNetwork bridge is a separate runtime. The MCP can inspect it, probe it, and issue guarded bridge RPC calls, but it will not silently switch a print from local LAN control to cloud/BambuNetwork control.
• BAMBU_MODEL remains mandatory for Bambu print operations because wrong machine presets can produce dangerous G-code.

Current Bench Test Status

This integration has been tested against the current FULU macOS release artifacts and a local Benchy smoke test. The MCP-side bug found during that bench was real: Bambu-family project slicers must use Orca/Bambu preset JSON with --load-settings, not the invalid --load-machine flag. That is fixed here.

The old Bambu Studio fallback still works. Set:

SLICER_TYPE=bambustudio
SLICER_PATH=/Applications/BambuStudio.app/Contents/MacOS/BambuStudio

With that fallback, the same Benchy 3MF sliced successfully through Bambu Studio's CLI into a Bambu-compatible project 3MF. This is the known-good path while FULU platform packaging settles.

macOS is not proven green yet. On this Mac, the FULU arm64 and x86_64 macOS release bundles hit the same CLI slice problem during Benchy testing: one path crashed with SIGSEGV inside OrcaSlicer CLI processing, and repeated attempts left uninterruptible macOS UE processes that ignored SIGKILL. The MCP now avoids pretending that is solved. check_fulu_orca_setup can inspect the bundle and bridge payload, but macOS users should treat FULU CLI slicing as active feedback territory until FULU ships a stable macOS CLI/runtime combination.

We need Windows testers. The WSL 2 setup path, payload checks, and bridge command shape are represented in this MCP, but the full Windows path still needs real reports from people who can validate install_runtime.ps1, verify_runtime.ps1, bridge probing, CLI slicing, and a known-safe print workflow on their own machine.

We will keep iterating with user and contributor feedback. Please report the OS, CPU architecture, FULU release asset name, check_fulu_orca_setup result, slicer command stderr, and whether the Bambu Studio fallback works on the same model.

FULU Runtime Setup By Platform

The FULU README currently says macOS is work in progress, but the source tree already ships macOS Lima runtime scripts and Windows WSL runtime scripts. This MCP knows those file layouts and returns the exact commands through check_fulu_orca_setup.

Windows:

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

Restart Windows, then run the FULU package scripts from the directory that contains install_runtime.ps1:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\install_runtime.ps1 -PackageDir . -PluginDir .
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\verify_runtime.ps1 -PackageDir . -PluginDir .

Linux:

Install the FULU OrcaSlicer-bambulab build normally, set SLICER_TYPE=orcaslicer-bambulab, and point SLICER_PATH at the executable. If you want bridge-level diagnostics, set FULU_BAMBU_BRIDGE_COMMAND to the packaged pjarczak_bambu_linux_host.

macOS:

Set the app payload directory, then run the scripts that FULU copies into the app bundle:

export FULU_ORCA_PLUGIN_DIR="/Applications/OrcaSlicer.app/Contents/MacOS"
bash "$FULU_ORCA_PLUGIN_DIR/install_runtime_macos.sh" -PackageDir "$FULU_ORCA_PLUGIN_DIR" -PluginDir "$FULU_ORCA_PLUGIN_DIR"
bash "$FULU_ORCA_PLUGIN_DIR/verify_runtime_macos.sh" -PackageDir "$FULU_ORCA_PLUGIN_DIR" -PluginDir "$FULU_ORCA_PLUGIN_DIR"

The default installed runtime is:

~/Library/Application Support/OrcaSlicer/macos-bridge/runtime

The bridge command shape is:

"/Applications/OrcaSlicer.app/Contents/MacOS/pjarczak-bambu-linux-host-wrapper" "$HOME/Library/Application Support/OrcaSlicer/macos-bridge/runtime/pjarczak_bambu_linux_host"

If your app is named Orca Studio.app or lives somewhere else, pass its real Contents/MacOS path as plugin_dir or FULU_ORCA_PLUGIN_DIR.

Check The Setup Through MCP

Ask your MCP client to call check_fulu_orca_setup, or call it from an agent with arguments like:

{
  "platform": "darwin",
  "slicer_path": "/Applications/OrcaSlicer.app/Contents/MacOS/OrcaSlicer",
  "plugin_dir": "/Applications/OrcaSlicer.app/Contents/MacOS",
  "run_bridge_probe": true,
  "bridge_command": "\"/Applications/OrcaSlicer.app/Contents/MacOS/pjarczak-bambu-linux-host-wrapper\" \"$HOME/Library/Application Support/OrcaSlicer/macos-bridge/runtime/pjarczak_bambu_linux_host\""
}

The result reports missing payload files, install/verify commands, the MCP env values to use, and bridge handshake/capability/runtime info when probing is enabled.

Per-call executable selectors require MCP_ALLOW_EXECUTABLE_ARG=1. By default the bridge command and its derived paths are read from server environment configuration. Passing bridge_command, or passing slicer_path, plugin_dir, or runtime_dir with run_bridge_probe=true, returns an error naming the opt-in flag. Non-executing setup inspection can still use the path arguments without the flag. These values select which local executable this server launches, so accepting them for a probe lets whatever is steering the model — a downloaded model's description, a README in an archive, 3MF metadata — choose that program. The same gate applies to slicer_path on slicing tools. Set the flag only for trusted iterative diagnostics; leave it off for normal use.

FULU Bridge RPC

fulu_bambu_network_rpc speaks the FULU bridge frame protocol from the MCP side. The protocol is little-endian binary frames with JSON bodies, using methods such as bridge.handshake, bridge.capabilities, bridge.runtime_info, and net.get_user_print_info.

Safe diagnostic example:

{
  "method": "bridge.runtime_info",
  "bridge_command": "\"/Applications/OrcaSlicer.app/Contents/MacOS/pjarczak-bambu-linux-host-wrapper\" \"$HOME/Library/Application Support/OrcaSlicer/macos-bridge/runtime/pjarczak_bambu_linux_host\""
}

Mutating methods are intentionally gated:

{
  "method": "net.start_print",
  "allow_mutating_method": true,
  "bambu_model": "p1s",
  "payload": {
    "client_job_id": 1,
    "params": {
      "dev_id": "YOUR_PRINTER_ID"
    }
  }
}

That second example is intentionally incomplete because real BambuNetwork print calls need the full FULU/Bambu print parameter payload. The important part is that the MCP exposes the bridge without pretending a cloud print can be safely inferred from a local filename.

Where this config lives depends on your client and OS:

Client / scope	macOS / Linux location	Windows location
Claude Desktop (macOS / Windows)	~/Library/Application Support/Claude/claude_desktop_config.json	%APPDATA%\Claude\claude_desktop_config.json
Claude Desktop (Linux)	Not officially supported for local MCP yet; Claude Desktop docs still list Linux support as coming soon.	N/A
Claude Code (project-shared MCP)	.mcp.json in the project root	.mcp.json in the project root
Claude Code (user/local MCP)	~/.claude.json	%USERPROFILE%\.claude.json
Claude Code settings (not MCP server definitions)