Skip to main content
Glama

register_printer

Destructive

Add a 3D printer to Kiln's fleet for AI-agent control and monitoring. Handles OctoPrint, Bambu, Moonraker, Creality, Elegoo, Prusa Link, Duet and USB backends.

Instructions

Register a new printer in the fleet.

Registering is free at every tier and always has been — what the fleet
tier sells is running printers in PARALLEL, enforced when a print
starts, not when a machine is added.  So owning a second printer and
using them one at a time is a supported setup on Free and Pro: the
registration succeeds and the reply notes the concurrency limit.

Free and Pro run 1 printer at a time.  Driving several at once starts
at Business; the reply says how many printers your plan includes.

Args:
    name: Unique human-readable name (e.g. "voron-350", "bambu-x1c").
        A name holding the printer's address, serial or another
        identifier is held before anything is saved (code
        ``NAME_HOLDS_IDENTIFIER``): the reply says what is in it and
        carries ``suggested_name``.  Offer that to the person, then call
        again with the name they choose.
    printer_type: Backend type -- "octoprint", "moonraker", "bambu",
        "creality", "elegoo", "prusalink", "duet", or "usb".
        "serial" is accepted as a legacy alias for "usb".
    host: Base URL or IP address of the printer.  For USB printers,
        this is the port path (e.g. "/dev/ttyUSB0", "COM3").
    api_key: The printer's credential: an API key (OctoPrint, Prusa
        Link, a Moonraker or Creality printer with its login turned
        on), a Bambu Lab printer's LAN access code, or a Duet's
        machine password.  For OctoPrint it can be left out: Kiln asks
        OctoPrint for a key and the reply (code ``AWAITING_APPROVAL``)
        carries ``approve_url``, a page where the person clicks Allow.
        Give them that link, then call again with the same arguments;
        the request stays open for ten minutes.
    serial: A Bambu Lab printer's serial number (``discover_printers``
        reads it off the network), or an Elegoo printer's mainboard id.
    verify_ssl: Whether to verify SSL certificates (default True).
        Set to False for printers using self-signed certificates.
        For Bambu, True maps to TLS pin mode and False maps to
        insecure mode.
    printer_model: Which printer this is, in any spelling the
        catalogue knows ("K1 Max", "k1_max", "Prusa MK4").  Required: a
        registration without it is refused (``PRINTER_MODEL_REQUIRED``).
        Ask the person, who knows what they bought; never guess one.
        A model outside the catalogue is recorded as they name it, with
        its make, under Kiln's generic limits.
    printer_make: Who makes the printer ("Prusa", "Anycubic").  Needed
        only for a model outside the catalogue, and implied by a Bambu
        Lab, Creality, Elegoo or Prusa Link connection.
    persist: Save the printer to ``~/.kiln/config.yaml`` so future MCP
        sessions load the same printer. Default ``True``.
    verify_connection: For Bambu printers, immediately query AMS status
        after registration and return a proof summary. Default ``True``.
    baudrate: Baud rate for USB printers.  Omitted, 115200; many
        Marlin boards are flashed for 250000 and will not talk at
        115200.
    camera_snapshot_url: A camera YOU point at the bed — an http(s)
        URL that answers with one image (a webcam's snapshot endpoint,
        an IP camera's still URL).  Any printer type; used instead of
        the printer's own camera by ``printer_snapshot``,
        ``monitor_print`` and every other frame reader.
    camera_stream_url: The same camera as a live feed — MJPEG over
        http(s), or an rtsp(s) stream (a frame is cut with ffmpeg).
        Either URL alone is enough.  A stream URL may embed a
        password; it is stored with the printer's other credentials
        and never repeated in a reply or a log.  Frames from your
        camera are what Kiln looks at; they do not switch on the
        printer's own failure detection, which runs on the printer
        against its own cameras.
    keep_name: True to register under ``name`` as given after the
        person has seen ``suggested_name`` and chosen their own.

When something this kind of printer needs is missing, the refusal
names it and says where the person finds it; ``discover_printers``
says the same for each printer it finds, before anything is asked.

Once the address has answered, Kiln reads the id the machine reports
for itself (a Prusa Link printer's serial, a Duet board's unique id,
the host serial Moonraker reports) and saves it with the printer, so a
later registration under this name at a new address is matched to the
same machine -- or refused as a different one -- by that id rather
than by the address.  The reply's ``machine_identity`` carries what
was read; a read that fails is noted in ``warnings`` and never fails
the registration.

Once registered the printer can be targeted by name — ``printer_status``,
``monitor_print``, ``cancel_print``, ``pause_print`` and ``resume_print``
all take a ``printer_name`` at every tier, so owning a second machine
never costs you sight of it or control over it.  Seeing them together
(``fleet_status``) and driving them together are Business features.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "printer_type": "<printer_type>",
      "host": "<host>"
    },
    "name": "register_printer"
  }
}

Input Schema

