Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

set_speed_profile

Destructive

Sets a 3D printer's print speed using a named preset or a percentage of the sliced speed, returning whether the printer confirmed, accepted, or failed the change.

Instructions

Set the print speed: a preset by name, or a percentage of the sliced speed.

One door for both ways a printer takes a speed.  Give exactly one of:

Args:
    profile: A preset — ``"silent"`` (50%), ``"standard"`` (100%),
        ``"sport"`` (124%) or ``"ludicrous"`` (166%).  Bambu Lab
        printers only; sport and ludicrous raise the nozzle
        temperature to keep up with the flow.
    percent: The speed as a percentage of the speed the file was
        sliced at — the feedrate override every FDM firmware has (100
        is the sliced speed; 10 to 300 is accepted).  A Bambu takes
        only its four presets, so the nearest one is set and the
        answer says which (``preset``, ``percent_actual``).
    printer_name: Which printer.  Omit for the default printer.

Nothing here judges whether a speed suits THIS printer or THIS layer:
Kiln's served ``set_speed_percent`` and ``set_speed_schedule`` do that
and hand the checked value here.  Use ``printer_status()`` to see the
current speed profile in ``printer.speed_profile``.

Branch on ``outcome`` — one field, three values, the same shape
``start_print`` uses for ``print_start``:

- ``"confirmed"``: the printer, in a report AFTER the command, shows the
  effect. For a Bambu, the reported speed level moved.
- ``"accepted"``: the command was sent and not refused, and the printer
  has not shown the effect yet. Normal on a quiet printer. Read
  ``printer_status()`` before building on it.
- ``"failed"``: the printer's interface refused the command.

``accepted`` (the boolean) keeps its old meaning: sent, not refused. It
is never proof the printer acted. ``success`` is ``False`` only for
``"failed"``.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "set_speed_profile"
  }
}

Input Schema

NameRequiredDescriptionDefault
percentNoThe speed as a percentage of the speed the file was sliced at — the feedrate override every FDM firmware has (100 is the sliced speed; 10 to 300 is accepted). A Bambu takes only its four presets, so the nearest one is set and the answer says which (``preset``, ``percent_actual``).
profileNoA preset — ``"silent"`` (50%), ``"standard"`` (100%), ``"sport"`` (124%) or ``"ludicrous"`` (166%). Bambu Lab printers only; sport and ludicrous raise the nozzle temperature to keep up with the flow.
printer_nameNoWhich printer. Omit for the default printer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.5.1
    • addedInput schema / properties / percent / description
      Added value: +"The speed as a percentage of the speed the file was sliced at — the feedrate override every FDM firmware has (100 is the sliced speed; 10 to 300 is accepted).  A Bambu takes only its four presets, so the nearest one is set and the answer says which (``preset``, ``percent_actual``)."
    • addedInput schema / properties / printer_name / description
      Added value: +"Which printer.  Omit for the default printer."
    • addedInput schema / properties / profile / description
      Added value: +"A preset — ``\"silent\"`` (50%), ``\"standard\"`` (100%), ``\"sport\"`` (124%) or ``\"ludicrous\"`` (166%).  Bambu Lab printers only; sport and ludicrous raise the nozzle temperature to keep up with the flow."
  2. Changed5 schema fields changedv1.5.0
    • addedInput schema / properties / percent
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Percent"
+}
    • addedInput schema / properties / printer_name
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Printer Name"
+}
    • addedInput schema / properties / profile / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • removedInput schema / properties / profile / type
      Removed value: -"string"
    • removedInput schema / required
      Removed value: -[
-  "profile"
-]
  3. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Goes well past the annotations by disclosing a real side effect (sport/ludicrous raise nozzle temperature), the Bambu coercion behavior (nearest preset is applied and reported via preset/percent_actual), and a full tri-state outcome contract ('confirmed'/'accepted'/'failed') with an explicit warning that accepted is never proof the printer acted. That directly disambiguates the destructiveHint=true mutation the annotations flag.

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?

Front-loads the one-line purpose and the exclusivity rule, then uses Args and bulleted outcome values for scanability. Slightly over-long: the trailing paragraph re-explaining the boolean 'accepted' and the success==False rule is largely redundant with the 'failed' bullet above it.

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?

With no output schema, the description compensates by fully specifying the return contract (outcome values, the reply fields preset/percent_actual, printer_status().printer.speed_profile for verification). For a three-parameter optional-argument mutation tool, nothing an agent needs to call it correctly is missing apart from lock/precondition details.

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% and the parameter descriptions restate the same preset percentages, 10–300 range, Bambu coercion and default-printer rule, so the description adds little unique meaning per parameter. One genuinely additive point is the 'exactly one of profile or percent' exclusivity, which the schema does not express.

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?

Opens with a specific verb and resource plus the two-mode scope: 'Set the print speed: a preset by name, or a percentage of the sliced speed.' It further distinguishes itself from the sibling tools set_speed_percent and set_speed_schedule, so an agent can tell which of the three to call without opening any schema.

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?

States the mutual-exclusion rule ('Give exactly one of' profile/percent) and the default behavior for printer_name, and routes validity judgment to set_speed_percent / set_speed_schedule. It does not, however, mention the fleet-wide alternative fleet_set_speed or state any precondition such as holding the printer lock before a mutating speed change.

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