Limitations

Printer Limitations

1. Status depth varies by backend. get_printer_status returns each backend's own status data: Bambu includes progress, layers, and time remaining; OctoPrint's /api/printer and Moonraker's /printer/info have no job progress. Use counterpart_print_progress for job progress on every backend. Its OctoPrint and Klipper mappings were checked against OctoPrint 1.8 and 1.11 virtual printers and a simulated Klipper printer; PrusaLink, Duet, Repetier, and Creality follow their API documentation and have not been checked on hardware.
2. Resume only what this server started. resume_print refuses a job it did not inspect and start, including one it started before a restart. Repetier's pause command and its time fields are not in Repetier's API manual.
3. Plain HTTP for most backends. Klipper, Duet, Repetier, and Creality adapters connect over http://. OctoPrint does too, unless PRINTER_HOST is an https:// URL (certificates are verified). The Prusa adapter uses HTTPS for Prusa Connect, an https:// host, or port 443.
4. Moonraker authentication is optional; Duet has no password support. Set API_KEY for Moonraker hosts that require authentication. Leave it empty only when Moonraker trusts the MCP host. A password-protected Duet cannot be reached yet.
5. Command sent is not print finished. A success response means the printer or its host accepted the request. Check status, and the printer itself, before you walk away.
6. Bambu prints need a sliced project and the right model. print_3mf needs a .3mf with Metadata/plate_<n>.gcode, uploads it to cache/, and starts the zero-based plate_index selection (default 0). Print settings such as layer height and temperatures cannot be changed at print time. start_print handles plain .gcode files only.
7. Bambu AMS choice is explicit. ams_slots and ams_mapping choose trays; there is no automatic colour matching here (bambu-printer-mcp has auto_match_ams). The LAN mapping is padded to five entries as Bambu's P1/X1 firmware expects; real behavior still depends on firmware, loaded filament, and the project's metadata. The LAN route sends P1/X1-style project_file paths for every model; bambu-printer-mcp's H2, P2S and A1 path differences and X2D native route are not in this server.
8. Bambu temperatures go through G-code. Temperature targets are sent as M104 or M140 over MQTT, so the printer's firmware and current state decide whether they apply.
9. Bambu networking assumes a trusted LAN. MQTT and FTPS use the printer's self-signed certificate. Uploads use TLS 1.2 with session reuse; confirmation on the X1C firmware reported in #22 is still outstanding.
10. Safety checks read files and reports, not the physical printer. A declared material cannot prove what spool is loaded, and the server does not ask a person to check it: the client's print action is the approval. There is no bed check: the printer detects an occupied bed itself during bed leveling. Klipper macro parameters that name a heater are checked, but macro bodies stored on the printer cannot be inspected. On Duet/RepRapFirmware, selecting a tool (T0) heats it to the temperature already stored on the printer; activation-only M568 and M144 are refused, but a plain tool change is allowed because every firmware uses it. The safety gate is tested with mocked printer transports and loopback HTTP APIs, plus one real Bambu P1S run that reached the firmware's command check; other printer systems have not been exercised on real hardware in this release.
11. Remote starts need a download route. start_print of a file already on the printer works on Bambu Lab, OctoPrint, Klipper, and Duet. Repetier, Prusa, and Creality refuse it; upload the local G-code with print: true instead.

General Limitations and Considerations

Memory usage

• STL tools load the whole mesh into memory as Three.js geometry. Files over about 10 MB can use several hundred MB of RAM.
• Running several operations in a row on large files can build up memory between garbage collection cycles.
• There is no built-in memory cap. On constrained systems, avoid processing several large files at once.

STL manipulation limitations

• lay_flat looks for the largest flat face; results on organic or rounded models can be unpredictable.
• extend_stl_base adds new geometry beneath the model. Complex or non-planar undersides can produce gaps or intersections at the join, so inspect the result.
• merge_vertices with a large tolerance can change the model's shape. The 0.01 mm default is safe for most models.
• modify_stl_section works best on simple geometry. Non-manifold meshes (holes, overlapping faces, internal geometry) can produce unexpected results for any transformation; repair them first in your slicer or a mesh tool.

Visualization limitations

• generate_stl_visualization produces a simplified schematic, not a true 3D render, and very detailed models may lose detail.

Performance considerations

• Slicing can take from seconds to several minutes, depending on the model and your CPU. Slicer runs time out after SLICER_TIMEOUT_MS (10 minutes by default). On macOS, a Bambu-compatible slicer that uses no CPU and writes nothing for SLICER_STALL_SECONDS (20 by default) is stopped earlier and reported as slicer-waiting-on-dialog (structuredContent.code); on macOS each such slice runs with an empty home folder of its own (CFFIXED_USER_HOME under TEMP_DIR), so the "reopen windows?" question after a slicer crash can't stop it.
• Large uploads depend on your network and the printer's storage speed.
• Bambu MQTT connections are reused. If a printer restarts or the network drops, the next call reconnects.