NameRequiredDescriptionDefault
hostYesBase URL or IP address of the printer. For USB printers, this is the port path (e.g. "/dev/ttyUSB0", "COM3").
nameYesUnique human-readable name (e.g. "voron-350", "bambu-x1c"). A name holding the printer's address, serial or another identifier is held before anything is saved (code ``NAME_HOLDS_IDENTIFIER``): the reply says what is in it and carries ``suggested_name``. Offer that to the person, then call again with the name they choose.
serialNoA Bambu Lab printer's serial number (``discover_printers`` reads it off the network), or an Elegoo printer's mainboard id.
api_keyNoThe printer's credential: an API key (OctoPrint, Prusa Link, a Moonraker or Creality printer with its login turned on), a Bambu Lab printer's LAN access code, or a Duet's machine password. For OctoPrint it can be left out: Kiln asks OctoPrint for a key and the reply (code ``AWAITING_APPROVAL``) carries ``approve_url``, a page where the person clicks Allow. Give them that link, then call again with the same arguments; the request stays open for ten minutes.
persistNoSave the printer to ``~/.kiln/config.yaml`` so future MCP sessions load the same printer. Default ``True``. Default: true.
baudrateNoBaud rate for USB printers. Omitted, 115200; many Marlin boards are flashed for 250000 and will not talk at 115200.
keep_nameNoTrue to register under ``name`` as given after the person has seen ``suggested_name`` and chosen their own. Default: false.
verify_sslNoWhether to verify SSL certificates (default True). Set to False for printers using self-signed certificates. For Bambu, True maps to TLS pin mode and False maps to insecure mode. Default: true.
printer_makeNoWho makes the printer ("Prusa", "Anycubic"). Needed only for a model outside the catalogue, and implied by a Bambu Lab, Creality, Elegoo or Prusa Link connection.
printer_typeYesBackend type -- "octoprint", "moonraker", "bambu", "creality", "elegoo", "prusalink", "duet", or "usb". "serial" is accepted as a legacy alias for "usb".
printer_modelNoWhich printer this is, in any spelling the catalogue knows ("K1 Max", "k1_max", "Prusa MK4"). Required: a registration without it is refused (``PRINTER_MODEL_REQUIRED``). Ask the person, who knows what they bought; never guess one. A model outside the catalogue is recorded as they name it, with its make, under Kiln's generic limits.
camera_stream_urlNoThe same camera as a live feed — MJPEG over http(s), or an rtsp(s) stream (a frame is cut with ffmpeg). Either URL alone is enough. A stream URL may embed a password; it is stored with the printer's other credentials and never repeated in a reply or a log. Frames from your camera are what Kiln looks at; they do not switch on the printer's own failure detection, which runs on the printer against its own cameras.
verify_connectionNoFor Bambu printers, immediately query AMS status after registration and return a proof summary. Default ``True``. Default: true.
camera_snapshot_urlNoA camera YOU point at the bed — an http(s) URL that answers with one image (a webcam's snapshot endpoint, an IP camera's still URL). Any printer type; used instead of the printer's own camera by ``printer_snapshot``, ``monitor_print`` and every other frame reader.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed14 schema fields changedv1.5.1
    • addedInput schema / properties / api_key / description
      Added value: +"The printer's credential: an API key (OctoPrint, Prusa Link, a Moonraker or Creality printer with its login turned on), a Bambu Lab printer's LAN access code, or a Duet's machine password.  For OctoPrint it can be left out: Kiln asks OctoPrint for a key and the reply (code ``AWAITING_APPROVAL``) carries ``approve_url``, a page where the person clicks Allow. Give them that link, then call again with the same arguments; the request stays open for ten minutes."
    • addedInput schema / properties / baudrate / description
      Added value: +"Baud rate for USB printers.  Omitted, 115200; many Marlin boards are flashed for 250000 and will not talk at 115200."
    • addedInput schema / properties / camera_snapshot_url / description
      Added value: +"A camera YOU point at the bed — an http(s) URL that answers with one image (a webcam's snapshot endpoint, an IP camera's still URL).  Any printer type; used instead of the printer's own camera by ``printer_snapshot``, ``monitor_print`` and every other frame reader."
    • addedInput schema / properties / camera_stream_url / description
      Added value: +"The same camera as a live feed — MJPEG over http(s), or an rtsp(s) stream (a frame is cut with ffmpeg). Either URL alone is enough.  A stream URL may embed a password; it is stored with the printer's other credentials and never repeated in a reply or a log.  Frames from your camera are what Kiln looks at; they do not switch on the printer's own failure detection, which runs on the printer against its own cameras."
    • addedInput schema / properties / host / description
      Added value: +"Base URL or IP address of the printer.  For USB printers, this is the port path (e.g. \"/dev/ttyUSB0\", \"COM3\")."
    • addedInput schema / properties / keep_name
      Added value: +{
      +  "description": "True to register under ``name`` as given after the person has seen ``suggested_name`` and chosen their own. Default: false.",
      +  "title": "Keep Name",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / name / description
      Added value: +"Unique human-readable name (e.g. \"voron-350\", \"bambu-x1c\"). A name holding the printer's address, serial or another identifier is held before anything is saved (code ``NAME_HOLDS_IDENTIFIER``): the reply says what is in it and carries ``suggested_name``.  Offer that to the person, then call again with the name they choose."
    • changedInput schema / properties / persist / description
      Previous value: -"Default: true."New value: +"Save the printer to ``~/.kiln/config.yaml`` so future MCP sessions load the same printer. Default ``True``. Default: true."
    • addedInput schema / properties / printer_make
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "Who makes the printer (\"Prusa\", \"Anycubic\").  Needed only for a model outside the catalogue, and implied by a Bambu Lab, Creality, Elegoo or Prusa Link connection.",
      +  "title": "Printer Make"
      +}
    • addedInput schema / properties / printer_model / description
      Added value: +"Which printer this is, in any spelling the catalogue knows (\"K1 Max\", \"k1_max\", \"Prusa MK4\").  Required: a registration without it is refused (``PRINTER_MODEL_REQUIRED``). Ask the person, who knows what they bought; never guess one. A model outside the catalogue is recorded as they name it, with its make, under Kiln's generic limits."
    • addedInput schema / properties / printer_type / description
      Added value: +"Backend type -- \"octoprint\", \"moonraker\", \"bambu\", \"creality\", \"elegoo\", \"prusalink\", \"duet\", or \"usb\". \"serial\" is accepted as a legacy alias for \"usb\"."
    • addedInput schema / properties / serial / description
      Added value: +"A Bambu Lab printer's serial number (``discover_printers`` reads it off the network), or an Elegoo printer's mainboard id."
    • changedInput schema / properties / verify_connection / description
      Previous value: -"Default: true."New value: +"For Bambu printers, immediately query AMS status after registration and return a proof summary. Default ``True``. Default: true."
    • changedInput schema / properties / verify_ssl / description
      Previous value: -"Default: true."New value: +"Whether to verify SSL certificates (default True). Set to False for printers using self-signed certificates. For Bambu, True maps to TLS pin mode and False maps to insecure mode. Default: true."
  2. Changed12 schema fields changedv1.5.0
    • removedInput schema / properties / api_key / default
      Removed value: -null
    • removedInput schema / properties / baudrate / default
      Removed value: -null
    • addedInput schema / properties / camera_snapshot_url
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "title": "Camera Snapshot Url"
      +}
    • addedInput schema / properties / camera_stream_url
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "title": "Camera Stream Url"
      +}
    • removedInput schema / properties / persist / default
      Removed value: -true
    • addedInput schema / properties / persist / description
      Added value: +"Default: true."
    • removedInput schema / properties / printer_model / default
      Removed value: -null
    • removedInput schema / properties / serial / default
      Removed value: -null
    • removedInput schema / properties / verify_connection / default
      Removed value: -true
    • addedInput schema / properties / verify_connection / description
      Added value: +"Default: true."
    • removedInput schema / properties / verify_ssl / default
      Removed value: -true
    • addedInput schema / properties / verify_ssl / description
      Added value: +"Default: true."
  3. Changed1 schema field changedv1.3.0
    • addedInput schema / properties / baudrate
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Baudrate"
      +}
  4. First observedv0.1.0

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutating call, and the description adds genuinely useful behavior: specific refusal codes, the ten-minute approval window, secret handling for camera_stream_url passwords, machine-identity reads that never fail the registration but land in ``warnings``, and the ``persist`` write to ``~/.kiln/config.yaml``. What it never addresses is the destructive edge the annotation flags — whether registering under an existing name overwrites or merges an existing printer entry, which is the main risk an agent needs to know about.

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

