Skip to main content
Glama
Sign In

kernelCAD

by com.kernelcad
OverviewDiscussionsAdmin

Send G-code to Printer

send_to_printer
Destructive

Use this when you need to upload a .gcode file (e.g. written by export with target: "model", format: "gcode") to a real network printer and, by default, start the print. protocol: 'octoprint' (POST /api/files/local with an X-Api-Key), 'moonraker' (Klipper's POST /server/files/upload), or 'bambu-lan' (Bambu Lab LAN-mode: FTPS implicit-TLS upload on port 990 as user 'bblp' with the printer's LAN access code, then an MQTT print-start command on port 8883 — requires access_code and, unless start_print is false, serial). bambu-lan uploads a .gcode.3mf print project (the printer prints 3MF projects, not bare G-code): the G-code goes in as Metadata/plate_1.gcode, inside the model 3MF from export format '3mf' when model_3mf_path is given (use options { arrange: 'plate', slicer: 'bambu' } so the printer shows the same named, coloured parts), else inside a minimal 3MF shell; the file name always ends in .3mf ('part.gcode' -> 'part.gcode.3mf'). Optional printer (a bundled profile id, the same ids as the export 3mf/gcode options.printer) is checked against protocol before anything is read or sent: an unknown id is refused with the list of valid ids, 'bambu-lan' needs a Bambu Lab profile and a Bambu Lab profile needs 'bambu-lan'. Pass { dry_run: true } to validate connectivity/authentication only, without uploading or starting a print. Never logs or echoes api_key/access_code.

Input Schema

NameRequiredDescriptionDefault
hostYesPrinter hostname or IP.
portNoOverride the protocol default port.
serialNoBambu printer serial number (required to start a print unless start_print is false).
api_keyNoOctoPrint API key (Settings -> API).
dry_runNoValidate connectivity/auth only; never uploads or starts a print.
printerNoPrinter profile id; checked against protocol before upload. List them with 'kernelcad print printers'.
filenameNoUploaded file name (default: 'kernelcad.gcode'; bambu-lan appends '.3mf').
protocolYes
gcode_pathYesPath to the .gcode file on disk.
access_codeNoBambu LAN-mode access code (printer settings -> LAN Only Mode).
start_printNoStart the print immediately after upload (default: true).
model_3mf_pathNobambu-lan only: model .3mf from export format '3mf' to package the G-code into (the uploaded .gcode.3mf).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedOutput schema / properties
      Removed value: -{
-  "diagnostics": {
-    "items": {
-      "additionalProperties": true,
-      "type": "object"
-    },
-    "type": "array"
-  },
-  "dry_run": {
-    "description": "True when only connectivity/auth was validated (no upload, no print start).",
-    "type": "boolean"
-  },
-  "error": {
-    "type": "string"
-  },
-  "ok": {
-    "type": "boolean"
-  },
-  "uploaded_path": {
-    "description": "Path/name the G-code (bambu-lan: the .gcode.3mf print file) was stored under on the printer.",
-    "type": "string"
-  }
-}
    • removedOutput schema / required
      Removed value: -[
-  "ok"
-]
  2. Changed4 schema fields changed
    • changedInput schema / properties / filename / description
      Previous value: -"Uploaded file name (default: 'kernelcad.gcode')."New value: +"Uploaded file name (default: 'kernelcad.gcode'; bambu-lan appends '.3mf')."
    • addedInput schema / properties / model_3mf_path
      Added value: +{
+  "description": "bambu-lan only: model .3mf from export format '3mf' to package the G-code into (the uploaded .gcode.3mf).",
+  "type": "string"
+}
    • addedInput schema / properties / printer
      Added value: +{
+  "description": "Printer profile id; checked against protocol before upload. List them with 'kernelcad print printers'.",
+  "enum": [
+    "generic-fdm",
+    "bambu-a1-mini",
+    "bambu-a1",
+    "bambu-p1s",
+    "bambu-p1p",
+    "bambu-x1c",
+    "bambu-x1e",
+    "bambu-h2d",
+    "bambu-h2s",
+    "prusa-mini-plus",
+    "prusa-mk4s",
+    "prusa-core-one",
+    "prusa-xl",
+    "creality-ender-3-v3",
+    "creality-k1",
+    "creality-k1-max",
+    "creality-k2-plus",
+    "elegoo-neptune-4-pro",
+    "anycubic-kobra-3",
+    "voron-2.4-250",
+    "voron-2.4-300",
+    "voron-2.4-350",
+    "ultimaker-s5"
+  ],
+  "type": "string"
+}
    • changedOutput schema / properties / uploaded_path / description
      Previous value: -"Path/name the G-code was stored under on the printer."New value: +"Path/name the G-code (bambu-lan: the .gcode.3mf print file) was stored under on the printer."
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Extraordinarily forthcoming beyond the annotations: secrets are never logged or echoed, printer profiles are validated against protocol before anything is read or sent, unknown ids are refused with the valid list, dry_run performs connectivity/auth checks only, and bambu-lan silently repackages G-code into a .gcode.3mf project with filename rewriting ('part.gcode' -> 'part.gcode.3mf'). This directly supports the destructiveHint=true / idempotentHint=false annotations by explaining that a real print starts by default and auth material is required.

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

Conciseness3/5

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

Front-loading 'Use this when...' is right, but the body is a single sprawling sentence stitched together with em-dashes and nested parentheses, making it hard to scan for the one protocol the agent needs. Given three protocols and 12 parameters some length is justified, but a per-protocol breakdown would earn its space better than the run-on structure.

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?

Covers everything an agent needs to call this safely for a destructive, network-dependent operation: required credentials per protocol, default behaviors (start_print true), validation-only mode, failure modes for bad profiles, and file-type conversion quirks. An output schema exists, so return values need no explanation.

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

Parameters5/5

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

Despite 92% schema coverage, the description adds material meaning the schema does not: bambu-lan requires access_code and, unless start_print is false, serial; model_3mf_path must come from export format '3mf' with options { arrange: 'plate', slicer: 'bambu' }; printer is cross-checked against protocol with bidirectional constraints. The interaction rules between parameters are the value here, not restatement.

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 — upload a .gcode file to a network printer and start the print by default — and enumerates the three supported protocols with their concrete endpoints. Even with 60+ siblings, an agent can immediately tell this is the physical-printing tool rather than export or fab_pack.

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

Usage Guidelines4/5

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

"Use this when you need to upload a .gcode file ... to a real network printer" gives a clear triggering context and ties the input back to export with target: "model", format: "gcode", which effectively names the upstream step. It also offers dry_run as the validate-only alternative. What it lacks is an explicit 'do not use for X, use export/fab_pack instead' exclusion.

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

All kernelCAD toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources