Skip to main content
Glama
DMontgomery40

MCP 3D Printer Server

by DMontgomery40
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

process_and_print_stl

Extend an STL base, slice it, and start printing; the job is refused before upload if expected bed or nozzle temperatures mismatch.

Instructions

Process an STL file (extend base), slice it, and start printing through the same checked print gate as upload_gcode/print_3mf. Expected temperatures are enforced: a mismatch refuses before upload.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hostNoHostname or IP address of the printer (default: value from env)
portNoPort of the printer API (default: value from env)
typeNoType of printer management system (default: value from env)
api_keyNoAPI key for authentication (default: value from env)
bed_tempNoExpected highest bed target in the sliced G-code (S and R forms). Printing stops before upload if it differs.
bed_typeNoBed/plate type installed on the printer (default: textured_plate).
materialNoDeclared filament material when the sliced G-code has no filament_type metadata. Must not contradict the file.
stl_pathYesPath to the STL file to process
bambu_modelNoBambu Lab printer model. Required for Bambu print operations.
nozzle_typeNoInstalled Bambu nozzle material used when slicing (default: BAMBU_NOZZLE_TYPE, else the preset's stock nozzle). The print gate compares it with the printer's report.
slicer_pathNoPath to the slicer executable (default: value from env). Per-call overrides require MCP_ALLOW_EXECUTABLE_ARG=1.
slicer_typeNoType of slicer to use. Use orcaslicer-bambulab for FULU OrcaSlicer-bambulab.
extruder_tempNoExpected highest nozzle target in the sliced G-code (S and R forms, every tool). Printing stops before upload if it differs.
slicer_profileNoProfile to use for slicing (default: value from env). OrcaSlicer also accepts machine/process profiles separated with ';', optionally followed by '|filament.json'.
nozzle_diameterNoNozzle diameter in mm (default: 0.4).
extension_inchesYesAmount to extend the base in inches
filament_profileNoOrcaSlicer filament profile path loaded with --load-filaments (default: FILAMENT_PROFILE/SLICER_FILAMENT_PROFILE env).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.9

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It usefully discloses the temperature-enforcement gate and that a mismatch refuses before upload, and 'start printing' signals a mutating, possibly irreversible action. However, it omits auth requirements, what happens on slicer failure, or the host/api_key defaulting behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste, with the core action chain front-loaded and the enforcement caveat second. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 17-parameter mutation tool with no annotations and no output schema, the description covers the pipeline and the print gate but says nothing about return values, failure modes beyond temperature mismatch, or the relationship to the several sibling STL-modification tools. Adequate but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the 17 parameters are already documented in the schema. The description adds only the 'extend base' hint tied to extension_inches and reinforces the temperature-check semantics already in bed_temp/extruder_temp descriptions. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific multi-step operation — extend the STL base, slice, and print — and anchors it against siblings by referencing the same checked print gate used by upload_gcode/print_3mf. An agent can distinguish it from slice_stl or start_print, though the 'extend base' phrasing is terse.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The pipeline nature implies usage (one call instead of slice_stl followed by start_print) but no explicit when/when-not guidance is given. The reference to the shared print gate hints at why this exists, but the agent must infer the alternative paths.

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