Conciseness2/5

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

The purpose is front-loaded well, but a full paragraph is spent on tier/pricing advocacy ("Registering is free at every tier and always has been — what the fleet tier sells is running printers in PARALLEL") that does not help an agent call the tool, and the Args block duplicates the schema word for word. Roughly half the text could be cut with no loss of invocation guidance.

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

Completeness4/5

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

For a 14-parameter create tool with no output schema, the description covers a lot: refusal codes, reply fields (``suggested_name``, ``approve_url``, ``machine_identity``, ``warnings``), per-backend credential requirements, and what ``persist`` actually writes. It omits only the overwrite/duplicate-name path, which is the remaining thing an agent would want before committing.

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 schema already documents every one of the 14 parameters in detail. The description's Args block is essentially a verbatim restatement of those schema descriptions and adds no meaning beyond them. Baseline 3 is the correct ceiling when the description only echoes structured data.

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?

The first line names a specific verb and resource ("Register a new printer in the fleet") and distinguishes the operation from discovery (``discover_printers``) and from later targeting of an already-registered printer. An agent knows immediately this is the create/add path.

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?

Usage context is strong: it explains that registration always succeeds regardless of tier, that concurrency limits apply at print time rather than registration, and it prescribes the retry loop for ``NAME_HOLDS_IDENTIFIER`` (offer ``suggested_name``, call again) and ``AWAITING_APPROVAL`` (hand over ``approve_url``, retry within ten minutes). It implies discovery should precede registration via the ``discover_printers`` reference but never states that ordering as an explicit rule, and it gives no guidance on what to do when the name is already taken.

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