Skip to main content
Glama

get_nozzle_state

Read-only

Retrieve the recorded nozzle state for a specific 3D printer using its printer ID. Optionally compare sliced-file nozzle size and printer readings to verify nozzle compatibility.

Instructions

Return the recorded nozzle state for a printer.

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": {
      "printer_id": "<printer_id>"
    },
    "name": "get_nozzle_state"
  }
}

Input Schema

NameRequiredDescriptionDefault
printer_idYesStable printer identifier — same key the public ``PrinterRegistry`` uses (e.g. ``"bambu_a1"``).
printer_modelNoOptional explicit model lookup key (e.g. ``"bambu_a1"``) when *printer_id* is a user-named instance ID like ``"kitchen_printer"``. Falls through to longest-prefix match against the overlay otherwise. Default: "".
file_nozzle_mmNoThe nozzle size in mm a sliced file states it was made for. Given one, the answer carries ``sliced_file``; a value that is not a plausible nozzle size is refused with ``VALIDATION_ERROR``. Omitted, no file check.
printer_readingNoWhat the printer itself reports as its nozzle, filled in by the caller's own Kiln when it can reach the machine. Used only where this process cannot read the printer, as data; omitted, the answer carries no printer-side comparison unless this process can read it. Leave it unset by hand.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.5.1
    • addedInput schema / properties / file_nozzle_mm / description
      Added value: +"The nozzle size in mm a sliced file states it was made for.  Given one, the answer carries ``sliced_file``; a value that is not a plausible nozzle size is refused with ``VALIDATION_ERROR``.  Omitted, no file check."
    • addedInput schema / properties / printer_id / description
      Added value: +"Stable printer identifier — same key the public ``PrinterRegistry`` uses (e.g. ``\"bambu_a1\"``)."
    • changedInput schema / properties / printer_model / description
      Previous value: -"Default: \"\"."New value: +"Optional explicit model lookup key (e.g. ``\"bambu_a1\"``) when *printer_id* is a user-named instance ID like ``\"kitchen_printer\"``.  Falls through to longest-prefix match against the overlay otherwise. Default: \"\"."
    • addedInput schema / properties / printer_reading / description
      Added value: +"What the printer itself reports as its nozzle, filled in by the caller's own Kiln when it can reach the machine.  Used only where this process cannot read the printer, as data; omitted, the answer carries no printer-side comparison unless this process can read it.  Leave it unset by hand."
  2. Addedv1.5.0

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already establish this as a safe, local, read-only operation, so the description need only add context beyond that. It adds only the ambiguous hint that the state is 'recorded', without explaining fallback behavior, what happens when no record exists, or how the optional printer_reading comparison is applied.

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

Conciseness4/5

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

The single sentence is front-loaded and free of filler, with no redundancy. It is arguably overly terse for a tool with optional comparison parameters, but that shortfall is better attributed to completeness than to waste.

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

Completeness2/5

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

For a tool with a nested optional object, model-resolution fallback, file-check behavior, and no output schema, the description does not explain return contents or error cases. The schema carries the details, but the description leaves key invocation context and sibling differentiation to inference.

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 parameter meanings are already fully documented in the schema. The description adds no additional semantic guidance about printer_id versus printer_model, file_nozzle_mm validation, or printer_reading usage, so the baseline of 3 applies.

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?

States a specific verb and resource ('Return the recorded nozzle state for a printer'), making the action understandable. However, it never distinguishes this from close siblings like list_nozzle_states, set_nozzle_state, or auto_detect_nozzle, so an agent cannot tell from the description alone which one to pick.

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

Usage Guidelines2/5

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

The description offers no when-to-use guidance, no prerequisites, and no named alternatives. The word 'recorded' faintly implies a stored lookup rather than a live query, but that inference is not stated or contrasted with sibling tools.

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